Select to view content in your preferred language

Whooooole lot of features: Bad Idea?

600
2
11-03-2014 02:47 PM
williamcarr
Frequent Contributor

I'm working on a PLSS app to search for land sections in the traditional descriptions.(NE corner of the SW corner of the NS corner ect.) So I took some PLSS sections, ran a model to cut them into quarters giving the first description(NE,SE,NW,SW). Then repeat the process on these sections, giving it a second field of (NE,SE,NW,SW), again and again till the quarters represent about 50 meters or so. My question, before I start on the second round of quartering is:

Is this going to be to many features to host in a JS app. I fully intend on limited scaling and labeling, but is 60 million features (through 6 or 7 layers) going to be possible?

On a side note, is it feasible to query a layer with 20 million features? Now that I think of it, it sounds kind of out of the question but what do I know.

Thanks.

0 Kudos
2 Replies
by Anonymous User
Not applicable

I can briefly chime in to say the default for querying feature services is to return 1000 features. However, I had a layer with a few thousand and got help in the 'setDefinitionExpression' method of FeatureLayer. You can limit the features returned in this way to just the area you are searching in (maybe a county). I personally have a dropdown menu where a user chooses a state, and I then only return features in that area, which is generally <500. Another option I offer is for the user to draw a bounding box and only return features in the area of their interest.

You can also increase the default number of features returned but it will most likely impact the speed of your application.

0 Kudos