Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread John Smith
2009/12/17 Steve Bennett stevag...@gmail.com:
 What do people think? (No comments on how to tag land reserves, it's just an
 example...)

Nice idea, but you are painting yourself into a corner as you limit
the fall back to a single option.

It'd be better if you could go from most specific to least, for
example, a massage shop is also a type of shop, which is also a retail
space.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Shalabh
On Thu, Dec 17, 2009 at 6:19 PM, Steve Bennett stevag...@gmail.com wrote:

 Hi all,
   As we all know, you don't tag for the renderer. However, you want your
 map data to render nicely now, and you want correct map data in the long
 term.

 Suggestion: introduce a fallback tag.

 For example, around my city there are little reserves - patches of grass
 reserved by the government for future development such as freeways or train
 lines. They often get tagged leisure=park, but say I want to start tagging
 them landuse=reserve instead. Suddenly, instead of being green on mapnik,
 it will be white again - unrecognised tag.

 Solution: tag it like this:
 landuse=reserve
 fallback:leisure=park

 That's pretty simple logic to explain to any renderer or editor, and it
 gives people a way to avoid the temptation of tagging for the renderer,
 and allows them to tag for the future instead.

 What do people think? (No comments on how to tag land reserves, it's just
 an example...)

 (This case is slightly complicated by the fact that the two tags - landuse
 and leisure - are different. Perhaps a more explicit
 fallback:landuse=leisure:park would be clearer.)

 Steve


 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

 1. And what if even the 'fallback tag' is not rendered by the renderer?
2. Some things may have just no fallback e.g. Mountain passes are not
rendered by most renderers. What would be the fallback tag in such a case.

In my opinion, this will only confuse the mappers more when they tag a POI.
A few days down the line, we would have many more questions on what should
be the fallback of what and why?

I would think a better idea is to have atleast one renderer and the main OSM
map to render a superset of all tags.

Regards,
Shalabh
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread John Smith
2009/12/17 Shalabh shalab...@gmail.com:
 On Thu, Dec 17, 2009 at 6:19 PM, Steve Bennett stevag...@gmail.com wrote:

 Hi all,
   As we all know, you don't tag for the renderer. However, you want your
 map data to render nicely now, and you want correct map data in the long
 term.

 Suggestion: introduce a fallback tag.

 For example, around my city there are little reserves - patches of grass
 reserved by the government for future development such as freeways or train
 lines. They often get tagged leisure=park, but say I want to start tagging
 them landuse=reserve instead. Suddenly, instead of being green on mapnik,
 it will be white again - unrecognised tag.

 Solution: tag it like this:
 landuse=reserve
 fallback:leisure=park

 That's pretty simple logic to explain to any renderer or editor, and it
 gives people a way to avoid the temptation of tagging for the renderer,
 and allows them to tag for the future instead.

 What do people think? (No comments on how to tag land reserves, it's just
 an example...)

 (This case is slightly complicated by the fact that the two tags - landuse
 and leisure - are different. Perhaps a more explicit
 fallback:landuse=leisure:park would be clearer.)

 Steve


 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

 1. And what if even the 'fallback tag' is not rendered by the renderer?
 2. Some things may have just no fallback e.g. Mountain passes are not
 rendered by most renderers. What would be the fallback tag in such a case.

 In my opinion, this will only confuse the mappers more when they tag a POI.
 A few days down the line, we would have many more questions on what should
 be the fallback of what and why?

 I would think a better idea is to have atleast one renderer and the main OSM
 map to render a superset of all tags.

+1

This should be in the rendering logic, not the map data, otherwise
it's no better than tagging things with the icons to use for POIs etc.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Peter Körner
 What do people think? (No comments on how to tag land reserves, it's 
 just an example...)

Tagging for and only or the renderer is a bad idea. Better sind in a 
patch to the mapnik xml, to that (in your example) landuse=reserve is 
rendered accordingly, or tag as landuse=park, reserve=yes.

Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Frederik Ramm
Hi,

Steve Bennett wrote:
 Solution: tag it like this:
 landuse=reserve
 fallback:leisure=park

This makes only sense if there are certain landuse=reserve areas that 
you want to fall back to leisure=park and other landuse=reserve areas 
that are more like a natural=grass. And this would then mean that 
landuse=reserve is somehow underspecified.

If you have a certain fallback hierarchy that says dear renderers of 
the world, if you encounter something tagged landuse=reserve and you 
don't know what to do, then treat it as leisure=park, then it makes 
more sense to create this hierarchy externally and feed it to the 
renderers, instead of putting bits and pieces of it all over the database!

There are some technical problems, too. Mapnik, for example, renders by 
going through the rules one by one, fetching the matching objects, and 
rendering them.

Your thinking is obviously the other way round: Take each object in turn 
and decide how to render it.

With your approach it is quite easy to have an else case that renders 
things differently if none of the other rules apply. With Mapnik that is 
not so easy.

Bye
Frederik

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Steve Bennett
On Thu, Dec 17, 2009 at 11:55 PM, Shalabh shalab...@gmail.com wrote:

 1. And what if even the 'fallback tag' is not rendered by the renderer?


That's the current situation. So, the worst case scenario, with this tag,
is...what we have now. Every other case is an improvement.


 2. Some things may have just no fallback e.g. Mountain passes are not
 rendered by most renderers. What would be the fallback tag in such a case.


Not sure which tag you're referring to. If the tag is just a bit of
decoration, maybe you don't need a fallback. But in lots of other cases, it
would be good to be able to fall back to at least a landuse=industrial, or
building=yes or something.



 In my opinion, this will only confuse the mappers more when they tag a POI.



Nah. Only the smart mappers would even think of using it.


 A few days down the line, we would have many more questions on what should
 be the fallback of what and why?


Nah. It doesn't matter enough. I would see it mostly as a personal thing for
the mapper, to know that at least *something* will render.

