[Qgis-developer] OSM viewer plugin / "map unit" bug in core when lat-long

[Mayeul Kauffmann]

Hi,
In fact the issues 1)a,b,c,d are OK in the latest plugin (sorry).
Still there are two main problems left, the roundabout issue plus a bug
in base code (see http://trac.osgeo.org/qgis/ticket/3825)

1h. (that I forgot to mention): OSM plugin imports data as lat-long, but
while using "map unit" for the symbology the minimum value authorized by
QGIS is 0.01 degree (about 800 meters at longitude 45) which is much too
wide for any regional or city map, even for motorways. Working with map
units is the best way to have continuous zoom, and this is what I most
often do in my styles (hence with metric projection only).
So to have nice symbology with the OSM plugin, we need to reproject the
data (UTM) or to fix above bug (would be better).

I guess changing the "map unit" maximum resolution should be trivial...
but this need to be done in QGIS 1.7.0 as rules-based renderer in main
1.8.0 does not have support for symbol levels.
Is there any interest from authorized committers to support/implement
this kind of code change in 1.7.0?

(Working on the 1g), 2) and 3) steps can be done manually by the final
user, but automatizing this would be nice).

Thanks for your feedback!
Mayeul

Le jeudi 12 mai 2011 à 23:44 +0200, Mayeul Kauffmann a écrit :
> Hi,
> I would like to ask those interested in OSM viewing with QGIS, to
> contribute to an improved QGIS  viewer of OpenStreetMap data, in form of
> a python plugin and, if needed, some modification in the trunk.
> 
> Recently I received several private emails asking me to share my
> experience and/or files related to viewing OpenStreetMap data in QGIS.
> "One image is worth a thousand words"... I have just put 5 improved
> renderings of OSM data here:
> http://www.qgis.org/wiki/OpenStreetMap_data_rendered_with_QGIS
> It uses the rule-based renderer (which just received support of symbol
> levels in 1.7.0) and osm2postgresql. More details on the method used
> here:  http://www.qgis.org/wiki/Using_OpenStreetMap_data
> 
> The roadmap could be as follows:
> 
> 1. Slightly modify the existing plugin as follows:
> 
> 1a. while opening an .osm file, store the data in a format (let's assume
> spatialite, but could be other type) that allows long strings (shp/dbf
> have a 254 characters limitation)
> 
> 1b. in the spatialite files, store in a single field named "tags" all
> the concatenated tags for each feature.
> Should look like this:
> "access"="private", "amenity"="parking", "parking"="underground"
> This example is how I manage this node:
> http://www.openstreetmap.org/browse/node/989971901
> 
> (The comma can be replaced by any separator, even a space; comma is for
> readability for humans).
> 
> (Optionally here, we can drop the following tags: "source",
> "modified_by", "edited_with" and the like. The shorter, the best
> performance and the smaller the files).
> 
> 1c. remove all points that are left with no tags after dropping these
> tags (those are just vertices or noise)
> 
> 1d. store the "name" tag in a "name" field (for labelling).
> 
> 1e. do not store roundabouts as polygons but as ways (this is the most
> common problem generated by the plugin when assuming that closed ways
> are polygons; this is impossible to have a nice rendering of polygonized
> roundabouts).
> 
> 1f. put the required layers in a single group layer
> 
> 1g. automatically apply a set of .qml files
> 
> The alternative to the above (1) is to use my osm2postgresql bash script
> (this requires a linux box; the script installs the server if not done
> yet; one of its advantages is correct management of polygons with holes
> and good performance at the country level).
> 
> 2. Distribute the .qml files I created with the plugin or with QGIS (no
> idea of what is best)
> 
> 3. Distribute  with the plugin or with QGIS the icons I generated (no
> idea of what is best).
> (Optionally: ask [again] SJJB management icon authors to backport svg
> bug fixes and share related bash scripts)
> 
> Ideally: for 2 and 3, think of how people would contribute their
> alternative OSM rendering using the QGIS OSM plugin.
> 
> 
> I would really appreciate collaboration of at least one python developer
> for (1-2-3), and [if needed] of a QGIS core developer for (2) and (3).
> I have very little experience with QGIS python plugins. Since I do this
> on my spare time only (to prepare my hiking maps), without help this
> will take ages and I have little personal interest in doing so (it
> already works on my machine, so...). Also, I could put my .qml on
> rapidshare, my .svg on openclipart and my bash script to create the svg
> on the qgis wiki... but I won't, since those solutions add a lot of
> hassle in data and code management and do not deliver what I would like
> to contribute to:
> "Fast, easy and beautiful on the fly rule-based rendering of OSM maps"
> Cf. http://trac.osgeo.org/qgis/ticket/3222
> 
> I would like to spend time improving the symbology rather than coding
> the above 1, 2 and 3, hence my question: anybody interested in
> contributing to an improved QGIS OSM viewer plugin?
> 
> Thanks for reading, and thanks in advance for any answer!
> Regards,
> Mayeul
> 
> PS: If we can do the above and test it with the QGIS web client, we
> could do a killer demo at the OSM state of the map conference in Vienna
> this summer, something like: "Create your Customized Slippy Map in 10
> Minutes with QGIS".
> MK
> 
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer