Re: [OSM-talk] simplifying mapnik layout definition
On Tue, May 27, 2008 at 04:40:58PM +0200, Andreas Barth wrote: > (Long-run should be to use parameters IMHO, so that we can just say > "stroke-width has that size in relation to the scale" - but that's for > another day) Merkaartor has pixelsize-width = estimated-real-width * factor + offset. This seems to work well across a large number of zoom views and I think it would make sense for real map render applications too. cu bart ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
* Andreas Barth ([EMAIL PROTECTED]) [080527 23:40]: > I have now put a bit of that stuff together. > > > All files (including sample code) is at > http://alius.ayous.org/~aba/osm-formater-1/ As I didn't get any comments, I assume that this solution doesn't fit the needs and I'll not follow it further. Cheers, Andi ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
On 27 May 2008, at 18:29, Robert (Jamie) Munro wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Andy Allan wrote: > | Now, if someone is volunteering to make a concise definition format > | that can be pre-processed into the mapnik XML format (or mapnik > python > | code, or even just read by a modified mapnik directly, or whatever) > | then I'd absolutely love to SEE THE WORKING CODE. That osm.xml is an > | unwieldy beast isn't in question, nor are the myriad of > possibilities > | to improve it - what is lacking is working alternative. > > IMHO in this case, the code is the easy part - it's designing a good Ah, we just have to solve the much smaller problem - the definition of 'good'. Best Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
What about using the Python bindings and actual Mapnik objects to create the XML file? It should be able to save an XML file, and that way you can abstract out all of the XML text from your program too... Beau On Wed, May 28, 2008 at 3:05 AM, Steve Hill <[EMAIL PROTECTED]> wrote: > On Tue, 27 May 2008, Andy Allan wrote: > > > Now, if someone is volunteering to make a concise definition format > > that can be pre-processed into the mapnik XML format (or mapnik python > > code, or even just read by a modified mapnik directly, or whatever) > > then I'd absolutely love to SEE THE WORKING CODE. That osm.xml is an > > unwieldy beast isn't in question, nor are the myriad of possibilities > > to improve it - what is lacking is working alternative. > > For OpenPisteMap I create the XML using some PHP code: > > https://public.subversion.nexusuk.org/trac/browser/openpistemap/trunk/scripts/mktemplate.php > > I've not converted the entire XML file yet, and I don't pretend it is a > universal solution, but I find it easier to work with than the raw MapNik > XML file. > > It would be nice to have some kind of cascading language so that styles > can be defined for each object at the top level and then modified for each > zoom level, but I suspect no one has the time to do it (I certainly > don't). > > - Steve >xmpp:[EMAIL PROTECTED] <[EMAIL PROTECTED]> > sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]> http://www.nexusuk.org/ > > Servatis a periculum, servatis a maleficum - Whisper, Evanescence > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk > ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
On Tue, 27 May 2008, Andy Allan wrote: > Now, if someone is volunteering to make a concise definition format > that can be pre-processed into the mapnik XML format (or mapnik python > code, or even just read by a modified mapnik directly, or whatever) > then I'd absolutely love to SEE THE WORKING CODE. That osm.xml is an > unwieldy beast isn't in question, nor are the myriad of possibilities > to improve it - what is lacking is working alternative. For OpenPisteMap I create the XML using some PHP code: https://public.subversion.nexusuk.org/trac/browser/openpistemap/trunk/scripts/mktemplate.php I've not converted the entire XML file yet, and I don't pretend it is a universal solution, but I find it easier to work with than the raw MapNik XML file. It would be nice to have some kind of cascading language so that styles can be defined for each object at the top level and then modified for each zoom level, but I suspect no one has the time to do it (I certainly don't). - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Barth wrote: | * Dave Stubbs ([EMAIL PROTECTED]) [080527 18:01]: |> I don't think inferring the LineSymbolizer is a good idea. But if you |> want to write a preprocessor to do the scale extraction I think that |> might help a lot. | | ok - though it might happen I'll fiddle with it anyways for start. Let's | see ... | | |> Personally I'd like to see an end to the XML syntax as it's hard to |> read, but that's more work than it's worth right now (to me at least). | | Any better idea than xml in your mind? Going away from XML might be an | option, but none I'll probably start with (simply for the ease of | getting started). How about YAML? You could either write a script to convert YAML to XML, and use the XML as normal, or possibly you could write a python script that read the YAML and built the styles in mapnik directly as in: http://trac.mapnik.org/wiki/GettingStarted PyYAML (http://pyyaml.org/wiki/PyYAML) is really simple to use. You feed it python lists and dictionaries containing each other, and it outputs YAML code, which is easy to read and easy to edit as long as you are careful with the whitespace (like python). Feed it YAML code and it returns lists and dictionaries. Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg8nTUACgkQz+aYVHdncI29mgCgrD/zYFV0lX3PYTIDgNYXP01P AqsAn2NoU5OqWFbwpuQ7tG4rkzdFJhrw =FDPf -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
On Tue, May 27, 2008 at 6:29 PM, Robert (Jamie) Munro <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Andy Allan wrote: > | Now, if someone is volunteering to make a concise definition format > | that can be pre-processed into the mapnik XML format (or mapnik python > | code, or even just read by a modified mapnik directly, or whatever) > | then I'd absolutely love to SEE THE WORKING CODE. That osm.xml is an > | unwieldy beast isn't in question, nor are the myriad of possibilities > | to improve it - what is lacking is working alternative. > > IMHO in this case, the code is the easy part - it's designing a good > format that is hard. It has to be actually easier to read and edit in > general, rather than easier for whoever designed it but just as hard (or > even harder) for everyone else. > > Whether it should be discussed here or in Mapnik's lists depends on if > the format will be generally useful, or specific to open street map's > needs - perhaps it will be tied intimately to our system of tags. > Perhaps the format could be used to generate osmarender formatting at > the same time. > > If we can agree some basic ideas for how the format should work, and > what won't work, someone may come along and try to implement it. If you > just say "go away until you have finished the whole thing" every time, > it's not surprising people don't write anything because they have no > idea where to start. I don't think this how it works. You don't have to "go away until you have finished the whole thing". What you have to do is think about the problem for a little longer than 15 minutes, come up with a reasonable starting point for an idea, and prefix the whole e-mail with "I'm going to do some work on making the mapnik style sheets easier to read and understand. This is my initial idea, does anybody have any comments or sugestions before I get started (just to check I'm not wasting my time)?" This simple formula takes a pie in the sky "wouldn't it be good if" massive waste of time into the makings of a useful discussion. The trick then of course is to ignore all the people suggesting you create an uber GUI to unify mapnik and osmarender using the one true formatting technique will all the bells, and just concentrate on the useful feedback to make sure you're not going to be wasting your time. You can then go away implement a first step, come back on the list and ask for further feedback. If you consider all of that a distraction then you can of course skip those steps and just do it and convince people they like it (probably not difficult if you do something useful). What's not going to happen is us all discussing the perfect style sheet format with the vague hope that at the end of it all someone will actually come along and implement it for us. There are hundreds of routes to take, but if something is going to work then it has to be done by someone who already has a clue where to start and what they're doing -- basically someone who was willing to actually properly consider the problem and how it might be fixed. Alternatively if you happen to know of a bunch of developers desperate to get started working on writing some OSM software, but they just can't seem to find themselves something to do, but would really really like a couple of specs to get their teeth into, then by all means, keep talking. But for as long as trac has quite so many untouched tickets, I'm going to doubt that's really true. > > Here's some working code that simplifies the file: > sed "s/(\[bridge] = 'yes' or \[bridge]='true')/isBridge/g" osm.xml > > And the reverse: > sed "s/isBridge/([bridge] = 'yes' or [bridge]='true')/g" It doesn't count if anybody with the vaguest clue can do it in 30 seconds for the simple reason that most of us probably already have. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
* Andreas Barth ([EMAIL PROTECTED]) [080527 16:45]: > [...] I have now put a bit of that stuff together. All files (including sample code) is at http://alius.ayous.org/~aba/osm-formater-1/ I re-formated the road-sections. They now look like this: [highway] = 'primary' or [highway] = 'primary_link' #e46d71 0.7 1.6 2.5 3template.py is the actual python code osm-template-reformated.xml is the result of the operation osm-template.xml the original file I used osmshort.xml is the new source file I know that the python code isn't final yet, and also that there are few spaces too much in the resulting xml file. If the trend however looks ok, I'd continue reformating the sections in that way (railways need to swap places, so I didn't do that yet), and adding code for other cases. (And as said before, I'm quite sure that after the first reformating round, there'll be a second one where we learned much from the first one.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
2008/5/27 Tom Hughes <[EMAIL PROTECTED]>: > Martijn van Oosterhout wrote: >> On Tue, May 27, 2008 at 7:29 PM, Robert (Jamie) Munro <[EMAIL PROTECTED]> >> wrote: >>> Here's some working code that simplifies the file: >>> sed "s/(\[bridge] = 'yes' or \[bridge]='true')/isBridge/g" osm.xml >>> >>> And the reverse: >>> sed "s/isBridge/([bridge] = 'yes' or [bridge]='true')/g" >> >> I'm thinking of teaching osm2pgsql and Mapnik about booleans at some >> point so that all the comparisons against yes/no/1/0/on/off/etc all >> get done during import. For this to work Mapnik needs to be able to >> handle comparing different types, I sent a patch to Jon to do this so >> hopefully at some point we can simplify at least that portion... > > I've already taught mapnik about booleans - if you have a postgresql > boolean column called 'bridge' then you can use '[bridge]' or 'not > [bridge]' as filters. > cool would be class based renderstyle implementation and integrate the scaledominators in a simpler way.. and have the casings into the same class definition, with some kind of rendering level [color] [width] round round [color] [width+2] round round and then a primary and secondary road could look like:([highway] = 'primary' or [highway] = 'primary_link') and not [tunnel]='yes' we can override the width and color variables in the RenderStyle i know this sample is not complete in anyway, but i hope the point is clear ;) shoot on it ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ([highway] = 'secondary' or [highway] = 'secondary_link') and not ([tunnel]='yes' or [tunnel]='true') 4,2
Re: [OSM-talk] simplifying mapnik layout definition
* Robert (Jamie) Munro ([EMAIL PROTECTED]) [080527 20:07]: > If we can agree some basic ideas for how the format should work, and > what won't work, someone may come along and try to implement it. If you > just say "go away until you have finished the whole thing" every time, > it's not surprising people don't write anything because they have no > idea where to start. You seem to read different mails than I do. I read the mails from Andy (and others) as "looks great, next step is actually working on code". Which is what I do now. (And that definitly won't be the last round of code, it's just a beginning.) Cheers, Andi -- http://home.arcor.de/andreas-barth/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
Martijn van Oosterhout wrote: > On Tue, May 27, 2008 at 7:29 PM, Robert (Jamie) Munro <[EMAIL PROTECTED]> > wrote: >> Here's some working code that simplifies the file: >> sed "s/(\[bridge] = 'yes' or \[bridge]='true')/isBridge/g" osm.xml >> >> And the reverse: >> sed "s/isBridge/([bridge] = 'yes' or [bridge]='true')/g" > > I'm thinking of teaching osm2pgsql and Mapnik about booleans at some > point so that all the comparisons against yes/no/1/0/on/off/etc all > get done during import. For this to work Mapnik needs to be able to > handle comparing different types, I sent a patch to Jon to do this so > hopefully at some point we can simplify at least that portion... I've already taught mapnik about booleans - if you have a postgresql boolean column called 'bridge' then you can use '[bridge]' or 'not [bridge]' as filters. Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
On Tue, May 27, 2008 at 7:29 PM, Robert (Jamie) Munro <[EMAIL PROTECTED]> wrote: > Here's some working code that simplifies the file: > sed "s/(\[bridge] = 'yes' or \[bridge]='true')/isBridge/g" osm.xml > > And the reverse: > sed "s/isBridge/([bridge] = 'yes' or [bridge]='true')/g" I'm thinking of teaching osm2pgsql and Mapnik about booleans at some point so that all the comparisons against yes/no/1/0/on/off/etc all get done during import. For this to work Mapnik needs to be able to handle comparing different types, I sent a patch to Jon to do this so hopefully at some point we can simplify at least that portion... Have a nice day, -- Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Allan wrote: | Now, if someone is volunteering to make a concise definition format | that can be pre-processed into the mapnik XML format (or mapnik python | code, or even just read by a modified mapnik directly, or whatever) | then I'd absolutely love to SEE THE WORKING CODE. That osm.xml is an | unwieldy beast isn't in question, nor are the myriad of possibilities | to improve it - what is lacking is working alternative. IMHO in this case, the code is the easy part - it's designing a good format that is hard. It has to be actually easier to read and edit in general, rather than easier for whoever designed it but just as hard (or even harder) for everyone else. Whether it should be discussed here or in Mapnik's lists depends on if the format will be generally useful, or specific to open street map's needs - perhaps it will be tied intimately to our system of tags. Perhaps the format could be used to generate osmarender formatting at the same time. If we can agree some basic ideas for how the format should work, and what won't work, someone may come along and try to implement it. If you just say "go away until you have finished the whole thing" every time, it's not surprising people don't write anything because they have no idea where to start. Here's some working code that simplifies the file: sed "s/(\[bridge] = 'yes' or \[bridge]='true')/isBridge/g" osm.xml And the reverse: sed "s/isBridge/([bridge] = 'yes' or [bridge]='true')/g" Robert (Jamie) Munro -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkg8ROMACgkQz+aYVHdncI3jsgCgsSeHDPwjdpEYCrCVazE6JBk1 kU4AoM9LhG9u7TiqfJ0wqmtT4O6mX5ua =8bg+ -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] simplifying mapnik layout definition
In message <[EMAIL PROTECTED]> "Robert (Jamie) Munro" <[EMAIL PROTECTED]> wrote: > Here's some working code that simplifies the file: > sed "s/(\[bridge] = 'yes' or \[bridge]='true')/isBridge/g" osm.xml > > And the reverse: > sed "s/isBridge/([bridge] = 'yes' or [bridge]='true')/g" How is that "working code" exactly? What is isBridge and where is it defined? Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
