Select to view content in your preferred language

Feature Service vs. Map Service

10-13-2017 06:32 AM
Regular Contributor

When publishing a map service, is there any advantage/reason to enable feature access unless you are going to edit features?

For example, if I want to add a REST endpoint to ArcGIS Online and save the layer as a read-only feature layer, is there any advantage to using a numbered feature service layer versus a numbered map service layer?  Obviously, if I wanted editing capabilities, I'd have to add the feature service layer, but if I simply want our users to have the ability to search for a layer and add it to a web map in ArcGIS Online, is using a numbered map service layer sufficient, or does a numbered feature service layer offer any benefits?

11 Replies
Esri Regular Contributor

Here's a good discussion where Vince Angelo‌ helped to clarify:

Besides editing, feature services also provide the option to dynamically set symbology for features at the client side. Map services essentially provide images pre-symbolized at the server side - either as pre-cached tiles or as dynamically generated images made from an exportmap request. Map services can be cached in order for data to render quickly. That's why basemaps are generally cached map services, while feature layers that render on top of basemaps can be either from a mapserver resource or a featureserver resource.

Regular Contributor

I get that there is a difference between an entire map service and a feature service.  But when you get down to the individual layers within the service, is there really a difference between:

Parcel Feature Service 


Parcel Map Service 

This is strictly from an ArcGIS Online point of view.  If I add these two endpoints to AGO, I can alter the same properties, for example: apply different symbology and filter.  Since I'm not interested in my users being able to edit these layers, simply allowing them to search for the layer and add it to a web map, is there really any reason to provide feature access?

Regular Contributor

Hi Matthew,

If you take editing out of the picture, it's largely a performance consideration. Check out the System Design Strategies on selecting the best output format for performance:

Software Performance - GIS Wiki | The GIS Encyclopedia 

It's not the best graphic in the world, but I believe it suggests that feature access increases the network traffic to your client considerably over other formats.

However, there is another reason you might want to publish non-editable data with feature access: to provide reference layers for offline mobile work. Publishing a non-editable feature service with the "Sync" capability enabled will allow your mobile editors to take the layer offline (with ArcGIS Collector, for example) to provide reference when overlaid with other, editable layers.


Occasional Contributor II

One other consideration I just discovered:

You cannot show attachments in the pop-ups for map services. The item must be a feature service layer.

Which seems kind of lame to me, since you CAN show related records for map services.

Maybe someone can prove me wrong...

0 Kudos
New Contributor II

Are you editing? Yes == you will have to use a feature service (at least for editing).

Caution: Brain-Dump A-Head...

Feature services, have very limited symbology renders (compared to dynamic map /export services):

See 20027: Layer uses advanced renderer settings—Help | ArcGIS for Desktop 

Feature services aren't necessarily great for highly complex geometries (i.e. lots of vertices) as the payload and requirements for many client devices to perform the rendering provides a poor user experience. Additionally, the max limit for feature services and a lack of client side (raw data) caching means there's likely to be a lot of I/O between client/server/database.

Feature services don't have a highly sophisticated control throttling the amount of data I/O. The service has a "max record" setting with a default of 1,000, however the geometry of 1,000 complex polygon features is far more complex than 1,000 2D point features. Similarly, not all polygon features have comparable complexity and may exist in the same feature class. It's not something we should expect Esri to address, but it is a characteristic of feature services you should be aware of an take it into consideration when evaluating their suitability. I've had 32,000 point's running perfectly find and seen 1,000 polygons grind Chrome to its knee's.

...cont. Something I have noticed in recent times is that the JS API appears to /query feature services for data in "tiled" chunks. So a single pan operation might spawn 6+ /query requests simultaneously to the server. I understand that this can provide a better user experience as data is obtained in chunks and the user will see a progressive loading of data. However, from a server perspective, this can hammer the server(s)/database(s) with multiple requests from a single client all at once. Each request exists within the max feature limit. So if you have the default limit of 1,000 the server is doing more work than you think. Additionally, the client may have to render a total > 6,000 complex features. I believe there's a way to control this behavior on the service but I have forgotten how sorry. I thought the simple request per map extent change was easier to configure/control/throttle but that's all in the past now.

Feature services/layers open up a lot of possibilities for client site development tools. This is because the data exists client-side whereas dynamic map services are just an image. They can be really useful and exploited for your own needs - so long as you are happy to develop.

Feature services can be great for printing secure data/services. The reason being that the client has the data and it passes it on to the printing server/services (to render). If you are using a secure dynamic map service, then the print service can't be supplied with data by the client. The print service needs security configuration so that it can talk to the secure dynamic map service. It can be complicated/problematic to get secure dynamic map services to print reliably. Esri should consider extending the output format of /export to support base64 so that the client can "fetch on forward" the images that the print service will require to compile its print output. 

Dynamic Map Services are really good at rendering the output but it comes at a cost (nothings free). The load is placed on the server resources (not the clients) and I/O is highly likely (but not always) higher than feature services. So, you might need additional server infrastructure (note.... AGOL don't support these services and this is why).

Hope someone finds something in here to be useful.

by Anonymous User
Not applicable

I have found dynamic map services aka map image services to be far easier on my server. And also they're so slow on the user end they are not useable. Ratcheting up max record count would peg the server in to oblivion on something like my parcel layer with hundreds of thousands of polygons. I never use feature services; it is only because of the performance issue.

All that will change once 10.7.1 implements feature service tiling. I'm really looking forward to this. That is apparently what is enabling hosted layers to render so fast. Until then, I have banished feature layers because they essentially bring servers to a halt. Esri always shows an example of a few trees or a parcel layer with 25 parcels or something like that. And/or a hosted feature layer, but most Orgs use their own server. Neither of those kinds of demos are useful. Real datasets are almost always bigger. It doesn't matter what a feature layer can do if it is not fast for the user and grinds the server to a halt.

This also is an issue because Open Data "Create webmap" link adds layers as feature layer to a new webmap. Rendering the whole idea of Open Data to view data, and let users make viewers ... useless. They definitely won't understand why not everything is showing or it is running slow.  For a concept like Open Data it needs to work, both easily in terms of interface and needs to be fast.   This is because adding a sublayer with .../serviceName../.Layer../0  or a number at the end, adds as a featureLayer. Hopefully next-gen AGOL will support adding sublayers as map image layers.  That would solve a lot of problems such as this. It can not be over-stated. 

Esri Regular Contributor

Kevin MacLeod‌, Given your experience, I'd posit that the bottleneck is likely on the database side. Have you done any profiling with SDEINTERCEPT?

by Anonymous User
Not applicable

Thank you Randall, I haven't, I will look at that for some SDE services. It happens even with fgdb though. And I compress and post and rec in SDE and attempt to optimize mxd documents for services. 

0 Kudos
New Contributor II

Hi Mathew 

Wanted to clarify that an AGOL or Portal Feature Service also allows other users to extract the layer or subset of the features.  In a map service it may be queriable but not extractable? 

0 Kudos