[OSM-dev] elemstyles.xml file

[Ulf Lamping]

Joerg Ostertag (OSM Munich/Germany) schrieb:
>> Sounds like a good approach. However, I just don't know how to do this
>> in the mappaint build process :-(
>>
>> BTW: Removing only the xml file from the mappaint directory will break
>> the description in
>> http://wiki.openstreetmap.org/index.php/JOSM/Plugins/MapPaint, as the
>> xml file will be missing from the style... As the icons belong to the
>> xml file (at least somehow), we could move the whole "standard"
>> directory (including xml and icons) to etc completely and fix the
>> mappaint manual accordingly.
>>     
> This would be what I'd likt to do. 
> Since gpsdrive, tiles at home, osmarender and mapnik uses partly the same/similar 
> Icons; my Idea is to move the map-icons completely to a separate 
> debian-package called map-icons or something similar. 
> The current state of the icons can be seen here:
> 	http://www.gpsdrive.de/development/map-icons.shtml
> or	http://svn.openstreetmap.org/applications/share/map-icons/
> And then make dependencies from the josm-mappaint package to this map-icons 
> package. This way we would only have to manage the icons structure once. As 
> you can see we already started 5 1/2 different themes. So everyone can easily 
> adapt the look of his map to his/her personal preferences.
>   
In the current state, the different icon sets missing different icons, 
so it's probably not a good idea to simply use e.g. only the "square 
big" theme, as lot's of icons would be missing that are available e.g. 
in the "classic" theme. So in it's current state we'll need to get the 
"best of all worlds" for a icon set as complete as possible for mappaint 
IMHO.

One solution could be to use src="square.small/accommodation/hotel.png" 
in the xml and copy the whole map-icons dir into the mappaint.jar. But 
again, I currently don't know much about the mappaint build process, so 
at least for now I simply can't do it. Another option would be to build 
a "mappaint" icon set into map-icons, but that's probably not the 
intention to keep the icons in one place ;-)

BTW: I'm a bit concerned about the icons of different trademarks like 
"Burger King", "Lidl" and alike. To prevent any legal trouble here, I 
personally would avoid using these and use generic icons instead (like 
the fast food icon).

However, I've experimented with this a bit in mappaint. First of all, in 
mappaint using any icons above the size of about 16*16 pixels is ugly 
and get's in the way of actually mapping things - and mappaint doesn't 
scale the icons automatically. Even if it would scale them 
automatically, to my experience it's often better to use e.g. The Gimp 
to scale down icons manually instead of relying on any JAVA build in 
scale algorithms, as the Gimp result will often look *much* better - 
especially for very small pictures like icons. Even using the Gimp some 
icons get's too blurred to be useful when scaled down to 16*16 pixels.

For this reason, a lot of the icons in the current sets won't fit good 
into mappaint - I don't know if that's true for the other renderers or not.


Although I know the porposed icons page, I'll start to add icons to the 
mappaint icons dir where I found they do match and looking ok. We can 
easily replace any icons later, if there is a big dispute about it. IMHO 
it's much better to have reasonable icons (that maybe not everyone 
agrees with, but can use his/her own mappaint style anyway) than no 
icons at all in mappaint. It really makes mapping a lot easier, and 
gives a much better overview what's already mapped :-)
>> The mapnik xml looks pretty different, although it serves basically the
>> same purpose. I left that over as an excercise for the interested reader
>> for now ;-)
>>     
> I talked to Artem and I think we could in the end try to do a build process 
> for all/some of these *.xml files. Where we have one master file (or set of 
> files) where we derive/build/make all  the others from. But this will also be 
> a little bit in the Future from now
Yes, with some xslt this shouldn't be too difficult - if everyone agrees 
with it to be useful.

Regards, ULFL