We have a query tool currently being designed outside the GIS environment which will allow the user to select a variety of health related parameters: collection year, gender, age etc. Most of the work is getting done in .NET and they are looking at Javascript for the mapping. Once the query runs, the user will have the option to see the results displayed on a map. Since it is still being designed, I do have some input on the most "GIS friendly" way to have this data formatted. I'm thinking something like JSON as a format they should be able to create out of their .NET and also be able to use with Javascript.
Although the output fields may vary, there are limited geometry choices. Most queries will be county based, but a few maybe be ZIP code tabulation areas (ZCTA). I already have existing "plain" map services I've created for other projects for these boundaries.
My thought is that I should be able to create a featureLayer out of the existing map service, and somehow step through the featureSet and query the Json data to create the infoTemplate and renderer? All the examples I see discuss 'linking to an existing table'. In this scenario, there will never be a table.
If I can get to the featureSet of my featureLayer, does it help me somehow to convert it to Json? Does it make sense to create a JSON file and send to the developers and allow them to populate the attributes and bring the whole thing back in as a featureCollection? That sounds very inefficient, but that seems to be how people are managing KML data.
All this data is maintained outside the GIS environment and creating a whole series of map services to duplicate it is not an option.
