Re: [OSM-dev] Improved text rendering in Mapnik
Hermann Kraus-2 wrote As my Google Summer of Code project I worked on improving Mapnik's text rendering. The most important change was adding support for complex scripts, but I also implemented some other nice features. You can read more about my work here: http://mapnik.org/news/2012/10/06/gsoc2012-status9/ Build instructions are included and I would like to hear about your success stories, but bug reports are also welcome. Hi, thanks for this great bunch of features. I especially like the possibility to label boundaries correctly with the displacement parameter. Unfortunately this feature has the side effect that the displacement parameter now depends on line orientation and thus breaks my style where I use the displacement parameter to move labels that they appear above the lines. I would like to see an option like line-orientated-displacement=false or similar to get the old behaviour back if you need it. Best regards, Melchior -- View this message in context: http://gis.19327.n5.nabble.com/Improved-text-rendering-in-Mapnik-tp5730315p5730343.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] (Multi)Polygon handling
Peter Körner wrote good start but I'd remove the .wkb files in favor of the wkt ones. You shouldn't have two versions of the expected output or you will get cases where the WKB and WKT differs. And it's unclear what the real expected result is. At the moment the .wkt and the .wkb files contain exactly the same geometry so you can either compare against the .wkb or the .wkt file. They may only get out of sync when people change the expected result and forget to change both files, but I think this is a rare case that we can then solve from commit history. -- View this message in context: http://gis.19327.n5.nabble.com/New-OGR-driver-to-read-OpenStreetMap-osm-pbf-files-tp5715906p5720533.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
[OSM-dev] (Multi)Polygon handling
Frederik Ramm wrote If we can't get everyone to use the same code base, then it would at least be great to reach some kind of agreement here, or maybe at least produce a test suite that everyone runs their code against. I created a testsuite for that with some more cases that need special treatment. Unfortunately I only stored the WKB representation in Google mercator projection, so it is not very human readable. The testcase contains a LINESTRING and a MULTIPOLYGON for simple closed ways and for relations a MULTILINESTRING and a MULTIPOLYGON ([1]). I would volunteer to bring it in an other format so that it is useful for everyone writing converters and I would like to discuss what is the best way to do it. I would suggest an .osm file and a Wiki Page containing the expected results in WKT/WKB and some explanation for each case. Any other ideas? Best regards, Melchior [1] https://dl.dropbox.com/u/58628/polygonizer.cpp -- View this message in context: http://gis.19327.n5.nabble.com/New-OGR-driver-to-read-OpenStreetMap-osm-pbf-files-tp5715906p5716408.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] (Multi)Polygon handling
Jochen123 wrote Just the geometries is not enough. We also need the tags in some form, because part of the multipolygon assembly is deciding which tags from the relation and which tags from the member ways make it to the output. I thought about focusing on geometry first since this is the more complicated part. But sure for tags it gets very complicated if we consider diff files too. Jochen123 wrote Input as .osm is good. But the output should not be on a wiki page but in some format so that it can be used for automated checks. I think the whole thing should probably be in a git repository. Maybe a subdirectory for each test case which contains the .osm input file, a .wkt output file, a .tags output file and a .result output file or so that has information whether the test should succeed or fail. Maybe other files, too with more detailed information if that turns out to be needed. Plus a README in every directory describing the test case to the developer. I like that idea. With the directory structure we can add .osc file to the directories as well so that we can check proper diff file handling after the initial import... I will try to get something like that ready as a demo -- View this message in context: http://gis.19327.n5.nabble.com/New-OGR-driver-to-read-OpenStreetMap-osm-pbf-files-tp5715906p5716442.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] (Multi)Polygon handling
I did a first commit on github containing a testsuite for invalid geometries formed by closed ways and their expected repaired version [1]. If you are happy with the format, I would continue with the invalid multipolygons... I would suggest to have the tag tests in a different test suite (a new directory), so that we don't get confused about objects having invalid tagging and invalid geometry at the same time. Melchior [1] https://github.com/nimix/osm_conv_tests -- View this message in context: http://gis.19327.n5.nabble.com/New-OGR-driver-to-read-OpenStreetMap-osm-pbf-files-tp5715906p5716461.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] (Multi)Polygon handling
Even Rouault wrote 2) valid Why do you need to reverse the winding order ? I thought that the WKT convention did not say anything about that, or did I miss something ? (Winding order is indeed significant in shapefiles, but that's another story). So I'd say it is up to the rendering engine to do any transformation that is needed for correct rendering according to the filling algorithm it uses. If I remember it right mapnik requires normalized geometries, so outer in clockwise and inners in counterclockwise order. I'm not sure if that is still the case, but osm2pgsql still does the normalization. That's why I defined the result in clockwise orientation... -- View this message in context: http://gis.19327.n5.nabble.com/New-OGR-driver-to-read-OpenStreetMap-osm-pbf-files-tp5715906p5716503.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] (Multi)Polygon handling
Jochen123 wrote I think I agree with your here. Whether a simple polygon is valid or not that tells us the Simple feature definition. Software that turns single ways into single polygons should only look at one thing: If the way is closed, it is porentially a polygon and can be converted to one. The conversion is straightforward and easy. The software is not supposed to fix ways that might result in invalid polygons. The result is a Simple Feature polygon and if some application wants to check whether a polygon is valid, it can do so. If it is valid, the way was valid, if not, then not. The case for multipolygons is different. Here there are several ways and a relation involved. It is much more difficult to assemble the raw data into a multipolygon. What we want to agree on is how exactly this assembling is done. It might be if you follow the assembling process exactly the result is an invalid multipolygon. Thats okay. We are not trying to make sure there aren't any invalid geometries generated. We are trying to make sure we agree on the result of the conversion process, may it be a valid (multi)polygon or an invalid one. Ok so, we can agree that in the closed way testsuite everything except 1,2 is invalid. I added .result files indicating that to the repository. But I don't like the idea to define the expected output to invalid geometries. There should be either a reasonable result or nothing. Otherwise it is impossible to have a repairing algorithm passing the test... Just a minute ago a also added a testcase for geometry output of multipolygons. Again we need to discuss which cases are valid and which are not. So far my opinion is: 1-3, 6-8 valid 4-5, 9-10 invalid Again for those not willing to look into github. I am talking about multipolygons in [1] from bottom to top. [1] https://dl.dropbox.com/u/58628/multipolygontest.osm Regards, Melchior -- View this message in context: http://gis.19327.n5.nabble.com/New-OGR-driver-to-read-OpenStreetMap-osm-pbf-files-tp5715906p5716524.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] (Multi)Polygon handling
Frederik Ramm wrote On 07/13/2012 04:59 PM, nimix wrote: If I remember it right mapnik requires normalized geometries, so outer in clockwise and inners in counterclockwise order. I'm not sure if that is still the case, but osm2pgsql still does the normalization. That's why I defined the result in clockwise orientation... Mapnik doesn't require that as far as I know (have to check though). However, if you e.g. create a shape file and open that in ArcGIS and compute the polygon area, it will come up with negative areas if your polygon goes the wrong way round. Hi, I just has a look at this... Mapnik indeed has no such requirement. But it requires inner rings of multipolygons do be in a different orientation than the outer ring. Hence it is reasonable to ensure that by just making all outers cw and inners ccw. -- View this message in context: http://gis.19327.n5.nabble.com/New-OGR-driver-to-read-OpenStreetMap-osm-pbf-files-tp5715906p5716533.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Rendering of Cliffs using mapnik-cairo?
Hi, I had such isues when using Ubuntus default PDF reader. Have you tried to load your files with adobe reade? That solved the problem for my files. Unfortunately I don't have a pc with the adobe reader right now, where I can try it. Best Regards, Melchior -- View this message in context: http://gis.19327.n5.nabble.com/Rendering-of-Cliffs-using-mapnik-cairo-tp5574167p5575603.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] osm2pgsql patch for nested relations
Hi Michael, As far as I can see there are two problems with your implementation. You assume that the nested relations are already processed at the point when the master relation is processed. Unfortunately this is not always true, because there might be relations that have members with a higher id than their own id. Another thing is that I think index creation is the last step of the import process so the update statements would consume a lot of time... Best regards, Melchior -- View this message in context: http://gis.19327.n5.nabble.com/osm2pgsql-patch-for-nested-relations-tp5514911p5515191.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Haiti need: GetLatLon for OpenStreetMap
Hi, I think OSMify will help you. It lets you add the OSM-Layers to getlatlon.com Link: http://blog.johnmckerrell.com/2007/12/31/new-version-of-osmify-bookmarklet/ Regards, Melchior Mikel Maron wrote: Thanks all for the suggestions, but slightly miss the ease of use for this task of GetLatLon ... it's a pretty subtle usability issue that's important for newbies and people doing a lot geocoding *there's a visible cross in the center (to be certain of the position) *the latlon is easy to cut and paste front and center *the latlon depends on the position of the map, not the mouse position. -Mikel == Mikel Maron == http://mapkibera.org/ +254 (0) 724899738 mi...@osmfoundation.org From: Mikel Maron mikel_ma...@yahoo.com To: dev@openstreetmap.org Cc: si...@simonwillison.net Sent: Sat, January 23, 2010 10:15:54 AM Subject: [OSM-dev] Haiti need: GetLatLon for OpenStreetMap Ushahidi, and others, are geocoding reports via OpenStreetMap. We want this to be as easy and accurate for them as possible. GetLatLon (http://www.getlatlon.com/) is a nice little site to do this, but uses Google Maps. Would someone be able to clone the site to use OSM, centered on Haiti? Thanks Mikel == Mikel Maron == http://mapkibera.org/ +254 (0) 724899738 mi...@osmfoundation.org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- View this message in context: http://n2.nabble.com/Haiti-need-GetLatLon-for-OpenStreetMap-tp681p4445565.html Sent from the Developer Discussion mailing list archive at Nabble.com. ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