I would think a better idea is to have atleast one renderer and the main OSM
 map to render a superset of all tags.


There are hundreds of thousands of distinct key=value pairs. And even if
that was one renderer could do it...how does that help? Say I want Mapnik to
look nice, but you propose that I use Osmarender instead because it supports
every single tag This isn't a solution at all.

Steve
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Shalabh
On Thu, Dec 17, 2009 at 6:35 PM, Steve Bennett stevag...@gmail.com wrote:

 On Thu, Dec 17, 2009 at 11:55 PM, Shalabh shalab...@gmail.com wrote:

 1. And what if even the 'fallback tag' is not rendered by the renderer?


 That's the current situation. So, the worst case scenario, with this tag,
 is...what we have now. Every other case is an improvement.



 2. Some things may have just no fallback e.g. Mountain passes are not
 rendered by most renderers. What would be the fallback tag in such a case.


 Not sure which tag you're referring to. If the tag is just a bit of
 decoration, maybe you don't need a fallback. But in lots of other cases, it
 would be good to be able to fall back to at least a landuse=industrial, or
 building=yes or something.


Referring to 'Mountain pass' which is not a decoration by any means.




 In my opinion, this will only confuse the mappers more when they tag a
 POI.


 Nah. Only the smart mappers would even think of using it.


And the 'not so smart ones' may sometimes end up putting in unwanted values
or choosing the wrong option from a drop down. And then some smart ones will
have to correct all that.



 A few days down the line, we would have many more questions on what should
 be the fallback of what and why?


 Nah. It doesn't matter enough. I would see it mostly as a personal thing
 for the mapper, to know that at least *something* will render.

 I would think a better idea is to have atleast one renderer and the main
 OSM map to render a superset of all tags.


 There are hundreds of thousands of distinct key=value pairs. And even if
 that was one renderer could do it...how does that help? Say I want Mapnik to
 look nice, but you propose that I use Osmarender instead because it supports
 every single tag This isn't a solution at all.

 Steve

Better than having renderers rendering the same area with different colours
and notations.

Anyway, for this approach to even start making sense, there has to be TAG
FAMILY TREE covering each known tag such that each has fallback options
going up to a certain level. And then each renderer should follow the TAG
TREE. Not sure how feasible would this be.

Regards,
Shalabh
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Joseph Reeves
to know that at least *something* will render.

This seems like a confusing proposal to ensure that a tiny fraction of
a percentage of the whitespace on OSM.org gets *something* rendered in
it.

-1 from me.



2009/12/17 Steve Bennett stevag...@gmail.com:
 On Thu, Dec 17, 2009 at 11:55 PM, Shalabh shalab...@gmail.com wrote:

 1. And what if even the 'fallback tag' is not rendered by the renderer?

 That's the current situation. So, the worst case scenario, with this tag,
 is...what we have now. Every other case is an improvement.


 2. Some things may have just no fallback e.g. Mountain passes are not
 rendered by most renderers. What would be the fallback tag in such a case.

 Not sure which tag you're referring to. If the tag is just a bit of
 decoration, maybe you don't need a fallback. But in lots of other cases, it
 would be good to be able to fall back to at least a landuse=industrial, or
 building=yes or something.


 In my opinion, this will only confuse the mappers more when they tag a
 POI.

 Nah. Only the smart mappers would even think of using it.


 A few days down the line, we would have many more questions on what should
 be the fallback of what and why?

 Nah. It doesn't matter enough. I would see it mostly as a personal thing for
 the mapper, to know that at least *something* will render.

 I would think a better idea is to have atleast one renderer and the main
 OSM map to render a superset of all tags.


 There are hundreds of thousands of distinct key=value pairs. And even if
 that was one renderer could do it...how does that help? Say I want Mapnik to
 look nice, but you propose that I use Osmarender instead because it supports
 every single tag This isn't a solution at all.

 Steve

 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Steve Bennett
On Fri, Dec 18, 2009 at 12:03 AM, Peter Körner osm-li...@mazdermind.dewrote:

 Tagging for and only or the renderer is a bad idea. Better sind in a
 patch to the mapnik xml,


With respect, fix the renderer is not a solution to how do I tag in such
a way that current and future renderers will produce an acceptable result?


 to that (in your example) landuse=reserve is
 rendered accordingly, or tag as landuse=park, reserve=yes.


 Did you mean leisure=park? If so, this is the worst case of tagging for
the renderer, because *it's not a park*. The whole point is to avoid using
incorrect tags.

Steve
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Steve Bennett
On Fri, Dec 18, 2009 at 12:12 AM, Shalabh shalab...@gmail.com wrote:

 Anyway, for this approach to even start making sense, there has to be TAG
 FAMILY TREE covering each known tag such that each has fallback options
 going up to a certain level. And then each renderer should follow the TAG
 TREE. Not sure how feasible would this be.


*If* you wanted to centralise the fallback logic, then, yes, that would be
nice to have.

Steve
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread John Smith
2009/12/17 Steve Bennett stevag...@gmail.com:
 Nah. Only the smart mappers would even think of using it.

And people that CP...

 Nah. It doesn't matter enough. I would see it mostly as a personal thing for
 the mapper, to know that at least *something* will render.

Don't tag it until your feature request to update mapnik's style sheet
is put into production...

 There are hundreds of thousands of distinct key=value pairs. And even if
 that was one renderer could do it...how does that help? Say I want Mapnik to
 look nice, but you propose that I use Osmarender instead because it supports
 every single tag This isn't a solution at all.

So file a feature request against mapnik's style sheet...

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Steve Bennett
On Fri, Dec 18, 2009 at 12:11 AM, Joseph Reeves iknowjos...@gmail.comwrote:

 This seems like a confusing proposal to ensure that a tiny fraction of
 a percentage of the whitespace on OSM.org gets *something* rendered in
 it.


No, it's a proposal to encourage people to tag for the future and to smooth
transitions to better tag schemes.

IMHO one of the reasons we get stuck with bad schemes is that switching is
so unattractive. If you go around changing existing tags to something
marginally better, all renderers will instantly stop rendering anything.
That's a huge disincentive.

Steve
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Steve Bennett
On Fri, Dec 18, 2009 at 12:15 AM, John Smith deltafoxtrot...@gmail.comwrote:

 Don't tag it until your feature request to update mapnik's style sheet
 is put into production...


That's completely at odds with standard OSM advice: tag however you want.


 So file a feature request against mapnik's style sheet...


I never mentioned Mapnik. Let's be quite clear about the use cases here:

Your strategy:
1) I want to tag Y instead of X.
2) I file a feature request with mapnik.
3) I file a feature request with kosmos
4) I file a feature request with osmarender
5) I file a few more feature requests
6) I turn old and grey.
7) My feature requests are all approved
8) I use my new tag.

My strategy:
1) I want to tag Y instead of X.
2) I tag Y, fallback:X
3) I get on with my life. Renderers will catch up whenever.

Steve
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Frederik Ramm
Hi,

Steve Bennett wrote:
   My strategy:
 1) I want to tag Y instead of X.
 2) I tag Y, fallback:X
 3) I get on with my life. Renderers will catch up whenever.

My strategy:

1) I want to tag Y
2) I tag Y
3) I get on with my life. Renderers will catch up whenever.

Bye
Frederik

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Chris Hill
Frederik Ramm wrote:
 Hi,

 Steve Bennett wrote:
My strategy:
   
 1) I want to tag Y instead of X.
 2) I tag Y, fallback:X
 3) I get on with my life. Renderers will catch up whenever.
 

 My strategy:

 1) I want to tag Y
 2) I tag Y
 3) I get on with my life. Renderers will catch up whenever.
   
+1

Cheers, Chris

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Shalabh
On Thu, Dec 17, 2009 at 6:54 PM, Frederik Ramm frede...@remote.org wrote:

 Hi,

 Steve Bennett wrote:
   My strategy:
  1) I want to tag Y instead of X.
  2) I tag Y, fallback:X
  3) I get on with my life. Renderers will catch up whenever.

 My strategy:

 1) I want to tag Y
 2) I tag Y
 3) I get on with my life. Renderers will catch up whenever.

 Bye
 Frederik

 +1

Shalabh
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread John Smith
2009/12/17 Steve Bennett stevag...@gmail.com:
 That's completely at odds with standard OSM advice: tag however you want.

You only want to tag stuff that renders, so update the render style
sheet then tag it, if you don't care about it rendering first just tag
it but your comments are specifically about wanting them to render
first.

 I never mentioned Mapnik. Let's be quite clear about the use cases here:

Umm yes you did...

 Say I want Mapnik to
 look nice, but you propose that I use Osmarender instead because it supports
 every single tag This isn't a solution at all.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Peter Körner
 Tagging for and only or the renderer is a bad idea. Better sind in a
 patch to the mapnik xml, 
 
 With respect, fix the renderer is not a solution to how do I tag in 
 such a way that current and future renderers will produce an acceptable 
 result?
Why not?

 to that (in your example) landuse=reserve is
 rendered accordingly, or tag as landuse=park, reserve=yes.
 
  Did you mean leisure=park? If so, this is the worst case of tagging 
 for the renderer, because *it's not a park*. The whole point is to 
 avoid using incorrect tags.
Sorry, was just a sample ;)

Peter

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Richard Mann
4) And maybe I do some rendering myself...

Richard

On Thu, Dec 17, 2009 at 1:24 PM, Frederik Ramm frede...@remote.org wrote:

 Hi,

 Steve Bennett wrote:
   My strategy:
  1) I want to tag Y instead of X.
  2) I tag Y, fallback:X
  3) I get on with my life. Renderers will catch up whenever.

 My strategy:

 1) I want to tag Y
 2) I tag Y
 3) I get on with my life. Renderers will catch up whenever.

 Bye
 Frederik

 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread John Smith
2009/12/17 Richard Mann richard.mann.westoxf...@googlemail.com:
 4) And maybe I do some rendering myself...

I actually offered him help/resources the other week on the talk-au
list with regards to style sheets, perhaps I was a little too subtle
:)

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Steve Bennett
On Fri, Dec 18, 2009 at 12:47 AM, John Smith deltafoxtrot...@gmail.comwrote:


 You only want to tag stuff that renders, so update the render style
 sheet then tag it, if you don't care about it rendering first just tag
 it but your comments are specifically about wanting them to render
 first.


I actually offered him help/resources the other week on the talk-au
list with regards to style sheets, perhaps I was a little too subtle
:)

Ok, we're obviously coming from very different mindsets here. I'm trying to
find scalable solutions. When I say Say I have x problem, it doesn't render
well, I'm not looking for someone to tell me how to edit a stylesheet and
hack mapnik to produce a particular result on my machine.

Instead, I'm presuming that the problem I'm describing is common to many
people. And further, I'm presuming that because they have a problem (which
there isn't a good solution for), *we* have a problem. In this case, I'm
saying that if people have to choose between tagging correctly, or getting
instant gratification in the online renderers. This is a problem. And these
are not solutions:
1) Tag correctly anyway
2) Don't worry about how it looks
3) Hack the stylesheet and render it on your machine
4) File a feature request
5) Fix the renderer myself and post the diff
6) Use a clever combination of tags that solves this particular instance

They're not solutions because they don't scale. They might solve my problem
today, but they don't solve the general problem for people in general.
Whereas having something like a fallback tag *does* scale: once implemented
in a few renderers, it only takes that tiny piece of knowledge (the
existence of the tag) for this problem to be solved again and again, every
time it occurs.

