Mapnik -osm2pgsql layers Thats awesome visualization!
Is it possable to create a mapnik osm2pgsql set of layers that would allow seeing just select features? I guess im talking about a wmf service. (which i barely understand) But wont that require separate hosting of the data? (or rather, a rendering of the planet that just has land & sea) where all the other features can be added with a osm2pgsql layer? (if you dont follow, thats ok) All i need to know if its technically possable :) ~ probably just requires oodles of computing power for it. Cheers, Sam On 1/22/10, Frank Steggink <[email protected]> wrote: > Frank Steggink wrote: >> Frank Steggink wrote: >> >>> Hi, >>> >>> As a bit of a challenge I've looked at the administrative data pointed >>> out by Nicolas Gignac: [1]. I know there are some doubts about the >>> accuracy, but this was also meant as an exercise to deal with this kind >>> of data. Maybe it can be reused for other purposes, although I haven't >>> written the tool I used in a generic way. I also hope that the more >>> accurate (1:20k) data uses the same structure. >>> >>> First I converted this data to SHP (with an ESRI tool called Import71, >>> and then ogr2ogr). Then it was converted to OSM with shp-to-osm.jar. >>> However, the data has a topological structure, so it has not much value >>> if it would be imported into OSM directly. >>> >>> The set of administrative boundaries contains municipalities, MRCs, >>> administrative regions (17) and urban agglomerates. The municipal data >>> contains also information about MRC, admin. regions and agglomerates, so >>> I decided to examine this further. Now the topological structure was a >>> benefit, because this is how administrative boundaries should also be >>> entered in OSM. The boundaries only contain attributes like from-node, >>> to-node, left-poly and right-poly. However, this is enough to compose >>> relationships (type=multipolygon/boundary, boundary=administrative, >>> etc.) out of them. Because I ended with an ArcInfo coverage as a result >>> of the conversion by Import71, I decided to extract data from the file >>> pat.adf to get the municipality and other relevant names, codes, etc. >>> >>> So far I have only created relationships, including the municipality >>> name. I would like to share it with you, in order to gather feedback. >>> The result can be found here: [2]. PLEASE do NOT upload this data to >>> OSM! The ways are sorted in the relationship, so they form closed >>> chains. Also the nodes where multiple ways meet have been deduplicated, >>> otherwise JOSM (and also OSM itself) won't recognize the ways as being >>> connected. The deduplication was based on the actual coordinates, not >>> the node IDs used in the topology. >>> >>> Things to do: >>> * Detect which boundary is the outer boundary, and which ones are the >>> inner boundaries. Obviously, the ring with the biggest surface area is >>> the outer boundary, and the rest are inner boundaries. >>> * Add multiple municipalities in the same relationship. >>> * Create MRCs, administrative regions, and urban agglomerates. >>> >>> More information about administrative boundaries can be found in [3]. >>> For Canadian provinces admin_level=4 should be used, for regional >>> municipalities (MRCs in Quebec) admin_level=6, and actual municipalities >>> admin_level=8. I would like to propose to use admin_level=5 for the >>> regions. They have at least a semi-offical status. Others might be able >>> to elaborate on it more. This leaves the urban agglomerates (Montreal >>> and Quebec only), for which admin_level=7 would be a natural choice, >>> although I'm not sure if they have any official status. What do you guys >>> think? >>> >>> Regards, >>> >>> Frank >>> >>> [1] >>> http://www.mrnf.gouv.qc.ca/territoire/portrait/portrait-donnees-mille.jsp >>> [2] http://www.steggink.org/osm/Quebec/quebec_munic.zip >>> [3] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative >>> >>> >>> _______________________________________________ >>> Talk-ca mailing list >>> [email protected] >>> http://lists.openstreetmap.org/listinfo/talk-ca >>> >>> >>> >> A clarification on this: "Add multiple municipalities in the same >> relationship." Several municipalities have exclaves, like outlying >> islands. They are divided over multiple polygons, so I created multiple >> relations for them. >> >> For the higher-level administrative boundaries, I intend to use >> information from the AAT file which was generated by Import71. This file >> contains records describing the boundary type. Although there is >> specific data for each level, in OSM it would be best to reuse the same >> set of nodes and ways, and that can best be done by using the same >> source data. >> >> Frank >> >> >> _______________________________________________ >> Talk-ca mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/talk-ca >> >> > > Hi all, > > The last days I've flexed my Mapnik / osm2pgsql skills, and was able to > put a visualization of the tiles online. They can be found here: [1]. > The tiles themselves are generated as transparent PNGs, so they didn't > have to be integrated into the data. Note that I also adjusted the > zoomlevels, so they are visible earlier than they would be normally. > Levels 6 - 13 are available, but the last level is still rendering as I > write this. I haven't take care of any labeling yet, although it is > present in the DB. > > Cheers, > > Frank > > [1] http://mijndev.openstreetmap.nl/~fsteggink/quebec_admin.html > > > _______________________________________________ > Talk-ca mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-ca > -- Twitter: @Acrosscanada Blog: http://Acrosscanadatrails.blogspot.com Facebook: http://www.facebook.com/sam.vekemans Skype: samvekemans OpenStreetMap IRC: http://irc.openstreetmap.org @Acrosscanadatrails _______________________________________________ Talk-ca mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-ca
