ThinkGeo.com    |     Documentation    |     Premium Support

Street based Shapefiles as a FeatureLayer

#1

Can you guys point me to some good example code that tells how to properly add street-based shapefiles to overlays?


What I would like to do is have code that reads in a shapefile, determines whether it is for major roads or secondary roads, sets the style appropriately, and adds it to the overlay.


I've played with this using the austinstreets.shp file in your example data directory, but can not get it to display anything.  I do get the united states to show up, and can remove that layer, but not the streets.  After several experiements with different styles and covering all 20 zoom levels, still no luck.


What I want to know is the following:



        
  • What features are relevant to streets?  I understand there are FIPS codes for US maps, but what about other countries in Europe, Africa, and Asia?

    •     
  • I know your world map database product covers the world, but how far down does it go in streets?  The online sample only seems to go down to major roads for non-US places.


What I'm trying to do is create a default background that has the basics: ocean, continents, countries, major roads (when zoomed out), middle roads (farther in), secondary roads (zoomed in a lot), rivers, and railroads.  What I think I need to accomplish that is a switch type statement in my shapefile reading function that uses the features it finds to figure out what the shapefile has in it.  It is too bad shapefiles are so lame -- they are too basic -- they should have classification that is globally consistent -- but I'm sure most of us think that.


Any help you can provide on this would be of great benefit to me.  I'd like to know the answer for generalized shapefiles from many sources AND how you would do it if I'm using your world map database.



#2

 


Brian,
 
I have created a sample attached. I use ValueStyle to determine how to render the Austinstreets shape files, I don’t attached the data and MapSuite DLLs, because you can find them in the installation folder.
 
The austinstreets can use CFCC to relevant to different type, about other data you can ask your data provider, even the data is represent the same area, it still would use different field to represent different type.
 
Our world map database covers the whole world, but if you want to go down and see detail, I am afraid that you only can look at part of North American.
 
The key of the street based shapefiles is that how to determine which field is the road type, one way is ask your data provider, the other way maybe you can do it yourself. We have a tool called MapSuiteExplorer in your installation folder, you can use it to view shape files, and also you can show features, it will be shown as a data table, you can look at each field, maybe it’s obviously which filed is road type.
 
I am not clear what your detail requirement, so after you research, you can let me know and I will answer your question to help you finish your application.
 
Thanks
James 

1560-StreetBasedShapeFiles.zip (11.4 KB)

#3

Brian, 
  
   We have a product called the World Map Kit and it has exactly what you are talking about.  We call them base maps and they cover the entire world.  We have simple coverage for most place and high detail for the US & Canada.  When you license the product you get the complete source of all the renderers.  This will for sure save you a bunch of time as we spent quite a bit into making nice renderers.  We have also modified the code, based on some great user feedback, to allow you to add and remove detailed state roads if you don’t need them.  This means you can have a general map of the world and then add the detail just for the states you need and cut down on the data size you may need to distribute. 
  
   You can see exactly what you would get, minus the geocoding, by going to maps.thinkgeo.com  
  
   Let me know if you have any questions. 
  
 David

#4

Thanks for the help with the StreetBasedShapeFiles example.  The example code with the WorldMap was even better.


HOWEVER, neither quite fit the need.  I am quite sure that I am not the only one that has this need.   Let me explain.


Both of your methods basically have hard coded styles based upon filenames or directory path names in the case of your WorldMap.  Then, when you apply a set of styles to each layer to make it look right (i.e. which zoom levels to appear, what color, what size, what font, etc.).


What I would hope for instead is a ThinkGeo class that can perform shapefile classification using not just filenames, but also the meta data in the shapefile.  One other problem is that if a given shapefile has streets for a small country in one shapefile at multiple levels of detail.  For example, NavTeq tends to do this, so you would have to query a single shapefile to create about 5 layers that come in at the appropriate zoom levels.  If you do not do this, then you have too much data at too many zoom levels, resulting in more than 25 seconds of rendering time -- way too long.  Ideally your class would do the following at a minimum:



        
  • Classify a shapefile at a high level as Road, Boundary, Water, or Label (i.e. an enum)

    •     
  • Sub-Classify the shapefile as level of detail 1 thru 5, where 1 is international, 2 is country, 3 is state, 4 is county, 5 is city, 6 is rural (i.e. another enum)

    •     
  • With the classifications above, return a ShapeFileFeatureLayer that has the proper zoom levels, colors, and size

    •     
  • Support the two major commercial world mapping vendor formats: NavTeq and LeadDog

    •     
  • It would also be VERY nice to be able to import the above classifications into an Microsoft SQL Server 2008 Spatial database, so we don't have to read and parse shapefiles (which are a lousy format).  Ideally, in code -- not scripts.


I have started to do the above in one enum (e.g. Road1, Road2, ..., Border1, Border2, ... City1, City2, ..., Water_Ocean, Water_River) but it is a big job.


Does that help?  I think this would add tremendous value to your product line.  With it, your WorldMap provides a nice foundation, which can be supplemented by user acquired data that goes on top.



#5

Brain,


Thanks for your post and suggestions.
 
I read through this thread and I thougth you are very gooding at GIS aspect and you did a good suggestion on it. While personally I think MapSuite product is a Mapping middleware up to now which aims to help develpers build a mapping application quickly and easily, what we are strong is not at the data, in fact, all our sample data is from Tiger data which probablly somehow is not so detailed and accuate with NaveTeq.
 
Thanks for your suggestions, we will double think about it to see how far we can go in this way.
 
Thanks.
 
Yale

#6

Thanks Yale,


I think you can retain your focus on the GIS middleware, but you could add a lot of value by classifying the data you already have better.  I did this by myself in about 2 weeks.  It is nice, because I can click on 'Road2' and it will automatically select all the shapefile layers from the WorldMap that are at the 'State' level.  Then I can turn them on or off as a group.  I can also decide whether I want them loaded at all.  If I were to do it again, I might provide another layer of classification such as 'Road' which groups Road1, Road2, Road3, ... Road7 similarly.


This allows me to easily tailor what types of shapefiles from the WorldMap are loaded on application startup.  I've also made class-based styles instead of individual hard-coded shapefile based styles as you guys have done.  It makes life easier, and provides for a more consistent presentation.  In your sample, you have several very similar styles repeated in the code.


Also, I do not think you need to support the maximum degree of detail provided by someone like NavTeq to start.  I would focus on the basic country, state, and county level to provide interstate and state roads, rivers, major lakes, and town names.  For most GIS applications, this would be great -- especially if it were worldwide.


I do think you should split up your data by continent, at a minimum as well.  If  you imported all of your shapefile data into an instance of a SQL Server 2008 database (PLEASE PLEASE DO THIS), then you could do even better, since you would query down to the country or county easily, especially if you forced yourself with a good structured database model to classify each shapefile based upon continent, country, county, type (e.g. road, river, water, boundary, etc.).


The above would only take a good developer about a month, and I think it would help you crush your competition.



#7

Brian, 



You did a great job, and your suggestion is very impressive. 



That's might be worth trying, I think that would work. 



But I am not 100 percent sure we will implement it Immediately. You know, every our project has a main plan. So we need consider some detail things of your idea and then decide whether we will do or not, we will let you know if you make any conclusion.



Thank you again.