[OSM-dev] central elemstyles/MapFeatures.xml

Joerg Ostertag (OSM Munich/Germany) openstreetmap at ostertag.name
Mon Nov 6 23:58:29 GMT 2006


On Monday 06 November 2006 22:57, Dubravko Penezic wrote:
> Hi Joerg,
>
> if I understand correctly You sugest to put two files in one like is
> now in osmarender ?

Well not exactly. I wanted to suggest to merge at least 2 files which are 
almost identical. The main difference is:
		data/elemstyles.xml	data/freemap.xml
Main section	<rules>			<ruleset>
Line 		<line 		 	<style 
		colour="#c08000"	colour="255,0,0"
		width="1"		width="0,0,0,0,0,0,0,0,0,0,1,1,1,1,1"
					dash="2,2" 
					z-index="2"
images		<icon 			<style
		src="station.png"	image="images/pub.png" 
		annotate="true" 	text="-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,0,0,8,8"
Additional Tags				<gpsmapcode>
					<gpstype>

I only would like to have both renderers mapfeatures.jar and freemap.php use 
the same rendering and coloring rules.
And I'd would add some more details like scale-min/max for rendering. This is 
almost all. The description_de-stuff is only optional. These small changes 
would enable us to have one central rendering rule as basis for all osm-based 
rendering applications.
I must admit that this idea came when i tried to understand the MapFeatures 
Page on the wiki and didn't really recognize a scheme behind it. So i had a 
look at how other programs do it and found that freemap.php and 
mapfeatures.jar did it a similar way. And that these files would be a good 
start for me to use in gpsdrive and osm-pdf-atlas. But what I don't want to 
do; is to invent the wheel another time or set on the wrong horse(file ;-). 
So My first effort now lies in getting a consensus about a central file 
defining a default rendering scheme for the osm-data.

> I dont think it is good idea.

Well I do think combining two almost identical files to one common file is a 
good idea if you look at it from the perspective of maintenance and 
consistency. But for this we would have to make some small changes to 
one/both of the renderers. And to make it usefull we would have to 
add the scale-min/scale-max tag. Since rendering without it then might look 
like this:
	http://www.ostertag.name/osm/maps/pdf_atlas/thumbs/TN_osm_atlas-UK-24.png
And I am sure almost every renderer get this problem as soon as he tries to 
zoom out a little bit.

> Right now If I would like to have separet color schema for rendering,
> I must change everything in osm-map-features.xml file and lost
> originaly set colore.

If you really-really want to have different rendering style in this file your 
rendering engine could handle not only the first matching rendering rule, but 
look for the first rendering rule which has an additional tag 
<renderingstyle>your-special-style</renderingstyle> set. 
What do you think about this. This way you could tell your rendering engine to 
adapt to different style with simply switching renderingstyle on the 
commandline or in a config file.
You can even define that you want to use another icon-set by simply specifying 
another icon source directory. This is already prepared in the directory 
	http://svn.openstreetmap.org/map-icons/
You can also find all these icons compared under:
	http://www.ostertag.name/gpsdrive/icons/index.html
I think these three possibilities would give enough flexibility to render maps 
in something like a user-style.

> That are very unpractical. But if you include style file like a link
> in osm-map-features.xml , that will help a lot. With simply
> configuration on begining you may change color schema, same is with
> taging file.

I think we are miss understanding each other. What I wanted to suggest was 
kind of a style definition file. And if you want to change colors for your 
particular needs you'll either have to change it in a local copy of this file 
or implement an overwrite mechanism (b.t.w. this would be method 3 of 
above ;-) in your application to do this.

-

Joerg



> On 11/6/06, Joerg Ostertag (OSM Munich/Germany)
>
> <openstreetmap at ostertag.name> wrote:
> > Hi,
> >
> > Is there a chance, that we combine the functionality of the elemstyles
> > and mapfeatures files? I think this would be very important to save very
> > much time.
> >
> > So I would really need (positive ;-) __ FEEDBACK __ from all developers
> > which are working at any kind of rendering engine for OSM-Data.
> >
> > For the first I would suggest that every Programm needing to do
> > rendering, does use a file placed at
> >         http://svn.openstreetmap.org/data/MapFeatures.xml
> > This file must have a content which can be completely parsed by any
> > normal XML::Parser.
> > I think the two files
> >         data/freemap.xml
> >         data/elemstyles.xml
> > are a good start. But I'd like to only have one central MapFeatures file
> > which is used as a basis for all editors and renderers. This way all
> > OSM-Maps have the same look and feel. All Editors would base on the same
> > taggin-scheme, ... And not everyone who does rendering code has to write
> > his own
> > elemstyles/mapfeatures/rendercontrol/... .xml-File. I want to use this
> > file too for gpsdrive and osm-pdf-atlas. I already did some tests with
> > osm-pdf-atlas and I managed to add icons to the pdf. But I think it
> > doesn't make sense to start a new MapFeatures.xml file for osm-pdf-atlas
> > (or gpsdrive).
> > So this is one more reason, why I'd like to have one central
> > MapFeatures.xml File with all the rules in there.
> >
> >
> >
> > I think using the Format of the data/freemap.xml File seems like the
> > easiest start.
> >
> > I then would add some more tags:
> > description_en: International english description
> >                 manatory
> > description_uk: British english description
> >                 optional
> > description_de: German description
> >                 optional
> >         .... other languages by there country code ...
> >
> > country: The country where this feature is primarily used.
> >         If you don't specify any it's used worldwide.
> >
> > I would then move the rendering stuff to a subkey 'rendering'. Every rule
> > can hold more than one of these '<rendering>'-keys. This would be used to
> > have different rendering rules for different scales.
> > In the example you would show the icon and an annotation for the lower
> > resolutions(1:1 ... 1:10000). These annotations would be the tag name=...
> > and the tag regioncode=... .
> > But if you want to render an overview (scale 1:10000 ... 1:100000)you
> > would only render the icon without any text.
> >
> > <mapfeatures>
> >  <rule>
> >   <condition k="class" v="suburb" />
> >   <country>de</country>
> >   <poi_type>city.small</poi_type>
> >   <description_en>Suburbs smaller than 1000 people</description_en>
> >   <description_de>Suburbs smaller than 1000 people</description_en>
> >   <description_gb>Suburbs smaller than 1000 people</description_en>
> >   <description_long_en>All Suburbs smaller than 1000
> > people</description_en> <rendering>
> >     <scale_min>1  </scale_min>
> >     <scale_max>10000  </scale_max>
> >     <icon annotate="name,regioncode" src="place.png" />
> >   </rendering>
> >   <rendering>
> >     <scale_min>10000  </scale_min>
> >     <scale_max>100000  </scale_max>
> >     <icon src="city/small.png" />
> >   </rendering>
> >  </rule>
> >  <rule>
> >         ...
> >  </rule>
> > </mapfeatures>
> >
> > --
> > Jörg (Germany, Munich)
> >
> > http://www.ostertag.name/
> > TeamSpeak2: ts2.ostertag.name, user: tweety, Channel: "GPS Drive"
> > irc://irc.oftc.net/#osm
> > Tel.: +49 89 420950304
> > Skype: skype-1106 at ostertag.name
> >
> > _______________________________________________
> > dev mailing list
> > dev at openstreetmap.org
> > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev

-- 
Jörg (Germany, Munich)

http://www.ostertag.name/
TeamSpeak2: ts2.ostertag.name, user: tweety, Channel: "GPS Drive"
irc://irc.oftc.net/#osm
Tel.: +49 89 420950304




More information about the dev mailing list