There may be arguments against my proposed solution. There may be better
solutions. It may not be a big problem. But, please, these one-off
workarounds and hacks are not solutions.

Steve
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Shalabh
On Thu, Dec 17, 2009 at 7:58 PM, Steve Bennett stevag...@gmail.com wrote:


 There may be arguments against my proposed solution. There may be better
 solutions. It may not be a big problem. But, please, these one-off
 workarounds and hacks are not solutions.

 Steve


Actually Steve, I think your solution is as much a workaround as the other
solutions. It just adds another level of complexity. If we dont centralize
what I call 'TAG TREE', it anyway wont work and I am not even sure if you
can identify a parent for each tag and then a parent of a parent and so on.

So, lets map and wait for the renderers to catch up.

Regards,
Shalabh
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread John Smith
2009/12/18 Shalabh shalab...@gmail.com:
 So, lets map and wait for the renderers to catch up.

Or if he were really serious about this he'd come up with a suitable
break down list of most specific to least specific way existing tags
already in use could render and then provide suitable patches for
renderers to hook into his results...

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Steve Bennett
On Fri, Dec 18, 2009 at 1:47 AM, John Smith deltafoxtrot...@gmail.comwrote:

 Or if he were really serious about this he'd come up with a suitable


Was this mailing list always like this? I don't get it. I make a sincere
suggestion for a tag that I think would be useful, and just look at the
response. Where does it all come from? Someone smacks down the OP and two
others immediately chime in with +1. Am I out of line brainstorming here?
Why the snide replies? Why so much negativity?

Steve
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Shalabh
On Thu, Dec 17, 2009 at 8:50 PM, Steve Bennett stevag...@gmail.com wrote:

 On Fri, Dec 18, 2009 at 1:47 AM, John Smith deltafoxtrot...@gmail.comwrote:

 Or if he were really serious about this he'd come up with a suitable


 Was this mailing list always like this? I don't get it. I make a sincere
 suggestion for a tag that I think would be useful, and just look at the
 response. Where does it all come from? Someone smacks down the OP and two
 others immediately chime in with +1. Am I out of line brainstorming here?
 Why the snide replies? Why so much negativity?

 Steve


Cool down Steve. The +1s were not to put you down, it was just agreement
with something someone said. No one here is shooting down your proposal
because they dont want change. Ask me, I am fed up of so many renderers,
none of which renders everything that I want rendered.

It is just that I dont see your solution as a scalable one and the same goes
for many of the +1ers. The +1 is just a figure of speech.

You are sort of advocating a top down approach while others think it has to
be a bottom up approach. And all of us are entitled to our opinions. If you
have a solution which can make the renderers render what they are supposed
to render without adding layers of complicacy, it will be welcome.

Cheers,
Shalabh
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Anthony
On Thu, Dec 17, 2009 at 8:09 AM, Steve Bennett stevag...@gmail.com wrote:

 On Fri, Dec 18, 2009 at 12:03 AM, Frederik Ramm frede...@remote.orgwrote:

 If you have a certain fallback hierarchy that says dear renderers of the
 world, if you encounter something tagged landuse=reserve and you don't know
 what to do, then treat it as leisure=park, then it makes more sense to
 create this hierarchy externally and feed it to the renderers, instead of
 putting bits and pieces of it all over the database!


 Yes...but I think it's a fair statement that centralisation of tag
 semantics is not working very well, and many people bypass the process
 altogether.

 So, yes, in a perfect world, we would simply define these fallbacks
 centrally. But in the OSM world, it would be useful to do them case by case.
 One benefit is no one needs to argue over them. You want to tag your
 fallback as landuse=nature_reserve? Go ahead.


Then just start using your fallback tag.  There's no need to tell the list
about it.

On Thu, Dec 17, 2009 at 8:18 AM, Steve Bennett stevag...@gmail.com wrote:

 My strategy:
 1) I want to tag Y instead of X.
 2) I tag Y, fallback:X
 3) I get on with my life. Renderers will catch up whenever.


Great.  Do it.  No one's stopping you.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Dave F.
Steve Bennett wrote:
 Hi all,
   As we all know, you don't tag for the renderer. However, you want 
 your map data to render nicely now, and you want correct map data in 
 the long term.

 Suggestion: introduce a fallback tag.

 For example, around my city there are little reserves - patches of 
 grass reserved by the government for future development such as 
 freeways or train lines. They often get tagged leisure=park, but say 
 I want to start tagging them landuse=reserve instead. Suddenly, 
 instead of being green on mapnik, it will be white again - 
 unrecognised tag.
Don't tag for the future.

If it's use *now *is a park, tag it as a park.

When  if (and that's a *big *if when talking about civil engineering 
projects) it changes use re-tag it then  not before.

Also, I think this should be on the Tagging forum.

Cheers
Dave F.





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Dave F.
Frederik Ramm wrote:
 Hi,

 Steve Bennett wrote:
My strategy:
   
 1) I want to tag Y instead of X.
 2) I tag Y, fallback:X
 3) I get on with my life. Renderers will catch up whenever.
 

 My strategy:

 1) I want to tag Y
 2) I tag Y
 3) I get on with my life. Renderers will catch up whenever.

 Bye
 Frederik
+1

Steve B - Your chasing your tail.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Dave F.
Steve Bennett wrote:
 I'm not looking for someone to tell me how to edit a stylesheet and 
 hack mapnik to produce a particular result on my machine.

But, Steve, that's precisely what you should be doing.


  And these are not solutions:
 4) File a feature request
 5) Fix the renderer myself and post the diff


Yes, they are. If the render of your choice doesn't render a key/tag, 
fix it yourself so that it does.
John S. looked willing to help you.

 ...But, please, these one-off workarounds and hacks are not solutions.
It sounds like you're the one that's 'hacking' things.

