I am trying to generate local map tiles for US states, counties and zipcodes so that I can mark them as polygons (with different colors) on OpenStreetMap from C# Visual Studio 2013 WPF on win 7.
I am following the instructions about Bing map at:
I am tring to use thr MapCruncher make the tiles. But, I do not know how to get an image for a state, county, or zip code such that I can use the MapCruncher to get the map tiles.
I need images of them without borders because an image is normally a square with some white bounds around the state , county, or zip code polygon area.
Also, because I need to make all local map tiles for all US states, counties and zip codes. It is impossible to make them manually by the MapCruncher tool.
How to make them by MapCruncher code ? Or are there C# codes that can do these ?
get the political constraints on the project removed, so that he can use the languages in which existing tools are written;
learn not to multi-post and not to keep creating new threads; if thinks dry up on one forum cross link the thread in the new forum;
do more research on exactly what OSM is.
There are occasions where there is a sufficient shift in emphasis that a new thread is needed, but the old thread should cross-linked to provide context and avoid repeat answers. I’m not convinced that even that is needed here.
if you want to work with OSM data you should use OSM data.
“Thematic Maps from Bing SDS” is not related to OSM. Please contact Microsoft/Bing or someone else outside from OSM if you are planning to user Bing data.
It should also be pointed out that you’re starting from a faulty premise by wanting to render ZIP code polygons. ZIP codes aren’t organised into polygons. They’re either lines (ways) or points (nodes). This site gives a summary of how ZIP codes are organized. As such, you won’t be able to find any ZIP code polygons in the OSM database. It looks like there may be some outside sources that synthesize artificial polygons from ZIP code data, but you’d likely need to do some massaging of the data to merge it with the administrative boundary data from OSM.
You should not merge ZIP-data with Admin-data, because it is not garantied that they match to 100%. In many countries postal services are private companies and they don’t care about admin boundaries (any more). It is “their realm” and they set the “boundaries” as they need them. We have ZIP-boundaries splitting cities, or some cities together in one zip-area - exept of one street, which belongs to another area. Just as the company needs it.
regards
walter
btw: The USA have 7 (seven) ZIP-Boundaries in OSM, if i remove duplicates i find only 3 or 4.
@usact: Did you manage to get the admin boundaries from OSM? As a first step?
@wambacher, My major concern is how to efficiently manipulate the map tiles (fetched from OSM server) by adding administration data on map tiles, the data may be zip code boundaries and then colorize them as colorful polygons on the map.
When the map is zoomed and panned, I have to make sure that the performance is acceptable in the case of a large of data needs to be added to the map tiles. For example, the boundary data of 50 states, 3k+ counties and 30k+ zipcodes in USA. These may make the performance very bad if the map tiles cannot be manipulated efficiently.
Adding polygons (the adm. boundary data) as UIElement in WPF is not a solution in the case of large data set.
I need a code example (C# Visual Studio 2013 WPF) about how to do this.
Those are German postal code (Postleitzahl) boundaries, not ZIP code boundaries. ZIP codes are specific to the United States and their territories. If you ignore the handful of improperly-mapped boundaries that you found in the database, my statement is true.
Both PlZ & ZIP are postal codes, but they are constructed in entirely different ways: the former is based on an area, the latter is based on a common group of (not necessarily contiguous) addresses. Canadian & British post codes have similar properties. The new Eircode’s absolutely cannot be represented as areas at the most granular level.
Of course it is convenient to represent non-aeral postal codes as areas, and this works most of the time, because address grouping into postal codes in based on postal rounds and mail volume, but it is not an intrinsic given for the dataset.
Either way, the OP will struggle to get an answer for this reason, and also for not following up the previous responses regarding OSM.
At least in the UK, I think the reason that people tend to assume ZIP and postcode are the same thing is that so many online forms ask for ZIP code, when they actually want the postcode, because the software was designed just for the US market.
In the UK, postcodes can certainly constitute single building islands within another post code, or even be simply post box numbers, or codes, like the BX? ??? series, which have no fixed geographical meaning, at all.
