[OSM-dev] Units in the Mapnik .xml file?
ulf.lamping at web.de
Thu Nov 1 15:57:32 GMT 2007
Dave Stubbs schrieb:
> On 01/11/2007, Ulf Lamping <ulf.lamping at web.de> wrote:
>> When I add such stuff to an xml file (I've done a similiar approach with
>> JOSM's mappaint plugin) I have a look which features are similiar, have
>> a look at how they do it in the xml and then think about why it's that
>> way. Maybe I take the same way of doing things and maybe I take a
>> different approach - but I have a look at the xml file first (and not
>> the map!).
> That's all fine if you are trying to display data. If you're trying to
> create a nice looking map then failing to look at it causes problems.
> You don't seem to be distinguishing between the two activities.
Well, my thought was about where to look *first* - of course you'll have
to look at the map to verify. But if you look at the map first, you tend
to miss similiar features (not in your current "clipping range") that
should "behave" the same way as the stuff you want to add.
>>> There is no reason at all to care about the scale
>>> at that point.
>>> The current situation is (IMHO) a barrier to entry
>> NO!!! The real entry barrier is a lot of people with IMHO strange
>> opinions how things should be. I remember something like: "We don't want
>> to have too much details in the map - even at zoomlevel 17" is one of
>> the reasons that completely drove me away from doing anything in the
>> osmarender / mapnik regard. We don't want to have several different maps
>> at osm.org (which I agree because of maintenance effort and processing
>> power) but we also don't want to have that level of detail on the osm
>> map - so how do we show to other users all the data osm already provides?
> There's certainly been a general dislike of putting /everything/ onto
> the tiles.
By the persons who want to see a nice looking map or by the persons who
track/map stuff and want to see their work on the map? ;-)
> It's excessive for a general purpose tile-set. The correct
> way to do this is create speciality tile-sets which represent some
But that's exactly what most people are not able to do.
If we had several different OSM maps already, that are emphasized on
specific things to show all aspects of OSM data I would perfectly agree.
But we currently have two more or less identical maps that both lack to
show lot's of OSM data.
If we would have one map to be "nice looking google maps clone" and the
other to be "show me all that we have - at least at the highest
zoomlevel" I would be perfectly ok with it.
But where's the map today, that enables all the mappers to see the work
that they have done?
> There is no way an online tile renderer is going to be sharing rules
> with a GPS. For a start you are probably going to want to use some
> completely different data.
What makes you think a "moving map" application (like gpsdrive) will
need a completely different set of rendering rules than our mapnik layer
(at least as a start)?!?
Especially when they are going to use mapnik for rendering?
In the long run they may build up their own set of rules and that's
fine. But for a start they will have it easier to build the application
with the same rules file as OSM and we will hopefully have more OSM
applications around. Which we are really missing IMHO.
>> Oh yes, I forgot the usual OSM answer: it's their problem and not ours
>> ... ;-)))
>> Regards, ULFL
>> P.S: Some time ago, I took a deep look at the mapnik and osmarender xml
>> files. The mapnik file looks ok and the osmarender files (BTW: there are
>> far too much of them) looked like a hideous ugly hack that desperately
>> needs a cleanup. So going the"osmarender way" is not the way I would
>> like to go ...
> >From such a deep look you seem to be making randomly sweeping generalisations.
> All the suggestion that was made is intending to do is be able to
> write something like "z13" rather than some "arbitrary" number. I
> think that is a great idea.
It's a step in "closing up stuff" into the "OSM only world" and don't
care what's going on around us. I've already mention the usual OSM
answer: "it's their problem and not ours"
What I basically wanted to say with the example of xml editing: The
problem is not the xml syntax, but the general disagreement of what
should go into the file - and this problem actually slows down
development. And tweaking the syntax won't help a lot with this problem.
Obviously this change will make the xml editing a bit easier. But as I
said before, I don't have a real problem how to put stuff into the xml,
the problem always is: which stuff.
More information about the dev