Cheers
Dave F.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Dave F.
Steve Bennett wrote:
 On Fri, Dec 18, 2009 at 1:47 AM, John Smith deltafoxtrot...@gmail.com 
 mailto:deltafoxtrot...@gmail.com wrote:

 Or if he were really serious about this he'd come up with a suitable


 Was this mailing list always like this? I don't get it. I make a 
 sincere suggestion for a tag that I think would be useful, and just 
 look at the response. Where does it all come from? Someone smacks down 
 the OP and two others immediately chime in with +1. Am I out of line 
 brainstorming here? Why the snide replies? Why so much negativity?

*You *asked for opinions!?! - What do people think?

Replies are in the negative because they think your idea is poor for the 
reasons stated. It's as simple as that.

Dave F.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Steve Bennett
First, thanks for the thoughtful replies, everyone. I'll reply to all in one
email.

It is just that I dont see your solution as a scalable one

What's not scalable about it - presumably that you have to tag a fall back
every time you use the tag? What's an alternative that's more scalable, for
someone who doesn't have the ability/time/whatever to setup a rendering
system and produce their own custom maps?

You are sort of advocating a top down approach while others think it has to
 be a bottom up approach.


IMHO what I am (was?) advocating is somewhere in the middle, but closer to
bottom up. True top down would be standardising all tags and forcing
renderers to be compliant. Somewhat less so is a central list that renderers
can optionally implement. I was only advocating a single tag that renderers
should know how to deal with, leaving all the rest of the decisions to
individuals. Pretty bottom up, if you ask me.


 And all of us are entitled to our opinions. If you have a solution which
 can make the renderers render what they are supposed to render without
 adding layers of complicacy, it will be welcome.


I don't think anyone spontaneously generates perfect solutions out of
nowhere. I had an idea, I wanted to see whether it could go anywhere with
some workshopping. Sure, maybe it was a dumb idea. But I don't think we can
shoot down every idea on the basis that it's not comprehensive.

Then just start using your fallback tag.  There's no need to tell the list
about it.

IMVHO, that approach is harmful in general (have you *seen* how many
different tags are out there?), and ironic in this instance.

More precisely, the fallback that you are proposing would be relatively
heavy both on code and people.

It may be heavy on code – I hadn't thought about the way Mapnik renders, for
instance – but by definition it's light on people: it's a completely
optional tag, there for those that want to use it. If you use it, you get
some additional benefit, if you don't, you lose nothing. If I was proposing
that everyone tag everything with multiple fallback tags, *that* would be
heavy on people.

If it's use *now *is a park, tag it as a park.
When  if (and that's a *big *if when talking about civil engineering
projects) it changes use re-tag it then  not before.

Did everyone misunderstand my example this way? The thing is a reserve, not
a park. It has grass, but no amenities. It only exists to protect the land
for future development. People tag them as parks because that's the closest
tag...but it's not ideal. My tagging for the future remark had nothing to
do with future development, only future support of a reserve tag.

Also, I think this should be on the Tagging forum.

Yeah, maybe. I thought it was slightly out of scope for that.

In the end, OSM is a database, and how you are rendering a map is something
accessory, as everyone can set up the rendering the way they want. It is
the greatest strength of OSM that you can choose what kind of rendering you
can do. I think the map should deemphasized at some point from the main site
as more and more people want custom rendering.

I guess I will have to investigate this further, but that's really not at
all how I see OSM, and not how I think the public perceives it. The diehards
on this list may all have their own renderers set up at home, but that's
rare. For most people, the mapnik view *is* OSM, and switching it off would
be dumping OSM's biggest selling point. The world has very much moved to a
cloud model, whereas what you're proposing (download the data, render it
using an offline client) is exactly the opposite of that. I just don't see
that approach gaining traction any more. If anything, I would have thought
you'd put more effort into custom rendering on the server, like cloudmade
does.

Of course, I could be completely wrong. That would at least explain why I
find the response of make your own stylesheet so jarring to my original
problem statement.

Yes, they are. If the render of your choice doesn't render a key/tag,fix it
yourself so that it does.

Hmm, and I put so much effort into explaining the difference between a
one-off solution and a scalable solution. I thought I'd get more than yes
it is.

*You *asked for opinions!?! - What do people think?
Replies are in the negative because they think your idea is poor for the
reasons stated. It's as simple as that.

Constructive critism is great, and there were some good points raised. But
by and large the response was not constructive.

Steve
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Richard Fairhurst

Steve Bennett wrote:
 For example, around my city there are little reserves - patches of 
 grass reserved by the government for future development such as 
 freeways or train lines. They often get tagged leisure=park, but 
 say I want to start tagging them landuse=reserve instead. Suddenly,
 instead of being green on mapnik, it will be white again - unrecognised 
 tag.

 Solution: tag it like this:
 landuse=reserve
 fallback:leisure=park

No. This is way beyond wrong in several ways.

Core principle: you should map what's on the ground. If it's a reserve, call
it a reserve. It's not a park, so don't call it a park. The OSM database
exists _only_ to record reality.

Secondly: as far as I can tell, you're proposing inserting
fallback:leisure=park into the database at every occurrence of
landuse=reserve. You might also have, I dunno,
fallback:highway=bridleway for every occurrence of highway=byway. And so
on across loads of tags.

This is just redundancy on a massive, massive scale. You're inserting the
same hint millions of times when you should be inserting it once. If
landuse=park always approximates to leisure=park, then that either needs to
be in the renderer stylesheets themselves (and it'd be one line in the
Mapnik stylesheet or osm2pgsql setup), or in a general equivalence document
that all the renderers can use (Shalabh's tree thingy).

Rendering information, of any stripe, does not go in the database. That is
absolute.



You want instant gratification - that's fair enough. But the authors of the
stylesheets don't have the time to pander to every possible tag combination
- which is also fair enough, they're volunteers too and they have to
prioritise. And I hate to say it, but trac shows that people _do_ sometimes
invent obscure tags, which is ok, and demand support for them incessantly,
which isn't.

So the right way to solve it is to lower the barrier to getting Your
Favourite Feature rendered. Fortunately this is happening.

Cartagen is an instant-gratification JavaScript renderer. It's awesome.
Halcyon is the Flash one I'm working on and if you'll permit the immodesty,
I'd say it's ok, too. Kosmos is Igor Brejc's long-standing project which
gets better by the month and can produce lovely results. Tiledrawer is Mike
Migurski's superb Mapnik for the rest of us installation which is still a
bit more involved, but worth it as the best way to harness Mapnik MONSTER
POWER without a nervous breakdown. Cloudmade's Style Editor has some
limitations but you can't beat it in UI terms and I'm sure it'll get more
flexible in the future, so one to watch. Of course, Osmarender has been
around since about 38BC and is reasonably accessible. And there are others.

This leads to a virtuous circle: one renderer supports the tag - tag more
widely used - more renderer support - and so on. Andy first started
rendering ncn_ref on OpenCycleMap several years ago, when OCM was just a
little local project rather than the world-conquering behemoth it is today.
Now there are cycle renderers for local areas, for Garmins, for routing, and
so on. It really works.

cheers
Richard
-- 
View this message in context: 
http://old.nabble.com/Suggestion%3A-fallback-tag-tp26827544p26830932.html
Sent from the OpenStreetMap - General mailing list archive at Nabble.com.


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Emilie Laffray
2009/12/17 Steve Bennett stevag...@gmail.com

 In the end, OSM is a database, and how you are rendering a map is
 something accessory, as everyone can set up the rendering the way they
 want. It is the greatest strength of OSM that you can choose what kind of
 rendering you can do. I think the map should deemphasized at some point from
 the main site as more and more people want custom rendering.

 I guess I will have to investigate this further, but that's really not at
 all how I see OSM, and not how I think the public perceives it. The diehards
 on this list may all have their own renderers set up at home, but that's
 rare. For most people, the mapnik view *is* OSM, and switching it off would
 be dumping OSM's biggest selling point. The world has very much moved to a
 cloud model, whereas what you're proposing (download the data, render it
 using an offline client) is exactly the opposite of that. I just don't see
 that approach gaining traction any more. If anything, I would have thought
 you'd put more effort into custom rendering on the server, like cloudmade
 does.

 Of course, I could be completely wrong. That would at least explain why I
 find the response of make your own stylesheet so jarring to my original
 problem statement.


I understand your point. But I disagree about the directions where things
are going. Some things are going for the cloud, some will stay on your
desktop. Don't necessarily believe the hype and take it with a pinch of
salt. I wouldn't be surprised if at some point, people are coming up with
custom cloud renderers.
But for the time being, if you want a custom rendering you will be using
your own pc or server. If you are interested in a relatively simple
renderer, you could look at http://igorbrejc.net/kosmoshome . This should
help you and should not be too difficult to use.
I look forward to some offline rendering using Halcyon personally. Being
able to tweak a map just by playing with some css sounds very appealing to
me.
I agree that for many people the map is the focal point of OSM but again, we
have already two major renderers on the main site. I think it sends a clear
signal that we are not just about one map but several.
In the end, the power of OSM is what you do with it. The map part is not a
major interest to me, but I might be one of the exception.

Emilie Laffray
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread John Smith
2009/12/18 Steve Bennett stevag...@gmail.com:

As others have stated this should have gone to the tagging mailing list.

 What's not scalable about it - presumably that you have to tag a fall back

Your suggestion as is only copes with 1 alternative, rather than
gracefully falling back to less specific alternatives.

 every time you use the tag? What's an alternative that's more scalable, for
 someone who doesn't have the ability/time/whatever to setup a rendering
 system and produce their own custom maps?

To come up with a list of options that things fall back to, this may
not need to be in mapnik etc, but could be handled by a pre-processor.

 IMHO what I am (was?) advocating is somewhere in the middle, but closer to
 bottom up. True top down would be standardising all tags and forcing
 renderers to be compliant. Somewhat less so is a central list that renderers
 can optionally implement. I was only advocating a single tag that renderers
 should know how to deal with, leaving all the rest of the decisions to
 individuals. Pretty bottom up, if you ask me.

And here you were complaining about me suggesting redundency on layer
tags was a bad thing and you've basically done the same thing, except
worst since you are making suggestions about dictating how renderers
handle tags, rather than letting them make their own minds up about
falling back to less specific tagging schemes.

As I said before, this would be no better than adding an URI for the
icon that should be displayed for POIs just because one or more
rendered may not render all POI icons.

 some workshopping. Sure, maybe it was a dumb idea. But I don't think we can
 shoot down every idea on the basis that it's not comprehensive.

Isn't that the point of this exercise, to fall back to something else
if a more specific tag isn't currently handled, what if the fall back
tag isn't handled. That's just an exercise in 2 unrendered tags
instead of one.

 IMVHO, that approach is harmful in general (have you *seen* how many
 different tags are out there?), and ironic in this instance.

They differ because of perceived need, renderers on the other hand
have perceived needs in what they think should be rendered rather than
users forcing things one way or the other.

 It may be heavy on code – I hadn't thought about the way Mapnik renders, for

Mapnik, or more to the point osm2pgsql does a bunch of pre-processing
on OSM data, you could easily supply code or psuedo code to make a
lookup table in osm2pgsql handle fall back rather than tryng to do it
in extra tags that just have to be processed regardless of if the
server should render them or not.

 instance – but by definition it's light on people: it's a completely
 optional tag, there for those that want to use it. If you use it, you get
 some additional benefit, if you don't, you lose nothing. If I was proposing
 that everyone tag everything with multiple fallback tags, *that* would be
 heavy on people.

No, that would be heavy on a person making a lookup table, but
certainly not to the scale you are suggesting labour should be
applied.

 Did everyone misunderstand my example this way? The thing is a reserve, not
 a park. It has grass, but no amenities. It only exists to protect the land
 for future development. People tag them as parks because that's the closest
 tag...but it's not ideal. My tagging for the future remark had nothing to
 do with future development, only future support of a reserve tag.

Why is park not ideal if the current usage is a park?

There is a lot of land that is reserved for roads in future if needed
that has been taken over by land holders and they graze stock or
cultivate it, the only difference is if the road is ever built the
government doesn't need to aquire the land it just needs to evict the
squatters. Should they render the same as a park because it's a
reserve, but the land use is completely different.

 I guess I will have to investigate this further, but that's really not at
 all how I see OSM, and not how I think the public perceives it. The diehards
 on this list may all have their own renderers set up at home, but that's
 rare. For most people, the mapnik view *is* OSM, and switching it off would
 be dumping OSM's biggest selling point. The world has very much moved to a
 cloud model, whereas what you're proposing (download the data, render it
 using an offline client) is exactly the opposite of that. I just don't see
 that approach gaining traction any more. If anything, I would have thought
 you'd put more effort into custom rendering on the server, like cloudmade
 does.

There is already attempts to shift rendering to the client side, there
is a javascript site that does this, and now potlatch 2.0 is heading
in the same direction. Just because mapnik is the way things are
handled at present doesn't mean it will be 5 years from now.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread John Smith
2009/12/18 Emilie Laffray emilie.laff...@gmail.com:
 But for the time being, if you want a custom rendering you will be using
 your own pc or server. If you are interested in a relatively simple

If he wants to play about I have an instance of mapnik he can play
with setup already.

He could also play with cloudmade's style sheet editor...

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Dave F.
Steve Bennett wrote:
 IMVHO, that approach is harmful in general (have you *seen* how many 
 different tags are out there?), and ironic in this instance.
Yes,  unless I'm missing something your proposal just adds the long list.

 If it's use *now *is a park, tag it as a park.
 When  if (and that's a *big *if when talking about civil engineering 
 projects) it changes use re-tag it then  not before.

 Did everyone misunderstand my example this way? The thing is a 
 reserve, not a park. It has grass, but no amenities. It only exists to 
 protect the land for future development. People tag them as parks 
 because that's the closest tag...but it's not ideal. My tagging for 
 the future remark had nothing to do with future development, only 
 future support of a reserve tag.

Very unclear in your OP. Anyway...

Tag for how you see it is now.
If it's not a park, change it!
If it doesn't render, put a request in.

Your claimed solution:
landuse=reserve
fallback:leisure=park

still won't render  still needs to be requested  it adds an extra tag.
Like I said, I think you're chasing your tail.


 Also, I think this should be on the Tagging forum.

 Yeah, maybe. I thought it was slightly out of scope for that.

 In the end, OSM is a database, and how you are rendering a map is 
 something accessory, as everyone can set up the rendering the way 
 they want. It is the greatest strength of OSM that you can choose what 
 kind of rendering you can do. I think the map should deemphasized at 
 some point from the main site as more and more people want custom 
 rendering.

 I guess I will have to investigate this further, but that's really not 
 at all how I see OSM, and not how I think the public perceives it. The 
 diehards on this list may all have their own renderers set up at home, 
 but that's rare. For most people, the mapnik view *is* OSM, and 
 switching it off would be dumping OSM's biggest selling point. The 
 world has very much moved to a cloud model, whereas what you're 
 proposing (download the data, render it using an offline client) is 
 exactly the opposite of that. I just don't see that approach gaining 
 traction any more. If anything, I would have thought you'd put more 
 effort into custom rendering on the server, like cloudmade does.

 Of course, I could be completely wrong. That would at least explain 
 why I find the response of make your own stylesheet so jarring to my 
 original problem statement.

 Yes, they are. If the render of your choice doesn't render a 
 key/tag,fix it yourself so that it does.

 Hmm, and I put so much effort into explaining the difference between a 
 one-off solution and a scalable solution. I thought I'd get more than 
 yes it is.

You suggestion is as much a one-off solution. It's not a one fix, 
fixes all, because you'll have another tag in a different situation  it 
won't render either, so you'll have to put in a request for it. And so 
on  so forth...

What is your understanding of a 'scalable' solution?

 *You *asked for opinions!?! - What do people think?
 Replies are in the negative because they think your idea is poor for the
 reasons stated. It's as simple as that.

 Constructive critism is great, and there were some good points raised. 
 But by and large the response was not constructive.
But only from your point of view.

 Steve
 

 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
   


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Anthony
 Then just start using your fallback tag.  There's no need to tell the list
 about it.

 IMVHO, that approach is harmful in general (have you *seen* how many
 different tags are out there?), and ironic in this instance.


Honestly, I don't see the harm in having lots of tags that everyone else can
happily ignore.  At least, not when they're added by hand.  The only real
harm is a small fraction of space in the database.  When it comes to massive
imports (tiger:*=*) or editor generated tags (created_by), yeah, it wastes
enough space (and therefore processing time) to cause some harm.  But the
1000 or so fallback tags you add to the database isn't going to really
harm anyone.

Yes, it's ironic in this instance.  But that's because the idea of a
fallback tag is ironic.

In any case, your best bet would be to take this proposal directly to the
developers of one or more renderers.  It's not even a tagging issue.  It's a
renderer issue.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread John Smith
2009/12/18 Anthony o...@inbox.org:
 Honestly, I don't see the harm in having lots of tags that everyone else can
 happily ignore.  At least, not when they're added by hand.  The only real
 harm is a small fraction of space in the database.  When it comes to massive
 imports (tiger:*=*) or editor generated tags (created_by), yeah, it wastes
 enough space (and therefore processing time) to cause some harm.  But the
 1000 or so fallback tags you add to the database isn't going to really
 harm anyone.

Except those tags are being removed as much as possible to reduce over
heads... :)

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Liz
On Fri, 18 Dec 2009, Dave F. wrote:
 Replies are in the negative because they think your idea is poor for the
 reasons stated. It's as simple as that.


unfortunately the contents of this list are dominated by people who are 
negative writing negative comments


I note overall a lack of creative thinking on this list and a concentration of 
arguments which don't progress but become more entrenched as they continue 


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Tobias Knerr
Steve Bennett wrote:
 Solution: tag it like this:
 landuse=reserve
 fallback:leisure=park

Lets assume that your fallback tag isn't just a less specific type of
object than the real tag (in that case, a tag hierarchy - as it is used
with amenity=parking + parking=*, for example - would solve the problem).

In this situation, a fallback is based on certain assumptions how
renderers display a tag. It only works in your example because you make
the assumption that parks are rendered as a green area or something like
that, and that would be appropriate for reserves, too. But some other
renderer might write park all over the area or do something else that
makes the rendering completely inappropriate for the feature. What if I
use beach as the fallback for my golf bunkers and get ice cone and
beach ball icons, rather than the yellow area I had expected?

Another problem with your approach is that it only works in renderers
designed with the intention to display /everything/. I'd expect good
rendering styles to be limited to a selected subset of the available
information.

Tobias Knerr

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Steve Bennett
On Fri, Dec 18, 2009 at 6:16 AM, Tobias Knerr o...@tobias-knerr.de wrote:

 that, and that would be appropriate for reserves, too. But some other
 renderer might write park all over the area or do something else that
 makes the rendering completely inappropriate for the feature. What if I
 use beach as the fallback for my golf bunkers and get ice cone and
 beach ball icons, rather than the yellow area I had expected?

 Another problem with your approach is that it only works in renderers
 designed with the intention to display /everything/. I'd expect good
 rendering styles to be limited to a selected subset of the available
 information.


Two good arguments against my proposal.

Richard Fairhurst wrote:
This is just redundancy on a massive, massive scale. You're inserting the
same hint millions of times when you should be inserting it once. If
landuse=park always approximates to leisure=park, then that either needs to
be in the renderer stylesheets themselves (and it'd be one line in the
Mapnik stylesheet or osm2pgsql setup), or in a general equivalence document
that all the renderers can use (Shalabh's tree thingy).

Rendering information, of any stripe, does not go in the database. That is
absolute.

More good points.

So the right way to solve it is to lower the barrier to getting Your
Favourite Feature rendered. Fortunately this is happening.

Yes. Rather than the right way to solve it being, say, do what the rest of
us do, install mapnik and start hacking on stylesheets.


Cartagen is an instant-gratification JavaScript renderer. It's awesome.
Halcyon is the Flash one I'm working on and if you'll permit the immodesty,
I'd say it's ok, too.

I wouldn't say it's ok, I'd say it's great - even at this early stage. Very,
very cool indeed. And it totally works for reducing the barrier to entry for
tweaking rendering: I already used it to demonstrate a proposal for divided
ways.

However, by instant gratification, I don't just mean I get to see, on my
desktop, the map rendered how I want. I mean, I get to know that
*everyone* will see the map rendered nicely.

I was thinking last night that there are four different goals/approaches
that one could be heading for in helping OSM:

1) Doing stuff that helps you directly. For example, tweaking a stylesheet
to render a map for yourself, adding tags that are only meaningful to you.
2) Doing stuff that helps others directly. For example, mapping a new area
in a standard way, adding styles to a standard stylesheet.
3) Doing stuff that helps others to help themselves. For example,
documenting ways to install the software, adding renderer support for
obscure tags.
4) Doing stuff that helps others to do things of benefit to others. For
example, working on improving processes, documenting tags, trying to
increase compatibility between renderers etc.

Some of the solutions proposed in this thread were essentially 1. Whereas
I'm mostly interested in 4 - it's just what motivates me. Getting a nicely
rendered map is nice. But multiplying that up, so that everyone is helping
everyone get nicely rendered maps - that's what motivates me.


This leads to a virtuous circle: one renderer supports the tag - tag more
widely used - more renderer support - and so on.

Yeah, I'm still exploring this circle and looking at ways it can be
improved. Maybe it can be made more efficient, maybe it can happen with less
mistakes, maybe it can happen faster...etc. Better feedback in both
directions will help.

Andy first started
rendering ncn_ref on OpenCycleMap several years ago, when OCM was just a
little local project rather than the world-conquering behemoth it is today.
Now there are cycle renderers for local areas, for Garmins, for routing,
and
so on. It really works.

Yeah, cloudmade routing is awesome.

So, thanks Tobias and Richard for very constructive responses which convince
me that my proposed fallback:* tag is too much of a hack to be worth
pursuing. I'll keep investigating the idea of a centralised rules table
though.

Steve
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread Roy Wallace
On Fri, Dec 18, 2009 at 7:46 AM, Steve Bennett stevag...@gmail.com wrote:

 I'll keep investigating the idea of a centralised rules table
 though.

Cool - if so, it might be interesting to see how this could relate to
the wiki also, not just renderers. Good luck :)

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk] Suggestion: fallback tag

2009-12-17 Thread John Smith
2009/12/18 Roy Wallace waldo000...@gmail.com:
 On Fri, Dec 18, 2009 at 7:46 AM, Steve Bennett stevag...@gmail.com wrote:

 I'll keep investigating the idea of a centralised rules table
 though.

 Cool - if so, it might be interesting to see how this could relate to
 the wiki also, not just renderers. Good luck :)

+1, I thought people were already working on some kind of
documentation consolidation based on tags not just what's in the wiki?

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk