Re: [OSM-talk] Tagging and rendering of television masts

2017-04-25 Thread Andy Townsend 

On 25/04/2017 13:51, Greg Troxel wrote:


However, if one renders and one doesn't, in the default style, that's a
bug, and presumably someone can make a pull request to fix it - it seems
obviously uncontroversial.


You'd have thought so, but a project maintainer closed exactly that 
issue at https://github.com/gravitystorm/openstreetmap-carto/issues/181 
back in 2014.  Unfortunately it's not the only example where the 
"standard" map takes "unusual" rendering decisions.  Put bluntly, if it 
doesn't work for you, use a different map.  Personally, I gave up using 
it about 3 years ago because it was no longer fit for purpose, at least 
for me.


Best Regards,

Andy



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

Re: [OSM-talk] Tagging and rendering of television masts

2017-04-25 Thread Greg Troxel 

Oleksiy Muzalyev  writes:

> Both "man_made=tower;tower:type=communications" and "man_made=mast"
> are being used interchangeably. One of them is rendered with a good
> icon and another not rendered at all on the OSM map.
> I was not suggesting to re-tag this particular communication mast per
> se, but to attract an attention to this phenomenon.

In general, it seems that tower is for a larger structure that is more
lattice-like and mast for a structure that is more of a pole.   I am not
sure this distinction makes sense, but I am also not sure it's harmufl.

However, if one renders and one doesn't, in the default style, that's a
bug, and presumably someone can make a pull request to fix it - it seems
obviously uncontroversial.


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tagging and rendering of television masts

2017-04-23 Thread Oleksiy Muzalyev 
Both "man_made=tower;tower:type=communications" and "man_made=mast" are 
being used interchangeably. One of them is rendered with a good icon and 
another not rendered at all on the OSM map.
I was not suggesting to re-tag this particular communication mast per 
se, but to attract an attention to this phenomenon.


Best regards,
Oleksiy

On 23.04.17 11:41, Andy Townsend wrote:

On 22/04/2017 07:33, Oleksiy Muzalyev wrote:


It is possible to map it as: "man_made=mast", "height=190", etc., 
then it will be rendered.


In the general case, please don't suggest that people mistag things 
just so that one particular renderer (one that probably isn't used by 
the majority of people that consume OSM data*) renders it.


However in this particular case I can't claim to be familiar enough 
with it to say whether 
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dtower or 
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast is more 
appropropriate, or indeed whether those wiki pages reflect OSM usage.


Best Regards,

Andy

* I'm guessing the "most views" accolade goes to either Mapbox Streets 
or MAPS.ME these days.


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




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

Re: [OSM-talk] Tagging and rendering of television masts

2017-04-23 Thread Oleksiy Muzalyev 
All what is written at http://wiki.openstreetmap.org/wiki/Aviation is 
fair enough, especially the main principle: "We map anything that is 
observable on the ground.", but not an airspace. A communication tower, 
or a mast is well observable on the ground.


The DJI changed the map on its RPAS control stations from Google to Here 
Map. And on Here Map not much is shown. So usually one looks at several 
maps while planning a flight, especially in an urban area.


Best regards,
Oleksiy

On 23.04.17 10:47, Andreas Vilén wrote:

Please read http://wiki.openstreetmap.org/wiki/Aviation

Pilots do not use the osm base map...

/Andreas

Skickat från min iPhone

23 apr. 2017 kl. 07:50 skrev Oleksiy Muzalyev 
>:



On 22.04.17 21:17, Martin Koppenhoefer wrote:


sent from a phone

On 22. Apr 2017, at 08:33, Oleksiy Muzalyev 
> 
wrote:


In my opinion, it is a significant issue, in fact a disaster 
waiting to happen. There will be soon air-born taxi in Dubai, 
Singapore, etc., and the extremely high communication towers, the 
so-called aviation traffic obstacles 
https://en.wikipedia.org/wiki/Air_traffic_obstacle , are not 
rendered on the OSM map at all.


which disaster do you expect to happen? Someone flying around in 
dense fog and using no other information than osm-carto?


I agree it is a shortcoming that towers are not rendered on 
osm-carto, but we should keep calm and not exaggerate its significance.


cheers,
Martin


Dear Martin,

An air traffic obstacle, a tall structure which can endanger air 
traffic, has to be marked with red and white colored markings and 
with aircraft warning lights at night. If you look at these 
communication towers this is how they are actually painted.


An airman say a pilot of a medicopter may well study terrain 
carefully on a map before a flight. In fact it is not a flight as a 
bird flies, but rather a jump as there is a time limit, an endurance. 
That is why a planning is necessary.


Unfortunately on the OSM map he/she will not see any icon. At the 
same time the air-traffic in urban areas will continue to increase. 
It is future of urban mobility [1].


If a helicopter, an RPAS, a plane touches a mast or a cable it would 
crash; a mast may collapse. For individuals involved it could 
certainly be a disaster.


People do realize it. Andy not only mapped the communication tower 
(or mast) but plans to map its cables. It is a good idea too. It will 
take time to map all these towers (masts), measure and calculate 
their height, etc.


Unfortunately the confusion between "man_made=tower" and 
"man_made=mast" continues. One is rendered and one is not, and that 
adds to confusion.


[1] 
http://www.airbusgroup.com/int/en/news-media/corporate-magazine/Forum-88/My-Kind-Of-Flyover.html


With best regards,

Oleksiy


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



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

Re: [OSM-talk] Tagging and rendering of television masts

2017-04-23 Thread Andy Townsend 

On 22/04/2017 07:33, Oleksiy Muzalyev wrote:


It is possible to map it as: "man_made=mast", "height=190", etc., then 
it will be rendered.


In the general case, please don't suggest that people mistag things just 
so that one particular renderer (one that probably isn't used by the 
majority of people that consume OSM data*) renders it.


However in this particular case I can't claim to be familiar enough with 
it to say whether 
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dtower or 
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dmast is more 
appropropriate, or indeed whether those wiki pages reflect OSM usage.


Best Regards,

Andy

* I'm guessing the "most views" accolade goes to either Mapbox Streets 
or MAPS.ME these days.


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

Re: [OSM-talk] Tagging and rendering of television masts

2017-04-23 Thread Andreas Vilén 
Please read http://wiki.openstreetmap.org/wiki/Aviation

Pilots do not use the osm base map...

/Andreas

Skickat från min iPhone

> 23 apr. 2017 kl. 07:50 skrev Oleksiy Muzalyev :
> 
>> On 22.04.17 21:17, Martin Koppenhoefer wrote:
>> 
>> sent from a phone
>> 
>>> On 22. Apr 2017, at 08:33, Oleksiy Muzalyev  
>>> wrote:
>>> 
>>> In my opinion, it is a significant issue, in fact a disaster waiting to 
>>> happen. There will be soon air-born taxi in Dubai, Singapore, etc., and the 
>>> extremely high communication towers, the so-called aviation traffic 
>>> obstacles https://en.wikipedia.org/wiki/Air_traffic_obstacle , are not 
>>> rendered on the OSM map at all.
>> 
>> which disaster do you expect to happen? Someone flying around in dense fog 
>> and using no other information than osm-carto?
>> 
>> I agree it is a shortcoming that towers are not rendered on osm-carto, but 
>> we should keep calm and not exaggerate its significance.
>> 
>> cheers,
>> Martin
> 
> Dear Martin,
> 
> An air traffic obstacle, a tall structure which can endanger air traffic, has 
> to be marked with red and white colored markings and with aircraft warning 
> lights at night. If you look at these communication towers this is how they 
> are actually painted.
> 
> An airman say a pilot of a medicopter may well study terrain carefully on a 
> map before a flight. In fact it is not a flight as a bird flies, but rather a 
> jump as there is a time limit, an endurance. That is why a planning is 
> necessary.
> 
> Unfortunately on the OSM map he/she will not see any icon. At the same time 
> the air-traffic in urban areas will continue to increase. It is future of 
> urban mobility [1].
> 
> If a helicopter, an RPAS, a plane touches a mast or a cable it would crash; a 
> mast may collapse. For individuals involved it could certainly be a disaster.
> 
> People do realize it. Andy not only mapped the communication tower (or mast) 
> but plans to map its cables. It is a good idea too. It will take time to map 
> all these towers (masts), measure and calculate their height, etc.
> 
> Unfortunately the confusion between "man_made=tower" and "man_made=mast" 
> continues. One is rendered and one is not, and that adds to confusion.
> 
> [1] 
> http://www.airbusgroup.com/int/en/news-media/corporate-magazine/Forum-88/My-Kind-Of-Flyover.html
> 
> With best regards,
> 
> Oleksiy
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tagging and rendering of television masts

2017-04-22 Thread Oleksiy Muzalyev 

On 22.04.17 21:17, Martin Koppenhoefer wrote:


sent from a phone


On 22. Apr 2017, at 08:33, Oleksiy Muzalyev  wrote:

In my opinion, it is a significant issue, in fact a disaster waiting to happen. 
There will be soon air-born taxi in Dubai, Singapore, etc., and the extremely 
high communication towers, the so-called aviation traffic obstacles 
https://en.wikipedia.org/wiki/Air_traffic_obstacle , are not rendered on the 
OSM map at all.


which disaster do you expect to happen? Someone flying around in dense fog and 
using no other information than osm-carto?

I agree it is a shortcoming that towers are not rendered on osm-carto, but we 
should keep calm and not exaggerate its significance.

cheers,
Martin


Dear Martin,

An air traffic obstacle, a tall structure which can endanger air 
traffic, has to be marked with red and white colored markings and with 
aircraft warning lights at night. If you look at these communication 
towers this is how they are actually painted.


An airman say a pilot of a medicopter may well study terrain carefully 
on a map before a flight. In fact it is not a flight as a bird flies, 
but rather a jump as there is a time limit, an endurance. That is why a 
planning is necessary.


Unfortunately on the OSM map he/she will not see any icon. At the same 
time the air-traffic in urban areas will continue to increase. It is 
future of urban mobility [1].


If a helicopter, an RPAS, a plane touches a mast or a cable it would 
crash; a mast may collapse. For individuals involved it could certainly 
be a disaster.


People do realize it. Andy not only mapped the communication tower (or 
mast) but plans to map its cables. It is a good idea too. It will take 
time to map all these towers (masts), measure and calculate their 
height, etc.


Unfortunately the confusion between "man_made=tower" and "man_made=mast" 
continues. One is rendered and one is not, and that adds to confusion.


[1] 
http://www.airbusgroup.com/int/en/news-media/corporate-magazine/Forum-88/My-Kind-Of-Flyover.html


With best regards,

Oleksiy


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

Re: [OSM-talk] Tagging and rendering of television masts

2017-04-22 Thread Andy Mabbett 
On 22 April 2017 at 07:33, Oleksiy Muzalyev  wrote:

> It is possible to map it as: "man_made=mast", "height=190", etc., then it
> will be rendered.

I have now changed the objects to use this method. (As noted
previously, I have no height data for the Portuguese mast)

> One could also add a "wikidata" tag

For Sutton Coldfield, that tag is on the while station, not just the mast.

What about tagging the anchor points and cables, as mentioned in my
original post?




-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] Tagging and rendering of television masts

2017-04-22 Thread Martin Koppenhoefer 


sent from a phone

> On 22. Apr 2017, at 08:33, Oleksiy Muzalyev  
> wrote:
> 
> In my opinion, it is a significant issue, in fact a disaster waiting to 
> happen. There will be soon air-born taxi in Dubai, Singapore, etc., and the 
> extremely high communication towers, the so-called aviation traffic obstacles 
> https://en.wikipedia.org/wiki/Air_traffic_obstacle , are not rendered on the 
> OSM map at all.


which disaster do you expect to happen? Someone flying around in dense fog and 
using no other information than osm-carto?

I agree it is a shortcoming that towers are not rendered on osm-carto, but we 
should keep calm and not exaggerate its significance.

cheers,
Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tagging and rendering of television masts

2017-04-22 Thread Oleksiy Muzalyev 

On 22.04.17 00:56, Andy Mabbett wrote:

the Sutton Coldfield (England) TV mast:

https://en.wikipedia.org/wiki/Sutton_Coldfield_transmitting_station

at:


http://www.opensntreetmap.org/?mlat=37.08321=-8.13643#map=17/37.0832/-8.1364

is a significant landmark, visible for several miles, and illuminated
at night. Yet it does not render. Is it missing a tag, or do we need
to tweak the rendering rules?

I became aware of this today, when I added a similar mast, at
Vilamoura (Portugal):


http://www.openstreetmap.org/?mlat=37.0830=-8.1364#map=17/37.0830/-8.1364

For that, I included three support wires, and three anchor points -
how should those be tagged?


Dear Andy,

It is possible to map it as: "man_made=mast", "height=190", etc., then 
it will be rendered. See an example:


https://www.openstreetmap.org/way/409948785#map=17/46.45003/30.74254

A "mast" is in the JOSM list for "man_made" already.

The issue that "man_made=tower" is not rendered on the OSM map had been 
raised already on the mailing lists. In my opinion, it is a significant 
issue, in fact a disaster waiting to happen. There will be soon air-born 
taxi in Dubai, Singapore, etc., and the extremely high communication 
towers, the so-called aviation traffic obstacles 
https://en.wikipedia.org/wiki/Air_traffic_obstacle , are not rendered on 
the OSM map at all.


On other maps say Maps.me map "man_made"=tower is rendered all right.

One could also add a "wikidata" tag to a mast or a tower. Almost all of 
these high structures have got a Wikipedia article.


Best regards,

Oleksiy




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

Re: [OSM-talk] Tagging and rendering of television masts

2017-04-21 Thread Martin Koppenhoefer 


sent from a phone

> On 22. Apr 2017, at 01:37, Andy Townsend  wrote:
> 
> The current tagging (man_made=tower; tower:type=communication) looks OK to me.


The word "communication" to me means a two-way exchange of information/ideas 
(mutual, e.g. a phone call). For television, the word "broadcast" would seem 
more appropriate.


cheers,
Martin 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Tagging and rendering of television masts

2017-04-21 Thread Andy Townsend 

On 21/04/2017 22:56, Andy Mabbett wrote:

the Sutton Coldfield (England) TV mast:

https://en.wikipedia.org/wiki/Sutton_Coldfield_transmitting_station

at:


http://www.opensntreetmap.org/?mlat=37.08321=-8.13643#map=17/37.0832/-8.1364


That's the one in Portugal, I think?

Sutton Coldfield is at:

https://www.openstreetmap.org/node/6044107

The discussion about how to render things like this in the standard 
style is at 
https://github.com/gravitystorm/openstreetmap-carto/issues/339 (and 
probably other places).


The current tagging (man_made=tower; tower:type=communication) looks OK 
to me.  An alternative might be to do as per Lichfield 
https://www.openstreetmap.org/node/1258302194 
(man_made=communications_tower), which the "standard" style also doesn't 
render.


I currently show them as e.g. 
https://map.atownsend.org.uk/maps/map/map.html#zoom=18=52.600125=-1.833634 
(with a name as well).  One thing that I had given a bit of thought to 
was to have _very_ tall towers appear at lower zoom levels.  It'd 
involve doing a bit of maths in the lua tag transform script, which is 
surely possible, but not something that I've not looked at at all - and 
for Sutton Coldfield it'd need the height tagging as well.


Best Regards,

Andy


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

[OSM-talk] Tagging and rendering of television masts

2017-04-21 Thread Andy Mabbett 
the Sutton Coldfield (England) TV mast:

   https://en.wikipedia.org/wiki/Sutton_Coldfield_transmitting_station

at:

   
http://www.opensntreetmap.org/?mlat=37.08321=-8.13643#map=17/37.0832/-8.1364

is a significant landmark, visible for several miles, and illuminated
at night. Yet it does not render. Is it missing a tag, or do we need
to tweak the rendering rules?

I became aware of this today, when I added a similar mast, at
Vilamoura (Portugal):

   
http://www.openstreetmap.org/?mlat=37.0830=-8.1364#map=17/37.0830/-8.1364

For that, I included three support wires, and three anchor points -
how should those be tagged?

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [OSM-talk] tagging and rendering

2008-05-13 Thread Lester Caine 
elvin ibbotson wrote:
 Typos in real words are easier to detect than a mistake in entering a 
 number.

 In the scenario I was suggesting numbers would only replace words for 
 type tags and users would never see the numbers but would just see words 
 (in their own language) mapped to/from numbers in the database by the 
 editor/viewer software. This somewhere between the ID numbers (set 
 purely by software) and latitude/longitude (which users do not enter 
 directly) and all the other tags, most of which (like name=) require 
 user direct input.

Some considerable time ago I tried to push the idea of using numeric types for 
the key map data so that translation is easy and since then I've been 
reconsidering how it could be done if I was going to run something locally.

highway, cycleway, waterway, railway, leisure and the like provide a top level 
  number and the 'approved' values provide sub-numbers. So that 'key' 101 
- for example - would be a highway:motorway. Just storing a single number for 
that data. We can maintain the free format by using 100 to indicate that 
there IS a string element to go with the tag.
All the 'way' tags would be 1xx, so 101 = cycleway, 102 = waterway etc.
Leisure/amenity/shop would become a 2xx series and so on.

0xx tags would then be used for additional data such as note, name, 
description, source ( with sub tags for approved sources ).

Reserving say 9xx for private tags that would only be used with perhaps a 
particular user ID so people could potentially use 900 for private notes .

Tools would then simply pick up a language file for their own translations of 
those numbers and create new tags or edit existing tags based on the list 
provided in their particular language set. If free form text is added then 
perhaps a warning could be posted about non-rendered data being added? Or even 
a switch to prevent free form data if not appropriate.

I am still looking at this from an internal storage point of view, and 
nowadays who actually TYPES the text for the main key entries - you just copy 
an existing item, or select from the list? The debate really is do we need to 
maintain a full 'XML' view of the data at all? By switching to a much more 
compact storage mechanism, data can be output as a full XML extract - perhaps 
even with a language switch for extracts in the target countries language - if 
required? But a compact - language agnostic - format would improve performance 
in a number of areas?

-- 
Lester Caine - G8HFL
-
Contact - http://home.lsces.co.uk/lsces/wiki/?page=contact
L.S.Caine Electronic Services - http://home.lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk//
Firebird - http://www.firebirdsql.org/index.php

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-12 Thread elvin ibbotson 

I'm grouping a replies to several posts for this topic...


On 9 May 2008, at 19:13, Jeffrey Martin wrote:

Typos in real words are easier to detect than a mistake in entering  
a number.




In the scenario I was suggesting numbers would only replace words for  
type tags and users would never see the numbers but would just see  
words (in their own language) mapped to/from numbers in the database  
by the editor/viewer software. This somewhere between the ID numbers  
(set purely by software) and latitude/longitude (which users do not  
enter directly) and all the other tags, most of which (like name=)  
require user direct input.





From: Jeffrey Martin [EMAIL PROTECTED]
Date: 9 May 2008 15:09:39 BDT
To: elvin ibbotson [EMAIL PROTECTED],  OSM Talk  
talk@openstreetmap.org

Subject: Re: [OSM-talk] tagging and rendering

The rendering should be separate from the data. Marking a hiking trail
as an autobahn so it will be a different color or be visible on higher
zoom levels I think we all agree is wrong.

Provided the data is correct, I don't see a problem with altering the
way data is collected and recorded to make it easier for renderers,
and those who program them and write the rendering rules.



I can see the attraction to the use of numbers for the values of the
highway tag. Having a new system that does not use terms that
have other meanings can force people to think about the OSM
definitions of the values. The UK centric terms have this effect
for me. I have to think about what motorway means for the US
or Korea in terms of the OSM definition because I have no competing
definition of the term motorway in my mind. For me motorway
only has an OSM definition.



I have today tagged a little country lane in my area as a railway  
line as well as highway=unclassified, as the free-from tagging system  
would seem to allow this and I wanted to see how it will be rendered  
by Mapnik and Osmarender.  I'm all for freedom but I think the type  
of a node or way is (like node ID and latitude/longitude) more  
fundamental than most tags which would retain user input and the  
potential to invent new tags.



From: Jonathan Bennett [EMAIL PROTECTED]
Date: 9 May 2008 19:55:01 BDT
To: talk@openstreetmap.org
Subject: Re: [OSM-talk] tagging and rendering


elvin ibbotson wrote:

Things humans read need to be human readable. The database should  
be  read by software and if it can be faster and more efficient  
using  numbers, numbers are what should be used.





The best way of proving this would be to come up with your own  
version of the OSM server stack that used ID numbers internally,  
while still outputting human-readable tag names. How long do you  
think it would take you?


I don't think we want another server. I can already demonstrate it:
I am currently experimenting with binary data downloads for my mobile  
OSM viewer, mom. I need data for scales from 3 (just coastlines and  
country boundaries for enormous areas) to scale 15 (almost everything  
in a limited area) and until there is a binary API the data has to be  
sourced as XML then parsed to binary. The standard OSM API does not  
have any level-of-detail filtering so I am using XAPI. To get data  
for a particular scale I have to make several calls to the XAPI for  
each feature group (natural, highway, waterway, ...) in turn, and  
each call takes quite a bit of setting up in the code. If, for  
example, the feature types were structured using a numerical system  
such that  so that all natural features began with 0, all highways  
with 1, etc, but everything needed at scales smaller than 5 ended  
with numbers smaller than 3 (eg. coastlines: 01; trunk roads: 12) I  
could make a simple call for features less than *3.





From: Martijn van Oosterhout [EMAIL PROTECTED]
Date: 9 May 2008 19:51:18 BDT
To: Jeffrey Martin [EMAIL PROTECTED]
Cc: OSM Talk talk@openstreetmap.org
Subject: Re: [OSM-talk] street traits


On Fri, May 9, 2008 at 8:30 PM, Jeffrey Martin [EMAIL PROTECTED]  
wrote:


A name for each kind of road in a person's country could be set up  
as an

editor feature. I select
mountain road 2 from my list and it fills in the number of  
lanes, lane

size, shoulder size, etc.
for me.



Strangly enough, JOSM supports this already.


Another option might be to have some kind of bot that fills in  
specific data

based on country
specific highway tags.



I thin you're missing something though. Just because it says
highway=motorway doesn't mean it looks identical everywhere. It means
what a motorway is in the country its located in. Just determine which
types of roads there are (there are about 7 usually, no matter what
the country) and then map those to the existing highway tags. All
done.

If you want to add stuff like lanes/etc go ahead, but for the basics
you don't need it.



A new thread but more evidence that feature type tagging is  
fundamental and may need rethinking. ___
talk

Re: [OSM-talk] tagging and rendering

2008-05-12 Thread Chris Jones 

 I don't think we want another server. I can already demonstrate it:
 I am currently experimenting with binary data downloads for my mobile 
 OSM viewer, mom http://mom.poco.org.uk/. I need data for scales from 
 3 (just coastlines and country boundaries for enormous areas) to scale 
 15 (almost everything in a limited area) and until there is a binary 
 API the data has to be sourced as XML then parsed to binary. The 
 standard OSM API does not have any level-of-detail filtering so I am 
 using XAPI. To get data for a particular scale I have to make several 
 calls to the XAPI for each feature group (natural, highway, waterway, 
 ...) in turn, and each call takes quite a bit of setting up in the 
 code. If, for example, the feature types were structured using a 
 numerical system such that  so that all natural features began with 0, 
 all highways with 1, etc, but everything needed at scales smaller than 
 5 ended with numbers smaller than 3 (eg. coastlines: 01; trunk roads: 
 12) I could make a simple call for features less than *3.
At some point there is still going to have to be a map between the 
freeform tags and your numbering scheme.. your example makes me think 
you simply want someone else to implement and maintain it so your 
application becomes easier to code.

Have you considered processing the Mapnik or Osmarender style rules to 
decide what to include/exclude at each scale?

-- 
Chris Jones, SUCS Admin
http://sucs.org


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-12 Thread Cartinus 
On Monday 12 May 2008 11:50:15 elvin ibbotson wrote:
 If, for  
 example, the feature types were structured using a numerical system  
 such that  so that all natural features began with 0, all highways  
 with 1, etc, but everything needed at scales smaller than 5 ended  
 with numbers smaller than 3 (eg. coastlines: 01; trunk roads: 12) I  
 could make a simple call for features less than *3.

Like already pointed out before:

This only works if your idea of important is the same as the idea of important 
of the ones that did the initial ordering. However for a motorist a motorway 
is the most important road, for a cyclist a cycleway is the most important 
road and for a canal boater roads are not important at all.

-- 
m.v.g.,
Cartinus

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-12 Thread Cartinus 
On Friday 09 May 2008 11:27:21 elvin ibbotson wrote:
 Much debate centres around the way features are tagged and how they  
 are rendered (for example recent discussion of golf course tagging,  
 the term 'highway', rendering power lines,...) and it seems that much  
 of this is inextricably involved with the OSM data itself. I  
 wondered if it was time, while OSM is still relatively young and  
 before it becomes too ossified and institutionalised, for the  
 approach to be reviewed.

 My own thoughts, for what they are worth, are that the data structure  
 should be language/locale agnostic. For example, ways could have a  
 numeric type field with, hypothetically, 10-19 being used for roads.  
 In this scenario 11 might be a UK motorway, an Italian autostrada or  
 an American interstate, while 19 might be a rough track (10 being  
 reserved for some not-yet-invented super highway, after all some of  
 us were here before motorways).

 The editors used to input data (Potlatch, JOSM, whatever) would hide  
 this structured data from the user and translate it to/from human  
 language. One immediate advantage is that a German user could tag an  
 autobahn rather than a motorway and global users would not have to  
 use language clearly derived from the British motorway/trunk road/A/B  
 (and little-known C) road classification system. Instead, local  
 nomenclature would be mapped (no pun intended) to the underlying data  
 structure by the local edition of the editor. Highways are an obvious  
 example we are all familiar with, but the principle would apply to  
 all feature types. Places of worship could be mapped as cathedrals,  
 churches, chapels, etc in Britain or as mosques, temples, shrines,  
 whatever in the east.

Problem you are trying to solve:
Discussion about tag names

Proposed solution:
Make tags numerical and have translations from numbers to names for multiple 
languages.

Probable effect:
The same discussion about the translations as before about the tag names, but 
now multiplied by the number of supported languages.

-- 
m.v.g.,
Cartinus

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-12 Thread SteveC 

On 9 May 2008, at 03:30, elvin ibbotson wrote:

 On 9 May 2008, at 11:05, Dave Stubbs wrote:


 As far as I see it there is no difference between mapping  
 11=autobahn,
 and mapping motorway=autobahn.

 I think you missed the point. At present we have highway=motorway and
 I believe a German user would need to use these words. What I suggest

but what you're suggesting is that we make it crap for everybody, not  
just germans

more logical might be to have everything in mandarin or spanish or  
whatever the most spoken language is

Best

Steve


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-10 Thread Chris Jones 

On 9 May 2008, at 19:55, Jonathan Bennett wrote:

 elvin ibbotson wrote:
 Things humans read need to be human readable. The database should be
 read by software and if it can be faster and more efficient using
 numbers, numbers are what should be used.


 The best way of proving this would be to come up with your own version
 of the OSM server stack that used ID numbers internally, while still
 outputting human-readable tag names. How long do you think it would  
 take
 you?


Some database engines can automatically compress data by replacing  
common values with look-up value for a dictionary containing the true  
value.

http://www.ibm.com/developerworks/db2/library/techarticle/ 
dm-0605ahuja/index.html explains the idea better than i do.

I would expect its only a matter of time before such features appear  
in the open-source database engines.

--
Chris Jones, SUCS Admin
http://sucs.org

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] tagging and rendering

2008-05-09 Thread elvin ibbotson 
Much debate centres around the way features are tagged and how they  
are rendered (for example recent discussion of golf course tagging,  
the term 'highway', rendering power lines,...) and it seems that much  
of this is inextricably involved with the OSM data itself. I   
wondered if it was time, while OSM is still relatively young and  
before it becomes too ossified and institutionalised, for the  
approach to be reviewed.

My own thoughts, for what they are worth, are that the data structure  
should be language/locale agnostic. For example, ways could have a  
numeric type field with, hypothetically, 10-19 being used for roads.  
In this scenario 11 might be a UK motorway, an Italian autostrada or  
an American interstate, while 19 might be a rough track (10 being  
reserved for some not-yet-invented super highway, after all some of  
us were here before motorways).

The editors used to input data (Potlatch, JOSM, whatever) would hide  
this structured data from the user and translate it to/from human  
language. One immediate advantage is that a German user could tag an  
autobahn rather than a motorway and global users would not have to  
use language clearly derived from the British motorway/trunk road/A/B  
(and little-known C) road classification system. Instead, local  
nomenclature would be mapped (no pun intended) to the underlying data  
structure by the local edition of the editor. Highways are an obvious  
example we are all familiar with, but the principle would apply to  
all feature types. Places of worship could be mapped as cathedrals,  
churches, chapels, etc in Britain or as mosques, temples, shrines,  
whatever in the east.

Rendering of the data is I think less tied up with the data itself,  
but again could be implemented differently by different map viewers.  
My paper road map of Ireland shows primary roads red in Ulster and  
green in Eire. Autbahns are green on my map of the Alps while  
autopistas are patriotically red and yellow on my Spanish map. Local  
or customisable viewers are possible with the current OSM but not, as  
far as I know, implemented yet, but the principle of separating the  
core data from the way it is described and depicted is, I believe,  
important.

Another aspect of the base data structure is that of level-of-detail  
(LoD) filtering. This is obviously done at present (villages and  
footpaths disappear as you zoom out) but is dictated by the people  
who code the viewers and is not, as far as I know, very well  
addressed in the API, so LoD filtering has to be done after data has  
been acquired, when it should be possible to specify LoD when  
requesting data. If LoD were considered in structuring the database  
it would be easy to filter data (eg. road types 10-13 only or for  
major ways of all types *0-*3). This is simpler for programming than  
clumsily using named tags (highway=motorway|trunk|primary) and would  
be invisible to users who might see autopista, autovia or carretera  
general.

elvin ibbotson

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread Dave Stubbs 
On Fri, May 9, 2008 at 10:27 AM, elvin ibbotson
[EMAIL PROTECTED] wrote:
 Much debate centres around the way features are tagged and how they
 are rendered (for example recent discussion of golf course tagging,
 the term 'highway', rendering power lines,...) and it seems that much
 of this is inextricably involved with the OSM data itself. I
 wondered if it was time, while OSM is still relatively young and
 before it becomes too ossified and institutionalised, for the
 approach to be reviewed.

 My own thoughts, for what they are worth, are that the data structure
 should be language/locale agnostic. For example, ways could have a
 numeric type field with, hypothetically, 10-19 being used for roads.
 In this scenario 11 might be a UK motorway, an Italian autostrada or
 an American interstate, while 19 might be a rough track (10 being
 reserved for some not-yet-invented super highway, after all some of
 us were here before motorways).

 The editors used to input data (Potlatch, JOSM, whatever) would hide
 this structured data from the user and translate it to/from human
 language. One immediate advantage is that a German user could tag an
 autobahn rather than a motorway and global users would not have to
 use language clearly derived from the British motorway/trunk road/A/B
 (and little-known C) road classification system. Instead, local
 nomenclature would be mapped (no pun intended) to the underlying data
 structure by the local edition of the editor.


What makes this not possible with named tags like we have at present?
As far as I see it there is no difference between mapping 11=autobahn,
and mapping motorway=autobahn. As long as we have enough highway
grades to cover the uses I don't think just numbering stuff will
actually improve anything. You could already build an editor that
remaps the highway tags to a local equivalent (it would probably be
best to do it via presets so as not to confuse people).


 Highways are an obvious
 example we are all familiar with, but the principle would apply to
 all feature types. Places of worship could be mapped as cathedrals,
 churches, chapels, etc in Britain or as mosques, temples, shrines,
 whatever in the east.

Um... except that Britain has quite a lot of mosques, temples and
shrines. These are different things, not the same things named
differently.



 Rendering of the data is I think less tied up with the data itself,
 but again could be implemented differently by different map viewers.
 My paper road map of Ireland shows primary roads red in Ulster and
 green in Eire. Autbahns are green on my map of the Alps while
 autopistas are patriotically red and yellow on my Spanish map. Local
 or customisable viewers are possible with the current OSM but not, as
 far as I know, implemented yet, but the principle of separating the
 core data from the way it is described and depicted is, I believe,
 important.


This is why we don't have (and have resisted) tags such as highway=red.

People have done customised renderings... see Freemap Slovakia for example:
http://www.freemap.sk/?lang=enzoom=8lat=48.49281826990847lon=18.326709281821315layers=BF0FFFT



 Another aspect of the base data structure is that of level-of-detail
 (LoD) filtering. This is obviously done at present (villages and
 footpaths disappear as you zoom out) but is dictated by the people
 who code the viewers and is not, as far as I know, very well
 addressed in the API, so LoD filtering has to be done after data has
 been acquired, when it should be possible to specify LoD when
 requesting data. If LoD were considered in structuring the database
 it would be easy to filter data (eg. road types 10-13 only or for
 major ways of all types *0-*3). This is simpler for programming than
 clumsily using named tags (highway=motorway|trunk|primary) and would
 be invisible to users who might see autopista, autovia or carretera
 general.


It's true that filtering highways based on a purely numeric system
would be simpler than having to maintain a comprehensive list of
highway type names, but this only really covers the standard map
display where you count motorways as the most important thing on the
map. If you consider something like the cycle map where we have ncn as
the things that should show up at zoom level 6 instead, then we have
to apply different rules.
So we only really gain something if the LoD demands happen to coincide
with the data model you define.

LoD is generally a more complicated problem that requires you to
actually define a whole array of features, and mechanisms for
simplification.


Dave

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread elvin ibbotson 
On 9 May 2008, at 11:05, Dave Stubbs wrote:


 As far as I see it there is no difference between mapping 11=autobahn,
 and mapping motorway=autobahn.

I think you missed the point. At present we have highway=motorway and  
I believe a German user would need to use these words. What I suggest  
is that if Potlatch is used on a German computer the user would be  
presented with a menu of road types starting with 'autobahn' while I  
would see a menu starting with 'motorway', both mapping to a database  
field of (hypothetically) 11. I can't see how 'motorway=autobahn'  
helps with anything.



 Places of worship could be mapped as cathedrals,
 churches, chapels, etc in Britain or as mosques, temples, shrines,
 whatever in the east.

 Um... except that Britain has quite a lot of mosques, temples and
 shrines. These are different things, not the same things named
 differently.

Fair point - I didn't think that one through until I'd clicked SEND.  
Best not talk about religion, eh?


 This is why we don't have (and have resisted) tags such as  
 highway=red.

Point missed again! I'm saying separate rendering from tagging.  
highway=red is exactly the opposite of what I'm suggesting.


 People have done customised renderings... see Freemap Slovakia for  
 example:
 http://www.freemap.sk/? 
 lang=enzoom=8lat=48.49281826990847lon=18.326709281821315layers=BF0 
 FFFT


Yes. Anyone can put up their own viewer, but I imagine most use the  
one on the OSM site and that could (possibly) render the content  
differently according to the keyboard language or to some locale  
setting in its control panel



 Another aspect of the base data structure is that of level-of-detail
 (LoD) filtering. ...


 If you consider something like the cycle map where we have ncn as
 the things that should show up at zoom level 6 instead, then we have
 to apply different rules.

No problemo! Special viewers like the cycle map would simply apply  
their own filters. And with well-structured data a map viewer could  
even have settings (eg. cycle routes on/off) allowing it to be  
customised by the user, making a proliferation of specialist viewers  
unnecessary.

 So we only really gain something if the LoD demands happen to coincide
 with the data model you define.

 LoD is generally a more complicated problem that requires you to
 actually define a whole array of features, and mechanisms for
 simplification.

I never said it was going to be easy :-) I do think that LoD demands  
are something that should be considered in designing the data  
structure. (I also think elevational data should be well integrated,  
too, but that's another topic.)

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread Dave Stubbs 
On Fri, May 9, 2008 at 11:30 AM, elvin ibbotson
[EMAIL PROTECTED] wrote:
 On 9 May 2008, at 11:05, Dave Stubbs wrote:


 As far as I see it there is no difference between mapping 11=autobahn,
 and mapping motorway=autobahn.

 I think you missed the point. At present we have highway=motorway and I
 believe a German user would need to use these words. What I suggest is that
 if Potlatch is used on a German computer the user would be presented with a
 menu of road types starting with 'autobahn' while I would see a menu
 starting with 'motorway', both mapping to a database field of
 (hypothetically) 11. I can't see how 'motorway=autobahn' helps with
 anything.

No, you've missed the point.
Potlatch can just as easily say:
highway=motorway -- [german for highway]=autobahn

as it can:
highway=11 -- [german for highway]=autobahn

The mapping to numbers doesn't gain us anything. It doesn't let us do
anything we can't already do, or make it any easier as far as I can
see.

I think you were actually suggesting something like type=11 -- where
10-20 means roads, 30-40 could mean railways etc. But as far as this
argument goes it doesn't really make much difference, other than
leaving us with a massive allocation problem which has been neatly
sidestepped by using free-form tagging.



 Places of worship could be mapped as cathedrals,
 churches, chapels, etc in Britain or as mosques, temples, shrines,
 whatever in the east.

 Um... except that Britain has quite a lot of mosques, temples and
 shrines. These are different things, not the same things named
 differently.

 Fair point - I didn't think that one through until I'd clicked SEND. Best
 not talk about religion, eh?


 This is why we don't have (and have resisted) tags such as highway=red.

 Point missed again! I'm saying separate rendering from tagging. highway=red
 is exactly the opposite of what I'm suggesting.


Indeed point missed again.
We DON'T DO (sorry Richard) highway=red. We do highway=primary and you
can make that any colour you like... same as you can do with
highway=13/type=13 -- it makes no difference is my point. Numbering
the highways won't help.



 People have done customised renderings... see Freemap Slovakia for
 example:

 http://www.freemap.sk/?lang=enzoom=8lat=48.49281826990847lon=18.326709281821315layers=BF0FFFT


 Yes. Anyone can put up their own viewer, but I imagine most use the one on
 the OSM site and that could (possibly) render the content differently
 according to the keyboard language or to some locale setting in its control
 panel


It could yes. There are a couple of issues with this mostly to do with
actually maintaining the style sheets and providing the processing
power/disk space.



 Another aspect of the base data structure is that of level-of-detail
 (LoD) filtering. ...


 If you consider something like the cycle map where we have ncn as
 the things that should show up at zoom level 6 instead, then we have
 to apply different rules.

 No problemo! Special viewers like the cycle map would simply apply their own
 filters. And with well-structured data a map viewer could even have settings
 (eg. cycle routes on/off) allowing it to be customised by the user, making a
 proliferation of specialist viewers unnecessary.


Hmm.. yes, maybe. But the point of your e-mail was essentially
numbering everything, and that really doesn't help us with this goal.

Dave

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread Vincent MEURISSE 
No, you've missed the point.
Potlatch can just as easily say:
highway=motorway -- [german for highway]=autobahn

as it can:
highway=11 -- [german for highway]=autobahn

You can look at merkaartor. It implement something like that. When you
draw a road, it show up a translated list for the tags. I thing that
an editor must hide tags for most usages to avoid tagging errors and
allows power users to change row tags.

 For example, ways could have a
numeric type field with, hypothetically, 10-19 being used for roads.
In this scenario 11 might be a UK motorway, an Italian autostrada or
an American interstate, while 19 might be a rough track

And why use tags at all. We can use highway=1 railway=2 amenity=3
name=4. Then we will renouce to xml format and use a binary one and
then close the source of osm software.
Seriously we use xml. The principle of xml is to be human readable and
use text attribute. If there is any tagging facility and tags
translation, it's the job of the editor.




On Fri, May 9, 2008 at 1:21 PM, Dave Stubbs [EMAIL PROTECTED] wrote:
 On Fri, May 9, 2008 at 11:30 AM, elvin ibbotson
 [EMAIL PROTECTED] wrote:
 On 9 May 2008, at 11:05, Dave Stubbs wrote:


 As far as I see it there is no difference between mapping 11=autobahn,
 and mapping motorway=autobahn.

 I think you missed the point. At present we have highway=motorway and I
 believe a German user would need to use these words. What I suggest is that
 if Potlatch is used on a German computer the user would be presented with a
 menu of road types starting with 'autobahn' while I would see a menu
 starting with 'motorway', both mapping to a database field of
 (hypothetically) 11. I can't see how 'motorway=autobahn' helps with
 anything.

 No, you've missed the point.
 Potlatch can just as easily say:
 highway=motorway -- [german for highway]=autobahn

 as it can:
 highway=11 -- [german for highway]=autobahn

 The mapping to numbers doesn't gain us anything. It doesn't let us do
 anything we can't already do, or make it any easier as far as I can
 see.

 I think you were actually suggesting something like type=11 -- where
 10-20 means roads, 30-40 could mean railways etc. But as far as this
 argument goes it doesn't really make much difference, other than
 leaving us with a massive allocation problem which has been neatly
 sidestepped by using free-form tagging.



 Places of worship could be mapped as cathedrals,
 churches, chapels, etc in Britain or as mosques, temples, shrines,
 whatever in the east.

 Um... except that Britain has quite a lot of mosques, temples and
 shrines. These are different things, not the same things named
 differently.

 Fair point - I didn't think that one through until I'd clicked SEND. Best
 not talk about religion, eh?


 This is why we don't have (and have resisted) tags such as highway=red.

 Point missed again! I'm saying separate rendering from tagging. highway=red
 is exactly the opposite of what I'm suggesting.


 Indeed point missed again.
 We DON'T DO (sorry Richard) highway=red. We do highway=primary and you
 can make that any colour you like... same as you can do with
 highway=13/type=13 -- it makes no difference is my point. Numbering
 the highways won't help.



 People have done customised renderings... see Freemap Slovakia for
 example:

 http://www.freemap.sk/?lang=enzoom=8lat=48.49281826990847lon=18.326709281821315layers=BF0FFFT


 Yes. Anyone can put up their own viewer, but I imagine most use the one on
 the OSM site and that could (possibly) render the content differently
 according to the keyboard language or to some locale setting in its control
 panel


 It could yes. There are a couple of issues with this mostly to do with
 actually maintaining the style sheets and providing the processing
 power/disk space.



 Another aspect of the base data structure is that of level-of-detail
 (LoD) filtering. ...


 If you consider something like the cycle map where we have ncn as
 the things that should show up at zoom level 6 instead, then we have
 to apply different rules.

 No problemo! Special viewers like the cycle map would simply apply their own
 filters. And with well-structured data a map viewer could even have settings
 (eg. cycle routes on/off) allowing it to be customised by the user, making a
 proliferation of specialist viewers unnecessary.


 Hmm.. yes, maybe. But the point of your e-mail was essentially
 numbering everything, and that really doesn't help us with this goal.

 Dave

 ___
 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] tagging and rendering

2008-05-09 Thread Jeffrey Martin 
The rendering should be separate from the data. Marking a hiking trail
as an autobahn so it will be a different color or be visible on higher
zoom levels I think we all agree is wrong.

Provided the data is correct, I don't see a problem with altering the
way data is collected and recorded to make it easier for renderers,
and those who program them and write the rendering rules.



I can see the attraction to the use of numbers for the values of the
highway tag. Having a new system that does not use terms that
have other meanings can force people to think about the OSM
definitions of the values. The UK centric terms have this effect
for me. I have to think about what motorway means for the US
or Korea in terms of the OSM definition because I have no competing
definition of the term motorway in my mind. For me motorway
only has an OSM definition.

People in countries with roads called motorways have a conflict
in their minds. If a section of a UK motorway is a single lane
dirt track then someone in the UK may be tempted to label
it as a motorway because it has a motorway sign. (That's just
a hyperbole to make a point. Let's keep discussions of the
highway tag itself on a separate thread.)

One solution to this psychology problem is to use terms
that do not have a local meaning. Numbering might be
one way to do that for some tags but not for others.

Another way to solve this psychological problem is to hide
the recorded data from the user. Something like presets
was suggested. Having different terms being used by the
person who writes the rendering rules and the person
collecting the data might cause other problems.

On Fri, May 9, 2008 at 6:27 PM, elvin ibbotson [EMAIL PROTECTED]
wrote:

 Much debate centres around the way features are tagged and how they
 are rendered (for example recent discussion of golf course tagging,
 the term 'highway', rendering power lines,...) and it seems that much
 of this is inextricably involved with the OSM data itself. I
 wondered if it was time, while OSM is still relatively young and
 before it becomes too ossified and institutionalised, for the
 approach to be reviewed.

 My own thoughts, for what they are worth, are that the data structure
 should be language/locale agnostic. For example, ways could have a
 numeric type field with, hypothetically, 10-19 being used for roads.
 In this scenario 11 might be a UK motorway, an Italian autostrada or
 an American interstate, while 19 might be a rough track (10 being
 reserved for some not-yet-invented super highway, after all some of
 us were here before motorways).

 The editors used to input data (Potlatch, JOSM, whatever) would hide
 this structured data from the user and translate it to/from human
 language. One immediate advantage is that a German user could tag an
 autobahn rather than a motorway and global users would not have to
 use language clearly derived from the British motorway/trunk road/A/B
 (and little-known C) road classification system. Instead, local
 nomenclature would be mapped (no pun intended) to the underlying data
 structure by the local edition of the editor. Highways are an obvious
 example we are all familiar with, but the principle would apply to
 all feature types. Places of worship could be mapped as cathedrals,
 churches, chapels, etc in Britain or as mosques, temples, shrines,
 whatever in the east.

 Rendering of the data is I think less tied up with the data itself,
 but again could be implemented differently by different map viewers.
 My paper road map of Ireland shows primary roads red in Ulster and
 green in Eire. Autbahns are green on my map of the Alps while
 autopistas are patriotically red and yellow on my Spanish map. Local
 or customisable viewers are possible with the current OSM but not, as
 far as I know, implemented yet, but the principle of separating the
 core data from the way it is described and depicted is, I believe,
 important.

 Another aspect of the base data structure is that of level-of-detail
 (LoD) filtering. This is obviously done at present (villages and
 footpaths disappear as you zoom out) but is dictated by the people
 who code the viewers and is not, as far as I know, very well
 addressed in the API, so LoD filtering has to be done after data has
 been acquired, when it should be possible to specify LoD when
 requesting data. If LoD were considered in structuring the database
 it would be easy to filter data (eg. road types 10-13 only or for
 major ways of all types *0-*3). This is simpler for programming than
 clumsily using named tags (highway=motorway|trunk|primary) and would
 be invisible to users who might see autopista, autovia or carretera
 general.

 elvin ibbotson

 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk




-- 
http://bowlad.com
___
talk mailing list
talk@openstreetmap.org

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread Dave Stubbs 

 I can see the attraction to the use of numbers for the values of the
 highway tag. Having a new system that does not use terms that
 have other meanings can force people to think about the OSM
 definitions of the values. The UK centric terms have this effect
 for me. I have to think about what motorway means for the US
 or Korea in terms of the OSM definition because I have no competing
 definition of the term motorway in my mind. For me motorway
 only has an OSM definition.

 People in countries with roads called motorways have a conflict
 in their minds. If a section of a UK motorway is a single lane
 dirt track then someone in the UK may be tempted to label
 it as a motorway because it has a motorway sign. (That's just
 a hyperbole to make a point. Let's keep discussions of the
 highway tag itself on a separate thread.)

 One solution to this psychology problem is to use terms
 that do not have a local meaning. Numbering might be
 one way to do that for some tags but not for others.

 Another way to solve this psychological problem is to hide
 the recorded data from the user. Something like presets
 was suggested. Having different terms being used by the
 person who writes the rendering rules and the person
 collecting the data might cause other problems.



There are some genuine problems that need solving -- tag translation,
tagging hierarchies, tag documentation and guides, and some bad tags
in common use to name but a few.

Unfortunately people seem most interested in solving these problems
via the magic bullet approach. This basically involves turning
everything on it's head, adding a level of indirection or two, putting
in some extra technical elements, and finally hoping that someone will
take the opportunity of the wholesale change to actually fix the
problem.

The highway tag has well known problems; mostly that it's a highly
subjective short cut for lots of tags and widely differing concepts,
of which nobody is entirely sure which takes precedence. This doesn't
get fixed by making everyone use numbers. Numbers are not an
intrinsicly better model of road types, nor do they make it easier to
create such a model.

Tags can be translated from English just as easily as they can be
translated from numbers. Presets can be created using english tags as
well as they can for numeric tags.

Numbers do not possess a natural hierarchy of feature types, nor do
they make such hierarchies easier to create.

Numbers are an abstraction, that's all they are. The present tag
names/values are also generally abstractions... just human readable
ones.

Dave

PS. This isn't aimed at anyone in particular, just a general observation.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread Jeffrey Martin 
Maybe what we need are some guidelines for making tags.

You can make any tag you want, but here are some general
principals about what makes a good key and what makes
good values for those keys.

At the very least we would have a framework for discussion.

Someone type something up on the wiki.

On Sat, May 10, 2008 at 12:48 AM, Dave Stubbs [EMAIL PROTECTED]
wrote:

 
  I can see the attraction to the use of numbers for the values of the
  highway tag. Having a new system that does not use terms that
  have other meanings can force people to think about the OSM
  definitions of the values. The UK centric terms have this effect
  for me. I have to think about what motorway means for the US
  or Korea in terms of the OSM definition because I have no competing
  definition of the term motorway in my mind. For me motorway
  only has an OSM definition.
 
  People in countries with roads called motorways have a conflict
  in their minds. If a section of a UK motorway is a single lane
  dirt track then someone in the UK may be tempted to label
  it as a motorway because it has a motorway sign. (That's just
  a hyperbole to make a point. Let's keep discussions of the
  highway tag itself on a separate thread.)
 
  One solution to this psychology problem is to use terms
  that do not have a local meaning. Numbering might be
  one way to do that for some tags but not for others.
 
  Another way to solve this psychological problem is to hide
  the recorded data from the user. Something like presets
  was suggested. Having different terms being used by the
  person who writes the rendering rules and the person
  collecting the data might cause other problems.
 


 There are some genuine problems that need solving -- tag translation,
 tagging hierarchies, tag documentation and guides, and some bad tags
 in common use to name but a few.

 Unfortunately people seem most interested in solving these problems
 via the magic bullet approach. This basically involves turning
 everything on it's head, adding a level of indirection or two, putting
 in some extra technical elements, and finally hoping that someone will
 take the opportunity of the wholesale change to actually fix the
 problem.

 The highway tag has well known problems; mostly that it's a highly
 subjective short cut for lots of tags and widely differing concepts,
 of which nobody is entirely sure which takes precedence. This doesn't
 get fixed by making everyone use numbers. Numbers are not an
 intrinsicly better model of road types, nor do they make it easier to
 create such a model.

 Tags can be translated from English just as easily as they can be
 translated from numbers. Presets can be created using english tags as
 well as they can for numeric tags.

 Numbers do not possess a natural hierarchy of feature types, nor do
 they make such hierarchies easier to create.

 Numbers are an abstraction, that's all they are. The present tag
 names/values are also generally abstractions... just human readable
 ones.

 Dave

 PS. This isn't aimed at anyone in particular, just a general observation.




-- 
http://bowlad.com
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread elvin ibbotson 

On 9 May 2008, at 12:21, Dave Stubbs wrote:



The mapping to numbers doesn't gain us anything. It doesn't let us do
anything we can't already do, or make it any easier as far as I can
see.


If the database, which is accessed by programmers, was numerically  
based, it would be be more amenable to algorithmic logic. At the  
simplest level, selecting elements with values above/below certain  
levels. The numbers would of course have to follow some logical  
pattern. Similar procedures using the current tags involve clumsier  
code like 'motorway OR trunk OR primary' and, if users are actually  
typing these words in (rather than selecting from human-friendly  
menus presented by the editor) a typo such as 'secodnary' cold  
corrupt the database and prevent the feature being seen by map  
viewers or routing engines for example.




I think you were actually suggesting something like type=11 -- where
10-20 means roads, 30-40 could mean railways etc. But as far as this
argument goes it doesn't really make much difference, other than
leaving us with a massive allocation problem which has been neatly
sidestepped by using free-form tagging.


Yes free-form tagging avoids having to decide on a pattern and allows  
for open-ended evolution, but it doesn't work if it's completely free- 
form. I could describe many roads around here as 'highway=country  
lane but would they get rendered? The fact that there are tagging  
recommendations acknowledges that anarchy would not work. But a data  
structure would have to allow change and evolution (at the simplest  
level, leaving spare numbers for future use) and this is a challenge.




Indeed point missed again.
We DON'T DO (sorry Richard) highway=red. We do highway=primary and you
can make that any colour you like... same as you can do with
highway=13/type=13 -- it makes no difference is my point. Numbering
the highways won't help.



Now I'm confused. I'm not suggesting numbers to avoid red highways  
for goodness' sake!





It could yes. There are a couple of issues with this mostly to do with
actually maintaining the style sheets and providing the processing
power/disk space.



Moore's Law should take care of those :-)




No problemo! Special viewers like the cycle map would simply apply  
their own
filters. And with well-structured data a map viewer could even  
have settings
(eg. cycle routes on/off) allowing it to be customised by the  
user, making a

proliferation of specialist viewers unnecessary.



Hmm.. yes, maybe. But the point of your e-mail was essentially
numbering everything, and that really doesn't help us with this goal.



It's just that numbers are easier for programmers (see above). Users  
would never see them. They would see words in their own language and  
the viewer/editor would map words to numbers.


elvin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread elvin ibbotson 

On 9 May 2008, at 14:56, Juan Lucas Dominguez Rubio wrote:


Hi,
the last line of your messge looks like a triple parallelism. Just  
to be precise: we are tagging 'autopistas' and 'autovias' as  
motorways, 'carreteras nacionales' as trunks and main regional  
roads as primary (for example, the roads linking Catalan cities to  
the Pyrenees)... just in case you are mapping something in Spain :-P


It's funny to see you say 'carretera general', that's old-fashion  
language, often heard in the rural Spain.




Wow, who'd have thought Open Street Map would improve my Spanish? I  
stand corrected. I just took the old-fashioned language from a road  
map I bought on holiday about 10 years ago to illustrate a point.  
Sadly, my Spanish does not extend much beyond ordering two beers or  
telling the waiter 'La mesa no es limpa' (if I remember the holiday  
Spanish phrase book correctly). I never encountered a dirty table in  
Spain, so never had chance to try this one :-(___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread elvin ibbotson 

On 9 May 2008, at 16:48, Dave Stubbs wrote:


 There are some genuine problems that need solving -- tag translation,
 tagging hierarchies, tag documentation and guides, and some bad tags
 in common use to name but a few.

Here we agree.


 Unfortunately people seem most interested in solving these problems
 via the magic bullet approach. This basically involves turning
 everything on it's head, adding a level of indirection or two, putting
 in some extra technical elements, and finally hoping that someone will
 take the opportunity of the wholesale change to actually fix the
 problem.

I don't think we should be afraid of radical change if it is needed.  
OSM has many years and many more terabytes to look forward to and if  
it needs change it would be better sooner rather than later.


 The highway tag has well known problems; mostly that it's a highly
 subjective short cut for lots of tags and widely differing concepts,
 of which nobody is entirely sure which takes precedence. This doesn't
 get fixed by making everyone use numbers.

I just took highways as a simple example everyone is familiar with. I  
don't want to make everyone use numbers. I don't want users ever to  
see the numbers. But users should never actually see the database. My  
whole point is separation of data from the viewing/editing interfaces.


 Numbers are an abstraction, that's all they are. The present tag
 names/values are also generally abstractions... just human readable
 ones.

Things humans read need to be human readable. The database should be  
read by software and if it can be faster and more efficient using  
numbers, numbers are what should be used.

elvin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread elvin ibbotson 

On 9 May 2008, at 14:51, Vincent MEURISSE wrote:


 You can look at merkaartor. It implement something like that. When you
 draw a road, it show up a translated list for the tags. I thing that
 an editor must hide tags for most usages to avoid tagging errors and
 allows power users to change row tags.

agreed


 For example, ways could have a
 numeric type field with, hypothetically, 10-19 being used for roads.
 In this scenario 11 might be a UK motorway, an Italian autostrada or
 an American interstate, while 19 might be a rough track

 And why use tags at all. We can use highway=1 railway=2 amenity=3
 name=4. Then we will renouce to xml format and use a binary one and
 then close the source of osm software.
 Seriously we use xml. The principle of xml is to be human readable and
 use text attribute. If there is any tagging facility and tags
 translation, it's the job of the editor.


I'm sure you must know of the binary data proposal. I have developed  
a mobile OSM viewer which uses the bitmap tiles - slow and big for  
mobile devices. But XML data is way bigger! There is a great deal to  
be said for a binary format. But the future is probably XML. I have  
no objection to tags with words (they are inevitable anyway for such  
things a names) provided they chosen to allow things like level-of- 
detail filtering and future growth, and are (as you say) separated  
from the user by the editor.

elvin


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread Jeffrey Martin 
Typos in real words are easier to detect than a mistake in entering a
number.

On Sat, May 10, 2008 at 2:45 AM, elvin ibbotson [EMAIL PROTECTED]
wrote:

 On 9 May 2008, at 12:21, Dave Stubbs wrote:


 The mapping to numbers doesn't gain us anything. It doesn't let us do
 anything we can't already do, or make it any easier as far as I can
 see.


 If the database, which is accessed by programmers, was numerically based,
 it would be be more amenable to algorithmic logic. At the simplest level,
 selecting elements with values above/below certain levels. The numbers would
 of course have to follow some logical pattern. Similar procedures using the
 current tags involve clumsier code like 'motorway OR trunk OR primary' and,
 if users are actually typing these words in (rather than selecting from
 human-friendly menus presented by the editor) a typo such as 'secodnary'
 cold corrupt the database and prevent the feature being seen by map viewers
 or routing engines for example.


 I think you were actually suggesting something like type=11 -- where
 10-20 means roads, 30-40 could mean railways etc. But as far as this
 argument goes it doesn't really make much difference, other than
 leaving us with a massive allocation problem which has been neatly
 sidestepped by using free-form tagging.


 Yes free-form tagging avoids having to decide on a pattern and allows for
 open-ended evolution, but it doesn't work if it's completely free-form. I
 could describe many roads around here as 'highway=country lane but would
 they get rendered? The fact that there are tagging recommendations
 acknowledges that anarchy would not work. But a data structure would have to
 allow change and evolution (at the simplest level, leaving spare numbers for
 future use) and this is a challenge.


 Indeed point missed again.
 We DON'T DO (sorry Richard) highway=red. We do highway=primary and you
 can make that any colour you like... same as you can do with
 highway=13/type=13 -- it makes no difference is my point. Numbering
 the highways won't help.


 Now I'm confused. I'm not suggesting numbers to avoid red highways for
 goodness' sake!


 It could yes. There are a couple of issues with this mostly to do with
 actually maintaining the style sheets and providing the processing
 power/disk space.


 Moore's Law should take care of those :-)



 No problemo! Special viewers like the cycle map would simply apply their
 own
 filters. And with well-structured data a map viewer could even have
 settings
 (eg. cycle routes on/off) allowing it to be customised by the user, making
 a
 proliferation of specialist viewers unnecessary.


 Hmm.. yes, maybe. But the point of your e-mail was essentially
 numbering everything, and that really doesn't help us with this goal.


 It's just that numbers are easier for programmers (see above). Users would
 never see them. They would see words in their own language and the
 viewer/editor would map words to numbers.

 elvin


 ___
 talk mailing list
 talk@openstreetmap.org
 http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk




-- 
http://bowlad.com
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering

2008-05-09 Thread Jonathan Bennett 
elvin ibbotson wrote:
 Things humans read need to be human readable. The database should be  
 read by software and if it can be faster and more efficient using  
 numbers, numbers are what should be used.


The best way of proving this would be to come up with your own version 
of the OSM server stack that used ID numbers internally, while still 
outputting human-readable tag names. How long do you think it would take 
you?


-- 
Jonathan

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-20 Thread Jeffrey Martin 
On Sat, Apr 19, 2008 at 1:15 AM, Peter Miller [EMAIL PROTECTED]
wrote:


 Major non-interstate highways that have traffic light free multi-level
 junctions etc should be tagged as 'trunk' and possibly also be rendered
 orange but with less grand route numbers to differentiate them from
 interstate routes.

This statement really bothers me. First, we must make every effort to keep
the data separate
from the rendering.

Consider a section of Interstate Highway that structurally resembles a UK
motorway. This section of road may also be part of a state highway. It's not
uncommon for a section of
road to have both a state highway sign and an Interstate sign. In some very
barren
areas an Interstate may have standard intersections without ramps. As in
your example above a road that is not an Interstate may have multiple levels
and ramps.

Whatever scheme we agree on must keep the road's structure separate from
legal classifications. I checked and the wiki still says that the highway
tag should be
used to indicate what the road looks like. My reasoning can be found on the
talk page.

Whether a road is an Interstate, state highway, county road, etc. should be
indicated in another data field.

I haven't been following all the conversations lately, but I remember an
Australian
was tagging a gravel road as a motorway because it was the main road between
two rural cities and he wanted it prominently rendered. Perhaps in this case
some
kind of importance tag should be used.

I think free tagging is great, but we should not allow multiple definitions
for each tag.
A tag should not indicate both it's legal status and it's structure,
although one might
imply the other under certain circumstances.

-- 
http://bowlad.com
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-20 Thread Alex L. Mauer 
Jeffrey Martin wrote:
 I think free tagging is great, but we should not allow multiple
 definitions for each tag.
 A tag should not indicate both it's legal status and it's structure,
 although one might
 imply the other under certain circumstances.

Well, that's an unfortunate fact of the 'highway' tag.  It was written
to indicate both legal status and physical structure.

-Alex Mauer hawke

-- 
Bad - You get pulled over for doing 90 in a school zone and you're drunk
off your ass again at three in the afternoon.
Worse - The cop is drunk too, and he's a mean drunk.
FUCK! - A mean drunk that's actually a swarm of semi-sentient
flesh-eating beetles.
OpenPGP key id: 51192FF2 @ subkeys.pgp.net



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-20 Thread Peter Miller 
Thanks for that Jeffrey. I agree entirely that rendering should follow
tagging and not lead tagging, my main concern at the moment is that UK
rendering (blue for motorway and orange for secondary) is encouraging
inappropriate tagging. I think we agree that one should clarify first how to
tag what is on the ground and then decide on how to render the data. Based
in the UK I am reliant on tiger and aerial photography to inform my choice
of tagging Am I right in thinking that the synthesis of this discussion is
being added to this wiki page?

http://wiki.openstreetmap.org/index.php/Highway_tag_usage

 

Fyi I have been doing a lot of work on the San Francisco bay area (Golden
Gate down to Foster City) over the past week or so and I am having been
working on the road classes tags today, hence my question. I have been:

 

Lifting the road class of roads tagged as secondary but which have flyovers
and divided carriageways etc and making them trunk (but motorway might be
more appropriate)

 

Lifting 'braded roads' with two carriageways in tiger data from residential
to primary.

 

Lifting some other roads from residential to secondary where they are
clearly significant feeder roads for an area.

 

Rationalising link roads to get them to match the class of road they are
feeding (there were lots of motorway_link roads feeding secondary for
example).

 

My first pass looked pretty ugly. I am currently waiting for osmarender to
render my latest adjustment to the primary network in the area and would
then be grateful for feedback as to whether I am on the right lines (but do
wait until tomorrow when the rendering should have finished).

 

I have also being doing a lot of 'de-duplicating' of roads pre/post tiger.
In general I have kept pre-tiger freeways and kept tiger for other roads. I
have also given a pass over most of the freeway network in the bay area in
the past week and have added the second carriageways where required and
cleaned up the geometry and sorted out some of the junctions.

 

 

 

 

Regards,

 

 

 

 

Peter

 

 

 

  _  

From: Jeffrey Martin [mailto:[EMAIL PROTECTED] 
Sent: 20 April 2008 15:42
To: Peter Miller
Cc: Talk Openstreetmap; [EMAIL PROTECTED]
Subject: Re: [OSM-talk] tagging and rendering highways in the USA and
elsewhere

 

 

On Sat, Apr 19, 2008 at 1:15 AM, Peter Miller [EMAIL PROTECTED]
wrote:

 

Major non-interstate highways that have traffic light free multi-level
junctions etc should be tagged as 'trunk' and possibly also be rendered
orange but with less grand route numbers to differentiate them from
interstate routes.

This statement really bothers me. First, we must make every effort to keep
the data separate
from the rendering.

Consider a section of Interstate Highway that structurally resembles a UK
motorway. This section of road may also be part of a state highway. It's not
uncommon for a section of
road to have both a state highway sign and an Interstate sign. In some very
barren
areas an Interstate may have standard intersections without ramps. As in
your example above a road that is not an Interstate may have multiple levels
and ramps.

Whatever scheme we agree on must keep the road's structure separate from
legal classifications. I checked and the wiki still says that the highway
tag should be
used to indicate what the road looks like. My reasoning can be found on the
talk page.

Whether a road is an Interstate, state highway, county road, etc. should be
indicated in another data field.

I haven't been following all the conversations lately, but I remember an
Australian
was tagging a gravel road as a motorway because it was the main road between
two rural cities and he wanted it prominently rendered. Perhaps in this case
some
kind of importance tag should be used.

I think free tagging is great, but we should not allow multiple definitions
for each tag.
A tag should not indicate both it's legal status and it's structure,
although one might
imply the other under certain circumstances.

-- 
http://bowlad.com 

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-19 Thread Robert (Jamie) Munro 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jo wrote:
| Robert (Jamie) Munro schreef:
|
| When I look at the USA, I want interstates to be blue. When an American
| looks at the UK, they want to see motorways to be a colour other than
| blue, because then they will understand instinctively what kind of road
| it is. This should be one of the major benefits of OSM over other maps.
|
| When someone from a USA IP address opens the map, they should see the
| USA style tiles by default, but have the UK tiles on the layer switcher.
|
| That would indeed make a lot of sense. Otherwise you will get odd
| results of roads changing style near the borders. So a separate tile
| server for the US is called for. Probably one for France as well with
| styles that look like Michelin's maps and maybe one for Germany (Are
| Germans used to Kummerley und Frey?)

Hopefully we won't need a separate tileserver for each rendering style -
1 server should be able to render more than one style at a time at
different URLs. I am led to believe that mod_tile cannot currently
render more than one style of tiles on a single apache installation - I
don't know what tilecache is capable of. It would be more efficient to
spread the load across multiple servers by odd/even tile numbers, or
possibly by odd/even zoom levels.

It is likely that a USA tileserver will be busy at different times from
a UK or Japan tile server, and it would be useful if they could share
the rendering loads between each at their own peak times.

Robert (Jamie) Munro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFICejwz+aYVHdncI0RAvVeAKC1NMcAwG4DMJdvqL9LBs6VY73WNQCg5lmp
WdydYFJvvcW6wdCwMUY2+r0=
=NUEB
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-19 Thread Dermot McNally 
On 18/04/2008, Jon Burgess [EMAIL PROTECTED] wrote:

 From a purely functional perspective this approach seems to work. The
  screenshot below shows what happens if you ask for the motorways in
  Ireland to be rendered in purple:

  http://tile.openstreetmap.org/direct/country-mways-example.png

  The motorways in England and Northern Ireland still render in the
  default blue.

So does the most northerly section of the M1 motorway in the Republic
of Ireland, a good 20km away from where that road actually crosses the
border. So while that's a nifty illustration, it shows that the
boundary information will need to get a lot better before we can rely
on it in all cases.

Dermot

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-19 Thread Jon Burgess 

On Sat, 2008-04-19 at 19:57 +0100, Dermot McNally wrote:
 On 18/04/2008, Jon Burgess [EMAIL PROTECTED] wrote:
 
  From a purely functional perspective this approach seems to work. The
   screenshot below shows what happens if you ask for the motorways in
   Ireland to be rendered in purple:
 
   http://tile.openstreetmap.org/direct/country-mways-example.png
 
   The motorways in England and Northern Ireland still render in the
   default blue.
 
 So does the most northerly section of the M1 motorway in the Republic
 of Ireland, a good 20km away from where that road actually crosses the
 border. So while that's a nifty illustration, it shows that the
 boundary information will need to get a lot better before we can rely
 on it in all cases.
 
 Dermot

That could have been due to a couple of things:-
- not using the correct projection on the boundary polygons I imported
- not trying to do anything to account for ways which crossed over a
border. PostGIS can generate clipped geometries while doing the
processing but I did not try this [1].
- or errors in the the boundary (from vmap0).

Thanks for pointing it out anyway.

Jon



[1] http://postgis.refractions.net/docs/ch04.html#id2677901




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-19 Thread Dermot McNally 
On 19/04/2008, Jon Burgess [EMAIL PROTECTED] wrote:

  - not trying to do anything to account for ways which crossed over a
  border. PostGIS can generate clipped geometries while doing the
  processing but I did not try this [1].

That's not the cause anyway - the motorway ends, with a break in ways,
about 10km before the crossing.

  - or errors in the the boundary (from vmap0).

I'd bet good money on this one. I'm still trying to find a good source
for the border data.

Dermot

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Peter Miller 
It would be good to get a resolution of the issue of highway classification
and rendering in the USA.

 

The San Francisco area is getting into a pretty
http://openstreetmap.org/?lat=37.3792lon=-121.9487zoom=12layers=0BFT
good state now, and could act as an 'exemplar' area for the USA should good
tagging practice, however the current highway tagging and rendering is a
mess and also looks wrong on the final map.

 

 I realise a bunch of you are meeting tomorrow in San Francisco for a
mapping party tomorrow so though I would chuck in my thoughts first.

 

 

 

The interstate roads are currently tagged 'motorway' and rendered blue.

 

The state roads are currently tagged on OSM variously with trunk (green)
primary (red) and secondary (orange). Some pretty major roads a tagged with
secondary (actually a very lowly road class in the UK below motorway, trunk
and primary) and I suspect that this is because it renders with the correct
colour. There is no 'secondary_link' tag for exit and entrance ramps because
secondary roads are too minor to have such things so highways rendered as
secondary are using 'secondary' tags for exist and entrance ramps as well.

 

With the current rendering people will be tempted to tag major roads as
'secondary' and get everthing into a bit of mess although others will insist
on using the hierarchy correctly and ignore the non-standard colour of the
resulting map.

 

 

Can I propose the following:

 

Interstate should be tagged 'motorway' and be rendered orange with a rather
grand rendering of the route number as on Google maps and on other US maps.

 

Major non-interstate highways that have traffic light free multi-level
junctions etc should be tagged as 'trunk' and possibly also be rendered
orange but with less grand route numbers to differentiate them from
interstate routes.

 

Major routes with multi lane traffic (2+lanes in each direction) but which
stop for traffic signals and have random side roads coming in frequently are
tagged 'primary' and should appear yellow and be reasonable wide.

 

Secondary and tertiary and then available for lower tiers and should appear
as yellow but be narrower.

 

If we can agree on the rendering rules and get both Mapnik and osmarender
sorted out for the USA then people will be incentivised to tag
appropriately. The moto 'render and they will come' probably applies here as
elsewhere.

 

Can I suggest that you do some block changes to the highways tags over the
weekend to get the tags right and (of course the colours will then be wrong)
ie top roads motorway/motorway_link=blue, next level trunk/trunk_link=green,
next level primary/primary_link=red and finally secondary=orange and
tertiary=yellow and then ensure that the rendering rules get sorted for
osmarender and mapnik .

 

Btw, I am not on the talk-us list. I will look and he USA list on the web
from time to time but so do include me in any relevant responses. I am
copying this to the main list because I suspect the issue also applies to
other countries around the world.

 

 

 

Regards,

 

 

 

Peter Miller

 

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Tom Hughes 
In message [EMAIL PROTECTED]
Peter Miller [EMAIL PROTECTED] wrote:

 The state roads are currently tagged on OSM variously with trunk (green)
 primary (red) and secondary (orange). Some pretty major roads a tagged with
 secondary (actually a very lowly road class in the UK below motorway, trunk
 and primary) and I suspect that this is because it renders with the correct
 colour. There is no 'secondary_link' tag for exit and entrance ramps because
 secondary roads are too minor to have such things so highways rendered as
 secondary are using 'secondary' tags for exist and entrance ramps as well.

There is no such thing as a tag that does not exist in OSM as we have
freeform tagging. In addition to which mapnik at least does render
things marked as secondary_link, so it seems to do a pretty good
impression of something that exists to me.

 If we can agree on the rendering rules and get both Mapnik and osmarender
 sorted out for the USA then people will be incentivised to tag
 appropriately. The moto 'render and they will come' probably applies here as
 elsewhere.

Agreeing on the rules or colour schemes is not the problem.

The problem is that we do not have the technology to render different
countries in different ways. I don't believe we even know of an efficient
way to do it, so we don't even know what the technology would look like
should somebody want to write it.

See the ongoing discussion about the difficulty of the problem of
determining efficiently what country something lies in for what I'm
talking about.

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] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Andy Allan 
 If we can agree on the rendering rules and get both Mapnik and osmarender
 sorted out for the USA

sorted out - they both work fine. Even if we had a production-ready
mechanism for country-specific rendering, it would still be a matter
of opinion, or more accurately, a matter of cartographic style, as to
whether we want to render the freeways in orange. After all, it's just
a map, and conventions are only conventions, not hard and fast rules.

Not saying that we shouldn't, just that your phrasing is quite
aggressive for what is a matter of taste. I wouldn't want someone to
say that my choice of colours for the cycle map contours needs
sorting out (even if that might well be true!).

Cheers,
Andy

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USAandelsewhere

2008-04-18 Thread Dan Putler 
On a ground truth note, it turns out that state highways in
California do range from freeways (CA 85), to major urban surface roads
(CA 82) to narrow two-lane rural roads (CA 130). While lowly, some of
them really are secondary roads.

Dan
 
On Fri, 2008-04-18 at 17:33 +0100, Tom Hughes wrote:
 In message [EMAIL PROTECTED]
 Peter Miller [EMAIL PROTECTED] wrote:
 
  The state roads are currently tagged on OSM variously with trunk (green)
  primary (red) and secondary (orange). Some pretty major roads a tagged with
  secondary (actually a very lowly road class in the UK below motorway, trunk
  and primary) and I suspect that this is because it renders with the correct
  colour. There is no 'secondary_link' tag for exit and entrance ramps because
  secondary roads are too minor to have such things so highways rendered as
  secondary are using 'secondary' tags for exist and entrance ramps as well.
 
 There is no such thing as a tag that does not exist in OSM as we have
 freeform tagging. In addition to which mapnik at least does render
 things marked as secondary_link, so it seems to do a pretty good
 impression of something that exists to me.
 
  If we can agree on the rendering rules and get both Mapnik and osmarender
  sorted out for the USA then people will be incentivised to tag
  appropriately. The moto 'render and they will come' probably applies here as
  elsewhere.
 
 Agreeing on the rules or colour schemes is not the problem.
 
 The problem is that we do not have the technology to render different
 countries in different ways. I don't believe we even know of an efficient
 way to do it, so we don't even know what the technology would look like
 should somebody want to write it.
 
 See the ongoing discussion about the difficulty of the problem of
 determining efficiently what country something lies in for what I'm
 talking about.
 
 Tom
 
-- 
Dan Putler
Sauder School of Business
University of British Columbia


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Ben Laenen 
On Friday 18 April 2008, Tom Hughes wrote:
  If we can agree on the rendering rules and get both Mapnik and
  osmarender sorted out for the USA then people will be incentivised
  to tag appropriately. The moto 'render and they will come' probably
  applies here as elsewhere.

 Agreeing on the rules or colour schemes is not the problem.

Who decides what colours are used on the main maps? I.e. who actually 
decided that motorways should be blue, and trunks should be green, how 
railways are rendered etc.?

Say I'd like to see railways rendered differently in the [EMAIL PROTECTED] 
maps, where 
should I ask? Is there some formal process like for accepting new 
tags where general agreement is formed?

Greetings
Ben

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Adam Schreiber 
On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes [EMAIL PROTECTED] wrote:
  The problem is that we do not have the technology to render different
  countries in different ways. I don't believe we even know of an efficient
  way to do it, so we don't even know what the technology would look like
  should somebody want to write it.

Shouldn't this be as easy as adding a tag indicating country and
altering the stylesheet to say highway=motorway country=us =
color=yellow, highway=motorway country=uk = color=blue?

Cheers,

Adam

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Frederik Ramm 
Hi,

 Shouldn't this be as easy as adding a tag indicating country and
 altering the stylesheet to say highway=motorway country=us =
 color=yellow, highway=motorway country=uk = color=blue?

Complete with the ability to have US motorways in the UK, yay!

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09 E008°23'33


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Frederik Ramm 
Hi,

 Who decides what colours are used on the main maps? I.e. who actually 
 decided that motorways should be blue, and trunks should be green, how 
 railways are rendered etc.?
 
 Say I'd like to see railways rendered differently in the [EMAIL PROTECTED] 
 maps, where 
 should I ask? Is there some formal process like for accepting new 
 tags where general agreement is formed?

The [EMAIL PROTECTED] maps are computed based on stylesheets that are in SVN, so
anybody can change them. It usually takes a while until a change is
visible everywhere because (1) not all tiles are rendered anew after a
style change, and (2) not all renderers update their styles every day.

We don't have a formal process to decide nor are there written rules.
The unwritten rules are probably roughly:

1. Don't break the styles
2. If you add something that affects only a small number of tiles,
   say because you started to tag historic battle sites and want a
   little marker there at the highest zoom level, just do it - if 
   people are unhappy, they can still change it and re-render
3. If you want to change something big, then discuss it on the [EMAIL PROTECTED]
   list. It's no use pushing through a change that would lead to
   half of the renderers simply refusing to update ;-)
4. Big changes like a different colour for highways are a bit 
   difficult since very many tiles have to be rendered, and the map
   will be a patchwork of old and new tiles for quite a while.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00'09 E008°23'33


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Adam Schreiber 
On Fri, Apr 18, 2008 at 2:02 PM, Frederik Ramm [EMAIL PROTECTED] wrote:
 Hi,


   Shouldn't this be as easy as adding a tag indicating country and
   altering the stylesheet to say highway=motorway country=us =
   color=yellow, highway=motorway country=uk = color=blue?

  Complete with the ability to have US motorways in the UK, yay!

Authentication of the data is a different problem than rendering it.

Note that this is different than tagging for a renderer since the data
country=foo is real and not a hint.  It was also just an example, not
necessarily an actual tagging suggestion.  The example was presented
because there was an assertion that it was a technological problem.

Adam

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Tom Hughes 
In message [EMAIL PROTECTED]
  Adam Schreiber [EMAIL PROTECTED] wrote:

 On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes [EMAIL PROTECTED] wrote:
   The problem is that we do not have the technology to render different
   countries in different ways. I don't believe we even know of an efficient
   way to do it, so we don't even know what the technology would look like
   should somebody want to write it.
 
 Shouldn't this be as easy as adding a tag indicating country and
 altering the stylesheet to say highway=motorway country=us =
 color=yellow, highway=motorway country=uk = color=blue?

Yes, obviously we could make everybody go round and tag the umpty
million objects in the database with a country code. That is a pretty
daft solution though when it should be possible to automate it.

Of course as soon as we'd done that people would start asking for
the shield shapes to change by state so we'd have to go round and
add state tags and so on...

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] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Tom Hughes 
In message [EMAIL PROTECTED]
  Ben Laenen [EMAIL PROTECTED] wrote:

 On Friday 18 April 2008, Tom Hughes wrote:
   If we can agree on the rendering rules and get both Mapnik and
   osmarender sorted out for the USA then people will be incentivised
   to tag appropriately. The moto 'render and they will come' probably
   applies here as elsewhere.
 
  Agreeing on the rules or colour schemes is not the problem.
 
 Who decides what colours are used on the main maps? I.e. who actually
 decided that motorways should be blue, and trunks should be green, how
 railways are rendered etc.?

The people who are sufficiently interested to get involved with making
changes to the stylesheets.

 Say I'd like to see railways rendered differently in the [EMAIL PROTECTED] 
 maps, where
 should I ask? Is there some formal process like for accepting new
 tags where general agreement is formed?

The question of what tags are used is orthogonal to how things are
rendered - not every rendering will show every object to start with.

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] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Peter Miller 
I hope I didn't come across as aggressive, but I did want to point out some
really weird inconsistencies that do need to be resolved and wanted to
encourage debate. In the UK a secondary roads is a minor road, in San
Francisco this
http://maps.yahoo.com/#mvt=slat=37.668663lon=-122.485307zoom=18
junction (a multilevel road with multiple flyovers) is classed as secondary
whereas this
http://maps.yahoo.com/#mvt=slat=37.428439lon=-121.909597zoom=19  one
(an urban road with traffic signal controlled junctions) is classed as
primary.

 

I suspect that fact reason that the first is classed as secondary is because
the mapper wanted an orange road and that it should really be a 'trunk'
road.

 

I really don't mind what the rendered colours are, that is for local
discussion and there may even be multiple versions with different styles as
far as I am concernedm, but currently the rendering is uk-centric and that
seems inappropriate for the USA and seems to be causing distortions with
tagging.

 

I do think that the hierarchy of road classes needs to be respected across
OSM (where a trunk road is more important than primary road than secondary
road etc) allowing a routing engine to direct drivers worldwide onto the
main routes (and also possibly keep pedestrians and cyclists off them). I do
think that the '_link' element needs to be used to help sat-nav systems give
meaningful instructions and not give out information about turning onto link
roads when it should say 'turn onto Highway 101'. I do think the description
of the highway road classes in Map Features needs to be internationalised to
allow people in new countries to chose the right mapping to their own
infrastructure and naming and colour conventions.

 

Personally I hope that San Francisco will prove a useful test case where
many of the outstanding internationalisation issues can be bottomed out
before there before large scale tagging across many other parts of the
country.

 

Currently everything except interstate is tagged as 'residential'. If it was
agreed that state highways should be 'trunk' roads then would it be sensible
to design a 'bot' to scan un-touched tiger data for road names including the
word 'state' but not the word 'interstate' and automatically update the tags
from 'highway=residential' to 'highway=trunk' (or whatever is agreed).

 

 

Regards,

 

 

 

 

Peter

 

 -Original Message-

 From: Andy Allan [mailto:[EMAIL PROTECTED]

 Sent: 18 April 2008 17:38

 To: Peter Miller

 Cc: Talk Openstreetmap

 Subject: Re: [OSM-talk] tagging and rendering highways in the USA and

 elsewhere

 

  If we can agree on the rendering rules and get both Mapnik and

 osmarender

  sorted out for the USA

 

 sorted out - they both work fine. Even if we had a production-ready

 mechanism for country-specific rendering, it would still be a matter

 of opinion, or more accurately, a matter of cartographic style, as to

 whether we want to render the freeways in orange. After all, it's just

 a map, and conventions are only conventions, not hard and fast rules.

 

 Not saying that we shouldn't, just that your phrasing is quite

 aggressive for what is a matter of taste. I wouldn't want someone to

 say that my choice of colours for the cycle map contours needs

 sorting out (even if that might well be true!).

 

 Cheers,

 Andy

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Matt Williams 
On Friday 18 April 2008 19:14:22 Tom Hughes wrote:
 In message [EMAIL PROTECTED]

   Adam Schreiber [EMAIL PROTECTED] wrote:
  On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes [EMAIL PROTECTED] wrote:
The problem is that we do not have the technology to render different
countries in different ways. I don't believe we even know of an
   efficient way to do it, so we don't even know what the technology would
   look like should somebody want to write it.
 
  Shouldn't this be as easy as adding a tag indicating country and
  altering the stylesheet to say highway=motorway country=us =
  color=yellow, highway=motorway country=uk = color=blue?

 Yes, obviously we could make everybody go round and tag the umpty
 million objects in the database with a country code. That is a pretty
 daft solution though when it should be possible to automate it.

 Of course as soon as we'd done that people would start asking for
 the shield shapes to change by state so we'd have to go round and
 add state tags and so on...

Well in that case it wouldn't be unfeasible to add is_in=Texas to the highways 
and in fact, is_in= is clearly better than country= anyway. But you're 
right, for country-wide location ionformation, it _should_ be possible to 
automate.

Regards,
Mat Williams


signature.asc
Description: This is a digitally signed message part.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Jon Burgess 

On Fri, 2008-04-18 at 19:14 +0100, Tom Hughes wrote:
 In message [EMAIL PROTECTED]
   Adam Schreiber [EMAIL PROTECTED] wrote:
 
  On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes [EMAIL PROTECTED] wrote:
The problem is that we do not have the technology to render different
countries in different ways. I don't believe we even know of an efficient
way to do it, so we don't even know what the technology would look like
should somebody want to write it.
  
  Shouldn't this be as easy as adding a tag indicating country and
  altering the stylesheet to say highway=motorway country=us =
  color=yellow, highway=motorway country=uk = color=blue?
 
 Yes, obviously we could make everybody go round and tag the umpty
 million objects in the database with a country code. That is a pretty
 daft solution though when it should be possible to automate it.
 
 Of course as soon as we'd done that people would start asking for
 the shield shapes to change by state so we'd have to go round and
 add state tags and so on...
 
 Tom

Provided we have the polygons describing the boundaries of countries,
states etc then we could tag the data during the osm2pgsql processing.
Alternatively it might be possible for Mapnik to query them at run time
(with the right join to a table containing boundary polygons in the data
source SELECT line it might even be possible today).

Generating the appropriate polygons from OSM data would be another
challenge for the reader. Using an external tool like the one used for
coastline shapefile generator is probably the answer.

My main concern would be the maintainability of the osm.xml style file.
It is already nearing 200kB and adding country (or state) specific
rendering would make it even more complex.

Jon




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Matt Williams 
On Friday 18 April 2008 19:25:37 Peter Miller wrote:
 I hope I didn't come across as aggressive, but I did want to point out some
 really weird inconsistencies that do need to be resolved and wanted to
 encourage debate. In the UK a secondary roads is a minor road, in San
 Francisco this
 http://maps.yahoo.com/#mvt=slat=37.668663lon=-122.485307zoom=18
 junction (a multilevel road with multiple flyovers) is classed as secondary
 whereas this
 http://maps.yahoo.com/#mvt=slat=37.428439lon=-121.909597zoom=19  one
 (an urban road with traffic signal controlled junctions) is classed as
 primary.



 I suspect that fact reason that the first is classed as secondary is
 because the mapper wanted an orange road and that it should really be a
 'trunk' road.



 I really don't mind what the rendered colours are, that is for local
 discussion and there may even be multiple versions with different styles as
 far as I am concernedm, but currently the rendering is uk-centric and that
 seems inappropriate for the USA and seems to be causing distortions with
 tagging.

I think most people agree with that, but as said, there's a technological 
barrier to overcome.

 I do think that the hierarchy of road classes needs to be respected across
 OSM (where a trunk road is more important than primary road than secondary
 road etc) allowing a routing engine to direct drivers worldwide onto the
 main routes (and also possibly keep pedestrians and cyclists off them). I
 do think that the '_link' element needs to be used to help sat-nav systems
 give meaningful instructions and not give out information about turning
 onto link roads when it should say 'turn onto Highway 101'. I do think the
 description of the highway road classes in Map Features needs to be
 internationalised to allow people in new countries to chose the right
 mapping to their own infrastructure and naming and colour conventions.

It already is. See 
http://wiki.openstreetmap.org/index.php/Key:highway#International_equivalence 
for the current definitions.

Regards,
Matt Williams

 Personally I hope that San Francisco will prove a useful test case where
 many of the outstanding internationalisation issues can be bottomed out
 before there before large scale tagging across many other parts of the
 country.



 Currently everything except interstate is tagged as 'residential'. If it
 was agreed that state highways should be 'trunk' roads then would it be
 sensible to design a 'bot' to scan un-touched tiger data for road names
 including the word 'state' but not the word 'interstate' and automatically
 update the tags from 'highway=residential' to 'highway=trunk' (or whatever
 is agreed).


signature.asc
Description: This is a digitally signed message part.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Tom Hughes 
In message [EMAIL PROTECTED]
  Jon Burgess [EMAIL PROTECTED] wrote:

 Provided we have the polygons describing the boundaries of countries,
 states etc then we could tag the data during the osm2pgsql processing.
 Alternatively it might be possible for Mapnik to query them at run time
 (with the right join to a table containing boundary polygons in the data
 source SELECT line it might even be possible today).

I was thinking about that while I was walking home earlier. The
main question I guess is how efficient PostGIS is at answering
the question which of these N hundred polygons is this data
in, or how efficiently we can code the equivalent in osm2pgsql.

 My main concern would be the maintainability of the osm.xml style file.
 It is already nearing 200kB and adding country (or state) specific
 rendering would make it even more complex.

Indeed. I was thinking about that too, and I think it needs an
extrat level of indirection, so the existing stylesheet stays
largely as it is but instead of saying that a secondary road
is rendered as #213455 or whatever some sort of code name is
given and then that is mapped to the real colour based on the
country.

Tom

-- 
Tom Hughes ([EMAIL PROTECTED])
http://www.compton.nu/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Peter Miller 
 Date: Fri, 18 Apr 2008 13:44:49 -0400
 From: Adam Schreiber [EMAIL PROTECTED]
 Subject: Re: [OSM-talk] tagging and rendering highways in the USA and
   elsewhere
 To: Tom Hughes [EMAIL PROTECTED]
 Cc: talk@openstreetmap.org
 Message-ID:
   [EMAIL PROTECTED]
 Content-Type: text/plain; charset=UTF-8
 
 On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes [EMAIL PROTECTED] wrote:
   The problem is that we do not have the technology to render different
   countries in different ways. I don't believe we even know of an
 efficient
   way to do it, so we don't even know what the technology would look like
   should somebody want to write it.
 
 Shouldn't this be as easy as adding a tag indicating country and
 altering the stylesheet to say highway=motorway country=us =
 color=yellow, highway=motorway country=uk = color=blue?


I think tagging each way with the country puts huge additional work onto
every mapper. We should have boundaries for countries from somewhere I
believe, and that will provide the national context for default rendering.
Possibly it is not achievable immediately, but I suggest we need to solve it
and ensure the integrity of the tagging in the meantime.

As to the question about 'who decides on the actual rendering' I am not
personally sure and it may require a bit of a benevolent dictator role in
the end, however if the core tagging is clear and consistent across OSM
then anyone is free to do their own rendering.

To answer the question about who chose blue for motorways. That is a
standard across road-maps in the UK that was possibly defined with motorways
were first build in the UK. I have a UK road atlas from 1976 that has the
motorways in blue. I guess that red was used for the most important roads
(being a bright colour) with a tone spreading from yellow through orange to
red before motorways and then when someone invented a new more important one
a new colour was needed. The answer is that OSM's currently colour scheme
seems to be that it is UK imperialism!

For interest, here are some colours using by Google maps around the world
for motorways or their local equitant.

Orange: USA, Canada, Germany, Russia, India, China
Red: Australia, France
Blue: UK


And for Yahoo

Red: USA, France, Russia
Orange: India
Blue: UK

And for Microsoft (local.live)

Green: France
Orange: UK, India, China
Yellow: Russia


So actually it is all a bit fluid and variable, but I still think a table
for colours by county makes sense unless someone wants to get agreement on a
single colour.

I would suggest we have a default of orange for top-level roads everywhere
with a local override which is blue for the UK and other countries can
debate what they want would be idea.

In the mean time please can we strongly encourage consistent tagging of
highways everywhere.

Regards,



Peter
 
 Cheers,
 
 Adam
 
 



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Cartinus 
On Friday 18 April 2008 21:23:47 Peter Miller wrote:
 The answer is that OSM's currently
 colour scheme seems to be that it is UK imperialism!

 For interest, here are some colours using by Google maps around the world
snip
 I would suggest we have a default of orange for top-level roads everywhere
 with a local override which is blue for the UK and other countries can
 debate what they want would be idea.

I would suggest we don't change the colours on the default OSM map at all. And 
especially not to some US / Google imperialist global uniform style.

If I buy a paper map from Michelin, another one from Kümmerly+Frey and a third 
from Falkplan, then I don't expect them to all have the same style. Why would 
all electronic maps need to look the same?

There is a really simple technical solution to have a national render style 
for OSM maps. Setup your own national tile server. Like the Dutch tile server 
and IIRC there is one for Japan too. This has the additional benefit it 
spreads the load over more servers.


-- 
m.v.g.,
Cartinus

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Jon Burgess 

On Fri, 2008-04-18 at 21:57 +0100, Jon Burgess wrote:
 It should then be possible to include fips_cntry as a filter in the
 osm.xml. 

From a purely functional perspective this approach seems to work. The
screenshot below shows what happens if you ask for the motorways in
Ireland to be rendered in purple:

http://tile.openstreetmap.org/direct/country-mways-example.png

The motorways in England and Northern Ireland still render in the
default blue.

Jon



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Robert (Jamie) Munro 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tom Hughes wrote:
| In message [EMAIL PROTECTED]
| Peter Miller [EMAIL PROTECTED] wrote:

| If we can agree on the rendering rules and get both Mapnik and osmarender
| sorted out for the USA then people will be incentivised to tag
| appropriately. The moto 'render and they will come' probably applies
here as
| elsewhere.
|
| Agreeing on the rules or colour schemes is not the problem.
|
| The problem is that we do not have the technology to render different
| countries in different ways. I don't believe we even know of an efficient
| way to do it, so we don't even know what the technology would look like
| should somebody want to write it.

I don't think this is a problem we shuold be trying to solve. We should
be solving the problem of the tile server only producing 1 rendering.

When I look at the USA, I want interstates to be blue. When an American
looks at the UK, they want to see motorways to be a colour other than
blue, because then they will understand instinctively what kind of road
it is. This should be one of the major benefits of OSM over other maps.

When someone from a USA IP address opens the map, they should see the
USA style tiles by default, but have the UK tiles on the layer switcher.

Robert (Jamie) Munro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFICSf/z+aYVHdncI0RAsnVAKDQMXTqQ1140PMQj7tqae25Ua3HywCgh9Hu
vgv5+TiMqgD0aaAGyN5T5rg=
=mERT
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Karl Newman 
On Fri, Apr 18, 2008 at 11:14 AM, Tom Hughes [EMAIL PROTECTED] wrote:

 In message [EMAIL PROTECTED]
   Adam Schreiber [EMAIL PROTECTED] wrote:

  On Fri, Apr 18, 2008 at 12:33 PM, Tom Hughes [EMAIL PROTECTED] wrote:
The problem is that we do not have the technology to render different
countries in different ways. I don't believe we even know of an
 efficient
way to do it, so we don't even know what the technology would look
 like
should somebody want to write it.
 
  Shouldn't this be as easy as adding a tag indicating country and
  altering the stylesheet to say highway=motorway country=us =
  color=yellow, highway=motorway country=uk = color=blue?

 Yes, obviously we could make everybody go round and tag the umpty
 million objects in the database with a country code. That is a pretty
 daft solution though when it should be possible to automate it.

 Of course as soon as we'd done that people would start asking for
 the shield shapes to change by state so we'd have to go round and
 add state tags and so on...

 Tom


Well, the ref tag should already have that information for the US anyway, so
custom shields (and colors) could be done for interstates (I 5), US
highways (US 101), state highways (US:CA 12) but probably not county
highways (CTH 22).

Karl
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] tagging and rendering highways in the USA and elsewhere

2008-04-18 Thread Jo 
Robert (Jamie) Munro schreef:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Tom Hughes wrote:
 | In message [EMAIL PROTECTED]
 | Peter Miller [EMAIL PROTECTED] wrote:

 | If we can agree on the rendering rules and get both Mapnik and osmarender
 | sorted out for the USA then people will be incentivised to tag
 | appropriately. The moto 'render and they will come' probably applies
 here as
 | elsewhere.
 |
 | Agreeing on the rules or colour schemes is not the problem.
 |
 | The problem is that we do not have the technology to render different
 | countries in different ways. I don't believe we even know of an efficient
 | way to do it, so we don't even know what the technology would look like
 | should somebody want to write it.

 I don't think this is a problem we shuold be trying to solve. We should
 be solving the problem of the tile server only producing 1 rendering.

 When I look at the USA, I want interstates to be blue. When an American
 looks at the UK, they want to see motorways to be a colour other than
 blue, because then they will understand instinctively what kind of road
 it is. This should be one of the major benefits of OSM over other maps.

 When someone from a USA IP address opens the map, they should see the
 USA style tiles by default, but have the UK tiles on the layer switcher.
   
That would indeed make a lot of sense. Otherwise you will get odd 
results of roads changing style near the borders. So a separate tile 
server for the US is called for. Probably one for France as well with 
styles that look like Michelin's maps and maybe one for Germany (Are 
Germans used to Kummerley und Frey?)

Polyglot

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk