Re: [Tagging] Named junctions

[Gerd Petermann]

wow, so the problem is much bigger than I expected.

I still think that my suggestion might help to solve the problem.

My understanding so far:

- In Japan (and maybe other countries),

you would prefer to render only those traffic_signals which have a name

- Complex junctions often require several nodes with highway=traffic_signals,

at least for the routing.


My suggestion place=junction  could be used for all junctions,

maybe in combination with traffic_signals=yes/no to help the renderer.

A special Japanese style would simply ignore unnamed traffic_signals.


 Gerd




Von: John Willis 
Gesendet: Donnerstag, 5. November 2015 23:47
An: Tag discussion, strategy and related tools
Betreff: Re: [Tagging] Named junctions





Javbw
On Nov 6, 2015, at 1:09 AM, Eugene Alvin Villar 
mailto:sea...@gmail.com>> wrote:


I'd suggest to use a node tagged

place=junction

with name=* or ref=*

for this. What do you think?

>From what I remember - in Korea they name junctions, and in Japan they 
>actually name the signals themselves.
I know that sounds like the same thing, but people to speak and refer to the 
Signal at the junction, and the name is on the signal, and the iconography used 
is the signal icon. As there are almost no street names in Japan on tertiary 
roads and below, spatial navigation is done through counting *unnamed* signals 
and occasionally using named signals.

The big problem traffic_signals_area
was trying to solve is the over-rendering of signal icons.

Billboards, pamphlets, and now websites use static images of maps with access 
directions and simplified maps that show how many signals you have to drive 
through before turning and reaching a destination from a known landmark 
(highway exit, train station).

Here is the access map for a very large park.

http://hitachikaihin.jp/wp-content/uploads/2012/03/996e3788561dbe76ffe45257c28c7c25.png

Note the line of signals in a row. Those are there to be counted.

Because of Japan's very old and extremely convoluted road network, it is 
usually not obvious where to turn - so people not using GPS directions 
(actually using a *map*) Rely **very heavily** on accurate and consistent 
placement of street light icons. And OSM is totally broken in this regard. 
Every node gets an icon. Depending on the zoom level, there is 0-1-2-3-4 or 
more icons when just **one** should be rendered. The signal icon is more 
important that almost all place names.

This is something all the Japanese paper maps and online maps follow, and 
Apple/Google also had to add all the icons properly to be useful *as a map* in 
Japan.

Google Maps of the signals in a row. Note 1 named signal has a name box that 
doesn't cover the road.

https://goo.gl/maps/E1hEzfi3iYF2

OSM has no rendered icons.
http://www.openstreetmap.org/#map=15/36.3967/140.5927
It has a label for the lights rendered, but no icons.

Next zoom level - label disappears. So no signals, no labels. Ugh.
http://www.openstreetmap.org/#map=16/36.4009/140.5901

Now icons - but two of them, with label.
http://www.openstreetmap.org/#map=17/36.40107/140.58986

Next, 4 icons - no label
http://www.openstreetmap.org/#map=18/36.40160/140.58949

Finally, at z19, I get 4 icons and a label together.

What a horrible job of rendering a single icon with a single label!

This is an unacceptable situation  for the Map in Japan. It 
fundamentally breaks using the map for road navigation for many many map users. 
and since every other map is better at this fundamental necessity of Japanese 
maps, it basically makes OSM an unusable choice in Japan (for spatial map usage 
while driving) and seem unfinished.

Traffic_signals_area was an attempt to solve this, but as this isn't an issue 
in Europe, it was ignored.

Javbw.




Labeling the signal area is just icing on the cake of removing all the unneeded 
icons cluttering the map.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag a fence made with metal bars?

[Martin Koppenhoefer]

sent from a phone

> Am 05.11.2015 um 23:09 schrieb John Willis :
> 
> In Japan, a half-wall half-fence like thing is common.  Cinder block walls 
> are very common for commercial and residential boundary walls, and in many 
> places are normal 1.5m tall walls. These cinder blocks are almost as narrow 
> as bricks - 15cm or so.


+1, good point, I've also encountered many times situations with several fences 
types or wall/fence combinations that are stacked one above the other, also 
retaining walls with a fence on top are not rare. How do we map this? 
Overlapping ways with layer tags? A relation?
Another not uncommon situation consists of hedges with a fence in the middle.


cheers 
Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Named junctions

[Andrew Errington]

We already use junction=yes for named junctions.  Why is another tag needed?

On 06/11/2015, Gerd Petermann  wrote:
> wow, so the problem is much bigger than I expected.
>
> I still think that my suggestion might help to solve the problem.
>
> My understanding so far:
>
> - In Japan (and maybe other countries),
>
> you would prefer to render only those traffic_signals which have a name
>
> - Complex junctions often require several nodes with
> highway=traffic_signals,
>
> at least for the routing.
>
>
> My suggestion place=junction  could be used for all junctions,
>
> maybe in combination with traffic_signals=yes/no to help the renderer.
>
> A special Japanese style would simply ignore unnamed traffic_signals.
>
>
>  Gerd
>
>
>
> 
> Von: John Willis 
> Gesendet: Donnerstag, 5. November 2015 23:47
> An: Tag discussion, strategy and related tools
> Betreff: Re: [Tagging] Named junctions
>
>
>
>
>
> Javbw
> On Nov 6, 2015, at 1:09 AM, Eugene Alvin Villar
> mailto:sea...@gmail.com>> wrote:
>
>
> I'd suggest to use a node tagged
>
> place=junction
>
> with name=* or ref=*
>
> for this. What do you think?
>
> From what I remember - in Korea they name junctions, and in Japan they
> actually name the signals themselves.
> I know that sounds like the same thing, but people to speak and refer to the
> Signal at the junction, and the name is on the signal, and the iconography
> used is the signal icon. As there are almost no street names in Japan on
> tertiary roads and below, spatial navigation is done through counting
> *unnamed* signals and occasionally using named signals.
>
> The big problem traffic_signals_area
> was trying to solve is the over-rendering of signal icons.
>
> Billboards, pamphlets, and now websites use static images of maps with
> access directions and simplified maps that show how many signals you have to
> drive through before turning and reaching a destination from a known
> landmark (highway exit, train station).
>
> Here is the access map for a very large park.
>
> http://hitachikaihin.jp/wp-content/uploads/2012/03/996e3788561dbe76ffe45257c28c7c25.png
>
> Note the line of signals in a row. Those are there to be counted.
>
> Because of Japan's very old and extremely convoluted road network, it is
> usually not obvious where to turn - so people not using GPS directions
> (actually using a *map*) Rely **very heavily** on accurate and consistent
> placement of street light icons. And OSM is totally broken in this regard.
> Every node gets an icon. Depending on the zoom level, there is 0-1-2-3-4 or
> more icons when just **one** should be rendered. The signal icon is more
> important that almost all place names.
>
> This is something all the Japanese paper maps and online maps follow, and
> Apple/Google also had to add all the icons properly to be useful *as a map*
> in Japan.
>
> Google Maps of the signals in a row. Note 1 named signal has a name box that
> doesn't cover the road.
>
> https://goo.gl/maps/E1hEzfi3iYF2
>
> OSM has no rendered icons.
> http://www.openstreetmap.org/#map=15/36.3967/140.5927
> It has a label for the lights rendered, but no icons.
>
> Next zoom level - label disappears. So no signals, no labels. Ugh.
> http://www.openstreetmap.org/#map=16/36.4009/140.5901
>
> Now icons - but two of them, with label.
> http://www.openstreetmap.org/#map=17/36.40107/140.58986
>
> Next, 4 icons - no label
> http://www.openstreetmap.org/#map=18/36.40160/140.58949
>
> Finally, at z19, I get 4 icons and a label together.
>
> What a horrible job of rendering a single icon with a single label!
>
> This is an unacceptable situation  for the Map in Japan. It
> fundamentally breaks using the map for road navigation for many many map
> users. and since every other map is better at this fundamental necessity of
> Japanese maps, it basically makes OSM an unusable choice in Japan (for
> spatial map usage while driving) and seem unfinished.
>
> Traffic_signals_area was an attempt to solve this, but as this isn't an
> issue in Europe, it was ignored.
>
> Javbw.
>
>
>
>
> Labeling the signal area is just icing on the cake of removing all the
> unneeded icons cluttering the map.
>

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

Re: [Tagging] How to tag a fence made with metal bars?

[Gerd Petermann]

Hmm, in my eyes many fences / barriers are also some kind of 
art, esp. old ones made of metal are often hand crafted (at
least in Germany). They are similar to the main entrances
of buildings, they try to express somehow how the owner
welcomes you (in case of the entrance) or tries to keep you 
away (in case of the fence).
I fear you will never find simple tags to describe these details
in a way that allows data consumers to use the information.

 Gerd



Von: Martin Koppenhoefer 
Gesendet: Freitag, 6. November 2015 09:30
An: Tag discussion, strategy and related tools
Betreff: Re: [Tagging] How to tag a fence made with metal bars?

sent from a phone

> Am 05.11.2015 um 23:09 schrieb John Willis :
>
> In Japan, a half-wall half-fence like thing is common.  Cinder block walls 
> are very common for commercial and residential boundary walls, and in many 
> places are normal 1.5m tall walls. These cinder blocks are almost as narrow 
> as bricks - 15cm or so.


+1, good point, I've also encountered many times situations with several fences 
types or wall/fence combinations that are stacked one above the other, also 
retaining walls with a fence on top are not rare. How do we map this? 
Overlapping ways with layer tags? A relation?
Another not uncommon situation consists of hedges with a fence in the middle.


cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Named junctions

[Gerd Petermann]

Oh, sorry, I did not yet notice this one :-( 

So forget my suggestion.

Gerd


Von: Andrew Errington 
Gesendet: Freitag, 6. November 2015 09:35
An: Tag discussion, strategy and related tools
Betreff: Re: [Tagging] Named junctions

We already use junction=yes for named junctions.  Why is another tag needed?

On 06/11/2015, Gerd Petermann  wrote:
> wow, so the problem is much bigger than I expected.
>
> I still think that my suggestion might help to solve the problem.
>
> My understanding so far:
>
> - In Japan (and maybe other countries),
>
> you would prefer to render only those traffic_signals which have a name
>
> - Complex junctions often require several nodes with
> highway=traffic_signals,
>
> at least for the routing.
>
>
> My suggestion place=junction  could be used for all junctions,
>
> maybe in combination with traffic_signals=yes/no to help the renderer.
>
> A special Japanese style would simply ignore unnamed traffic_signals.
>
>
>  Gerd
>
>
>
> 
> Von: John Willis 
> Gesendet: Donnerstag, 5. November 2015 23:47
> An: Tag discussion, strategy and related tools
> Betreff: Re: [Tagging] Named junctions
>
>
>
>
>
> Javbw
> On Nov 6, 2015, at 1:09 AM, Eugene Alvin Villar
> mailto:sea...@gmail.com>> wrote:
>
>
> I'd suggest to use a node tagged
>
> place=junction
>
> with name=* or ref=*
>
> for this. What do you think?
>
> From what I remember - in Korea they name junctions, and in Japan they
> actually name the signals themselves.
> I know that sounds like the same thing, but people to speak and refer to the
> Signal at the junction, and the name is on the signal, and the iconography
> used is the signal icon. As there are almost no street names in Japan on
> tertiary roads and below, spatial navigation is done through counting
> *unnamed* signals and occasionally using named signals.
>
> The big problem traffic_signals_area
> was trying to solve is the over-rendering of signal icons.
>
> Billboards, pamphlets, and now websites use static images of maps with
> access directions and simplified maps that show how many signals you have to
> drive through before turning and reaching a destination from a known
> landmark (highway exit, train station).
>
> Here is the access map for a very large park.
>
> http://hitachikaihin.jp/wp-content/uploads/2012/03/996e3788561dbe76ffe45257c28c7c25.png
>
> Note the line of signals in a row. Those are there to be counted.
>
> Because of Japan's very old and extremely convoluted road network, it is
> usually not obvious where to turn - so people not using GPS directions
> (actually using a *map*) Rely **very heavily** on accurate and consistent
> placement of street light icons. And OSM is totally broken in this regard.
> Every node gets an icon. Depending on the zoom level, there is 0-1-2-3-4 or
> more icons when just **one** should be rendered. The signal icon is more
> important that almost all place names.
>
> This is something all the Japanese paper maps and online maps follow, and
> Apple/Google also had to add all the icons properly to be useful *as a map*
> in Japan.
>
> Google Maps of the signals in a row. Note 1 named signal has a name box that
> doesn't cover the road.
>
> https://goo.gl/maps/E1hEzfi3iYF2
>
> OSM has no rendered icons.
> http://www.openstreetmap.org/#map=15/36.3967/140.5927
> It has a label for the lights rendered, but no icons.
>
> Next zoom level - label disappears. So no signals, no labels. Ugh.
> http://www.openstreetmap.org/#map=16/36.4009/140.5901
>
> Now icons - but two of them, with label.
> http://www.openstreetmap.org/#map=17/36.40107/140.58986
>
> Next, 4 icons - no label
> http://www.openstreetmap.org/#map=18/36.40160/140.58949
>
> Finally, at z19, I get 4 icons and a label together.
>
> What a horrible job of rendering a single icon with a single label!
>
> This is an unacceptable situation  for the Map in Japan. It
> fundamentally breaks using the map for road navigation for many many map
> users. and since every other map is better at this fundamental necessity of
> Japanese maps, it basically makes OSM an unusable choice in Japan (for
> spatial map usage while driving) and seem unfinished.
>
> Traffic_signals_area was an attempt to solve this, but as this isn't an
> issue in Europe, it was ignored.
>
> Javbw.
>
>
>
>
> Labeling the signal area is just icing on the cake of removing all the
> unneeded icons cluttering the map.
>

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

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

[Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Paul Johnson]

ref=* on ways has become an unmitigated hot mess for maintainability, and
now that relations have been around for a considerable amount of time.
Let's kill this dinosaur like Linux killed ext filesystem support already.
It's so long in the tooth it's starting to go from egregious to just sad.

*Background*: Prior to 2007 and the 0.5 API, OpenStreetMap had no
"relation" data type, just nodes and ways.  A stopgap measure to deal with
routes was to tag them on ways.  However, this quickly developed into a
major issue as routes with their own refs for different modes and
memberships cropped up as OSM developed past being merely a traditional
street map.  Relations were introduced, and quickly adopted as the standard
tagging for routes of all kinds, with tags for most networks moving off the
member ways to the relations.  Presets for creating road routes with
relations exist in (at least) JOSM and have for years now (I'd consider it
a glaring, almost egregious, omission for any general purpose or
highway-oriented editor at this point).

*The problem:* It's now been 8 years since the introduction of relations,
and only route=road seems to be the sticking point for consistent route
tagging, with qualities that should be part of the relation are instead
still getting legacy-tagged on ways.  This ends up being a major
maintainability nightmare in places where multiple routes share the same
way, especially whenever a new route is introduced or an old route is later
deleted, and only gets worse the more routes share the same way (Illinois
being an extreme example with some highways carrying as many as 9 signed
routes), or the more road networks in play (Texas being an extreme example
with 7 state level networks).

There's also the situation where ways themselves have their own refs often
disconnected from the route (Oregon for sure for any highway with no route,
all highways prior to 1928 and most highways 1928-2007, which is to say all
but ~20-30 highways statewide) and possibly Pennsylvania (with the
four-digit state highways) has this situation, but PA's case might just be
a borderline case of routes with unsigned-ref).

Even in European cases, thanks to "E" routes in the EU, this is decidedly
not a strictly North American situation.

In any case, adding or removing members and checking the relation's
consistency is far easier, and easier to validate, than juggling multiple
ref values in any sort of coherent fashion.  And this is before even
getting into issues of *which order* the refs go in...

*The fix: * I propose a goal of December 31, 2016 to eliminate ref=* as a
method to describe an overlying route; this should be more than ample time
for existing data consumers to catch up on doing a move and ensure data
consistency for routes.  Kill the dinosaur:

   - Deprecate ref=* on ways from having anything to do with the routes
   they run over, use relations instead and phase out the use of
   route-describing refs on ways (be it removal of the tag or replacement of
   the key's value with a ref that actually applies to the way instead of the
   route).
   - Stop rendering this key and instead render the relations in opencarto
   and other featured layers.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Martin Koppenhoefer]

2015-11-06 11:24 GMT+01:00 Paul Johnson :

> Even in European cases, thanks to "E" routes in the EU, this is decidedly
> not a strictly North American situation.




I agree with your analysis and the proposed fix (maybe we can be faster
than the deadline you suggest). FWIW, even without E-routes there are
overlapping routes in Europe (e.g. in Germany), but admittedly compared to
the US it is a rare phenomenon.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Decorative flower fields? (not as a crop?)

[johnw]

Thanks for this information - I live about 1 hour away from Oze but I have not 
visited it yet. And most of the fields in Oze are certainly wetlands of some 
kind. 

I will eventually visit both of the places you mentioned, as everyone likes 
pictures of pretty flowers in the forest. 

Links in Japanese are always fine, as I can always learn something from a link. 

Javbw

> On Nov 4, 2015, at 10:47 PM, tomoya muramoto  wrote:
> 
> For Mizubasho, most famous field is Oze swamp(but sorry I have never been 
> there) due to a famous japanese fork song, you know.
> I remember natural Katakuri flower field at the top of Mt. Tsukuba. They say 
> there are 30 thousand Katakuri flowers in 20,000 m2 area 
> (http://www.ttca.jp/?p=1552 ), they are on the 
> forest floor as you said.
> Actually I don't know they are *natural*, but they say so.
> 
> Maybe you can check a list of Natural monuments designated by Japanese 
> government.
> https://ja.wikipedia.org/wiki/%E6%A4%8D%E7%89%A9%E5%A4%A9%E7%84%B6%E8%A8%98%E5%BF%B5%E7%89%A9%E4%B8%80%E8%A6%A7#.E8.A2.AB.E5.AD.90.E6.A4.8D.E7.89.A9.E3.83.BB.E5.8D.98.E5.AD.90.E8.91.89.E9.A1.9E
>  
> 
>  (sorry it is written in Japanese)

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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Christoph Hormann]

On Friday 06 November 2015, Paul Johnson wrote:
> Stop rendering this key and instead render the relations 

Is there *any* map style that does this at the moment?

AFAIK osm2pgsql does not support including relation membership info in 
the rendering database.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Andy Townsend]

On 06/11/2015 10:24, Paul Johnson wrote:


Even in European cases, thanks to "E" routes in the EU, this is 
decidedly not a strictly North American situation.




Not really, or at least not across the board.  In some European 
countries "E" roads are paper routes only - they're made up by non-local 
beaurocrats, are unsigned, and irrelevant for all route planning purposes.


Obviously in places where a road can have multiple equivalent references 
(such as the US) route relations perfect sense (as does figuring out 
which routes are actually signed on which bits of road) but in places 
where there's only one real ref per piece of tarmac (such as the UK) 
there's no need to force mappers to start maintaining relations as well 
as just recording the reference.


Routers ought to already know what country they're in when routing 
(though the recent US maxweight discussion worries me that they may not 
all do this) so it really shouldn't be an overhead for them.


Cheers,

Andy (SomeoneElse)

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

Re: [Tagging] Decorative flower fields? (not as a crop?)

[johnw]

> On Nov 4, 2015, at 8:51 PM, Martin Koppenhoefer  
> wrote:
> 
> I think it's not that different to a cutline for instance, which is one of 
> the most used values in man_made

You are right, since it is a place where the land is cleared, a cutline is a 
clearing in the woods. Similar to clearcut too. but both of those are based 
removal of existing natural items - the absence of the original - not the 
growth/presence of new plants.

Many of the “growth of new plants” tags are inside Landuse (forest, meadow, 
farmland, orchard - which are all the more similar to a flowerbed) 

I was thinking natural=flowers because so many of the values are heavily 
altered/managed by man (rivers, streams, scrub, etc), but are still considered 
natural. 

Perhaps landuse=flowerbed or landcover=flowers is the best solution. 

Thoughts?


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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Dave Swarthout]

On Fri, Nov 6, 2015 at 8:02 PM, Andy Townsend  wrote:

> Obviously in places where a road can have multiple equivalent references
> (such as the US) route relations perfect sense (as does figuring out which
> routes are actually signed on which bits of road) but in places where
> there's only one real ref per piece of tarmac (such as the UK) there's no
> need to force mappers to start maintaining relations as well as just
> recording the reference.


I'm glad someone else said it first. I don't want to be forced to create a
relation where one is not needed. Relations are tricky, the tools for
handling and editing them are IMO not that good, and it will invite many
mistakes by less experienced mappers. I was looking at a what I surmise to
be a ferry route earlier today and it had a tag of route=fairway. Did the
mapper not realize what he was doing or are the diagnostic tools for
determining errors in relations not that robust? Hell, when I'm adding
inners within a large multipolygon I don't even think there is a way to
determine exactly which relations surround my area. In addition, editing a
relation which shares nodes/ways with another relation is a pure nightmare.

No thanks. Before you go ahead with something like this, please make sure
the tools and the Wiki are up to the job.

Dave
-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Mike N]

On 11/6/2015 8:00 AM, Christoph Hormann wrote:

Stop rendering this key and instead render the relations

Is there*any*  map style that does this at the moment?

AFAIK osm2pgsql does not support including relation membership info in
the rendering database.


The US developmental version at 
http://tile.openstreetmap.us/osmus_shields/preview.html#14/39.9272/-86.1812 
gets its information from relations - the only way to properly show such 
roads carrying multiplexed routes.


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

Re: [Tagging] [OSM-talk] Proposal: Sunset ref=* on ways in favor of relations

[Paul Johnson]

On Fri, Nov 6, 2015 at 7:00 AM, Christoph Hormann 
wrote:

> On Friday 06 November 2015, Paul Johnson wrote:
> > Stop rendering this key and instead render the relations
>
> Is there *any* map style that does this at the moment?
>

I believe Toby had a working mapnik-based renderer doing this on osm.us at
one point, though i'm not sure what became of this.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Paul Johnson]

On Fri, Nov 6, 2015 at 7:02 AM, Andy Townsend  wrote:
>
> Obviously in places where a road can have multiple equivalent references
> (such as the US) route relations perfect sense (as does figuring out which
> routes are actually signed on which bits of road) but in places where
> there's only one real ref per piece of tarmac (such as the UK) there's no
> need to force mappers to start maintaining relations as well as just
> recording the reference.
>

Well, I believe impetus for route relations was Sustrans networks.  These
tags went from the ways to relations years ago already, so call me
skeptical that there's no multiplexes in the UK (especially since without
any real effort inside 30 seconds, just randomly scrolling by hand to the
UK, I see that the A24 and RCN CS7 are multiplexed).  I honestly don't see
why we should be treating tags related to route=road any different than
we're already treating route=bicycle.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Colin Smale]

 

On 2015-11-06 14:26, Dave Swarthout wrote: 

> I was looking at a what I surmise to be a ferry route earlier today and it 
> had a tag of route=fairway. Did the mapper not realize what he was doing or 
> are the diagnostic tools for determining errors in relations not that robust?

Are you sure that route=fairway is wrong? It can have a nautical
meaning: 

https://en.wiktionary.org/wiki/fairway 

//colin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Andy Townsend]

On 06/11/2015 13:44, Paul Johnson wrote:
On Fri, Nov 6, 2015 at 7:02 AM, Andy Townsend > wrote:


Obviously in places where a road can have multiple equivalent
references (such as the US) route relations perfect sense (as does
figuring out which routes are actually signed on which bits of
road) but in places where there's only one real ref per piece of
tarmac (such as the UK) there's no need to force mappers to start
maintaining relations as well as just recording the reference.


Well, I believe impetus for route relations was Sustrans networks.  
These tags went from the ways to relations years ago already, so call 
me skeptical that there's no multiplexes in the UK (especially since 
without any real effort inside 30 seconds, just randomly scrolling by 
hand to the UK, I see that the A24 and RCN CS7 are multiplexed).  I 
honestly don't see why we should be treating tags related to 
route=road any different than we're already treating route=bicycle.




Sure - there are lots of route relations (such as Sustrans' cycle 
networks) in the UK, but (over here) that's separate from the reference 
of the road.  It's also fair to say that Sustrans' route labelling can 
be "variable", to the point where "the signs on the ground", "the route 
they'd like to use" and "the official current sustrans route" can be 
three different things.  As an aside, Sustrans recently changed their 
official route for some routes just south of where I live to match the 
signs on the ground (and therefore OSM, which was mapped from those) as 
what OSM had was actually more a more sensible route than what they 
had.  Where there is this variability in signing, you can't always 
expect someone (especially a new mapper) to fill in all the details of 
cycle routes that a bit of road is part of, though a cycling fan can 
usually come along and fill in the gaps.  However a new mapper can read 
the reference on normal road signs and should be able to fill in the 
"ref" on the way without difficulty.  The tricky bit (in the US) is 
having a UI in e.g. iD that can guide them through the "add to existing 
nearby route relation".


Both iD and P2 can show nearby relations, but for example at 
http://www.openstreetmap.org/#map=19/53.07007/-2.04161 both also show in 
the relations that you might want to add to a way the relations that a 
way is already part of, and super-relations of other relations (which it 
doesn't need to be added to).


None of this is easy, and iD (correctly in my view) tries to hide 
relation functionality if it can.  I'm just suggesting to try and keep 
it simple where its possible to do so (i.e. don't create route relations 
where it's possible to express the same concept in a simpler way).


Cheers,

Andy (SomeoneElse)




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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Craig Wallace]

On 2015-11-06 13:44, Paul Johnson wrote:

On Fri, Nov 6, 2015 at 7:02 AM, Andy Townsend mailto:ajt1...@gmail.com>> wrote:

Obviously in places where a road can have multiple equivalent
references (such as the US) route relations perfect sense (as does
figuring out which routes are actually signed on which bits of road)
but in places where there's only one real ref per piece of tarmac
(such as the UK) there's no need to force mappers to start
maintaining relations as well as just recording the reference.


Well, I believe impetus for route relations was Sustrans networks.
These tags went from the ways to relations years ago already, so call me
skeptical that there's no multiplexes in the UK (especially since
without any real effort inside 30 seconds, just randomly scrolling by
hand to the UK, I see that the A24 and RCN CS7 are multiplexed).  I
honestly don't see why we should be treating tags related to route=road
any different than we're already treating route=bicycle.


There's not really any 'multiplexes' in the UK.
There are a few places where A roads appear to overlap.for a short 
distance. But its really one road number disappearing, while the other 
continues. So each section of road will only have one official number, 
and only one of the road numbers will be signposted.


Yes, cycle routes do follow numbered roads. But that doesn't change the 
number of the road, it still only has one main ref. If you asked someone 
cycling along there, they would still say they are on the A24.



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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Andrew MacKinnon]

This seems reasonable.

It would be helpful if we changed the renderers to render the ref in a
route=road relation and ignore the ref tag if a route=road relation is
present. In Canada we had a problem a while ago with a user making
mechanical edits adding prefixes like "ON" and "RR" to a lot of roads.
I have been gradually deleting these prefixes but it is very time
consuming. Relations are a much better way of storing this data and if
renderers use the relation instead, then I could just delete these ref
tags instead of fixing them.

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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Martin Koppenhoefer]

sent from a phone

> Am 06.11.2015 um 14:00 schrieb Christoph Hormann :
> 
> AFAIK osm2pgsql does not support including relation membership info in 
> the rendering database.


it can make objects from multipoligon and route relations 

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

Re: [Tagging] Decorative flower fields? (not as a crop?)

[Martin Koppenhoefer]

sent from a phone

Am 06.11.2015 um 14:09 schrieb johnw :

>> I think it's not that different to a cutline for instance, which is one of 
>> the most used values in man_made
> 
> You are right, since it is a place where the land is cleared, a cutline is a 
> clearing in the woods. Similar to clearcut too. but both of those are based 
> removal of existing natural items - the absence of the original - not the 
> growth/presence of new plants.


yes, and I was referring to flowerbed, not flowerfield which I'd see slightly 
different (not in man_made)

cheers 
Martin ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[David Marchal]

___
> 
> On 06/11/2015 10:24, Paul Johnson wrote: 
> 
> Obviously in places where a road can have multiple equivalent 
> references (such as the US) route relations perfect sense (as does 
> figuring out which routes are actually signed on which bits of road) 
> but in places where there's only one real ref per piece of tarmac (such 
> as the UK) there's no need to force mappers to start maintaining 
> relations as well as just recording the reference. 

I also agrees with Paul. This proposal can be useful in some situations, but 
not all networks are such a mess. Here, in France, apart from E-roads,, there 
are virtually no road with several refs, and, AFAIK, that's the same for nearby 
countries. Besides, maintaining such a long relation can quickly become a 
nightmare, so I don't think it would really be useful in most situations, even 
if I understand it could be useful in some situations, like the USA networks 
you described.   
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in, favor of relations

[Richard Welty]

On 11/6/15 5:01 PM, Paul Johnson  wrote:

> > Stop rendering this key and instead render the relations

>> >
>> > Is there *any* map style that does this at the moment?
>> >
> I believe Toby had a working mapnik-based renderer doing this on osm.us at
> one point, though i'm not sure what became of this.
>
it was never on osm.us so far as i know. the demo is still up here:

http://bl.ocks.org/ToeBee/raw/6119134/#13/42.6276/-73.8955

Phil Gold did a lot of work on this, but he's been busy with other things
and i haven't heard of any work on this in a while. i got a lot of the NYS
county route shields up and running.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Dave Swarthout]

@Colin - I see it now in Wiktionary, but since it is not in the OSM Wiki
how would renderers show or use that information? I guess my point is that
the relation manager and tools are difficult to master and forcing their
use on the general mapping community would be a mistake. Even if
deprecating the ref tag was deemed okay by our little group, the general
user community will resist the change and rightly so IMO

Dave

On Fri, Nov 6, 2015 at 8:46 PM, Colin Smale  wrote:

>
>
>
>
>
> On 2015-11-06 14:26, Dave Swarthout wrote:
>
> I was looking at a what I surmise to be a ferry route earlier today and it
> had a tag of route=fairway. Did the mapper not realize what he was doing or
> are the diagnostic tools for determining errors in relations not that
> robust?
>
>
>
> Are you sure that route=fairway is wrong? It can have a nautical meaning:
>
> https://en.wiktionary.org/wiki/fairway
>
> //colin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Named junctions

[John Willis]

(This Was sent earlier but looks like it wasn't received. Cleaned up/ clarified 
a bit and sent again). 


> On Nov 6, 2015, at 1:30 PM, Marc Gemis  wrote:
> 
> However, I do not see why the "ignorance" of the non-Asian mappers

Full disclosure: I am an American. I moved to Japan in 2011, and my 
comprehension of written Japanese is poor (I don't know much kanji at all), 
which makes me much better than a tourist, but I can not claim to speak for 
native Japanese mappers, just what I see in the tagging/wiki. In some ways I am 
stuck in between, because my home (I'm married and not leaving Japan) and 
language don't currently line up yet, so I am very familiar with & mapping 
places I can't always parse the meaning of without research, and dependent on 
the EN wiki. 



TL;DR:

The English/German taggers are the leaders in the tagging scheme AFAIK, so it 
is important for you to be inclusive and flexible when making tagging schemes. 
This will solve issues that you will eventually have to solve anyway, so we 
might as well do it now, for the benefit of all regional maps, not just myself 
and my region. saying a regional rendering solves the issue just puts off 
solving the issue via making a proper tagging system that is flexible enough to 
handle the regional issues we don't know about yet. 



There are many people who are native Japanese speakers mapping, as well as 
people who love Japan (and other Asian countries too, of course) but are native 
English speaking mappers - so I want to make OSM's default render as useful as 
the default render in Google Maps or better. At least I want to repair glaring 
omissions and polish when possible. 


AFAIK, the OSM JA mapping community Is similar to the Wikipedia community - 
they follow the lead of the larger English community. And since 
Europeans/English speakers are driving tagging and "proper tag documentation", 
they are following what we lay down in the wiki, as I understand it. 

So as we are driving the tag set being used and content of the wiki pages, that 
exerts a tremendous amount of control over everyone mapping everywhere. 

And since a lot of the world, map wise, is the same, the difficulties come up 
with difficult to imagine regional or cultural differences, which cannot always 
be solved by just having a region render it in their own style. 

I believe those regional differences should be rendered in the default OSM, as 
the default should be the most useful for all users. 


1) Asian countries, due to the script barrier of their language, offer most 
everything (at least in Japan) in JA and EN - which is reflected in dual labels 
for of most navigation signs throughout all of Japan. This is embraced in the 
default view of google maps, but not in OSM/-carto. This idea of dual language 
labeling should eventually become standard for non-standard scripts makes it 
useful for visitors, residents, and other Asians. It also describes the 
situation on the ground - everything (in Japan at least) is coated in English 
for non-native speakers, so the default render of OSM should reflect that. 

2) Font issues persist. I helped a bit with updating the fonts, but very 
complex characters are difficult to read, there are not many different 
character weights supported, and shields, even with the render change, still 
render Kanji refs badly. 

3) Japan is hit by a spatial mapping issue triple whammy:

- no road names on tertiary or below (90% of all roads have no name or ref) 
- A very very dense place name system & lot number based addressing: nothing is 
labeled in sequence along the roads - a map is necessary to locate almost any 
structure. 

- the need for signals to have consistently rendered icons and for some to be 
named for spatial / map usage for visual navigation. Cities have many named 
signals.  

This makes what iconography and place labels somewhat more important for the 
"last kilometer" of a journey. 

4) regionally agnostic umbrella tags, with consideration given for value 
expansion. This is not so big a deal, as it is the easiest to understand, but 
think of how churchyard or building=church was documented - it is evident that 
all the other religious buildings would need to be tagged, but shrine and 
temple were added to the wiki by me (?), rather than a proposal handling all 
the religious buildings at once. Since the European pages are driving tags 
(English and German, right?), they need to think more globally when adding 
tags. It easy to come up with and document tags, but it is far easier to come 
up with tagging solutions that cover everyone in the first place. 

5) regional variation in the default render should be encouraged. Proper 
regional iconography/shields and certain pattern conventions should be 
encouraged in the main view IMO. For example, the current railway 
renderedblack/white pattern is used only for JR trains. The other private lines 
get a solid line. Again, as spatial navigation is important, having