Re: [Tagging] Multiple values in isced:level

[Graeme Fitzpatrick]

On Tue, 20 Aug 2019 at 09:09, Martin Koppenhoefer 
wrote:

>
> what I wanted to say is that you need to know all possible values to make
> sense of a range, while you need no knowledge about possible values to get
> the information from a list.
>

I can see what you're getting at, but under that concept, when we enter
opening hours as Mo-Fr 09:00-17:00, we should actually be entering
Mo=yes;Tu=yes;We=yes ... 09:00=yes;10:00=yes etc (or should that be
09:00=yes;09:15=yes;09:30=yes ... - no, of course it shouldn't be!).

For some situations, a range is perfectly acceptable, & saying that a
school is 0-12 is one of them.

Thanks

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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Warin]

First. What is to be mapped?

The presence of animals?

Or

The animal output of a agricultural feature?

Once I have that answer I can respond to that issue rather than provide 
multiple answers that confuse.

The first post talks of both presence and output, while the subject says 
presence.



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

Re: [Tagging] Forward/backward routes

[Paul Johnson]

On Mon, Aug 19, 2019 at 6:23 PM Peter Elderson  wrote:

> Well, the simple version I got from bicycle route mappers is: members in
> the main direction have no roles. The fact that there is a role tells you
> it’s a way for the opposite direction, and then forward tells you the
> opposite travel direction goes against the mapped direction of that member
> way, and the backward role tells you the opposite travel direction goes
> with the mapped direction of the way.
>

If the way is traversable as part of the route in both directions, then
this is correct.  If the route only applies to one direction, then you do
need to specify forward or backward.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Branched and alternative roujtes

[Warin]

On 20/08/19 00:11, Kevin Kenny wrote:

(Summary: What do the data *consumers* want to see in the tagging for
route alternatives, circular routes, and routes that begin and end on
dual carriageways?)

On Mon, Aug 19, 2019 at 3:47 AM Sarah Hoffmann  wrote:

We do happen to have a clear rule for unbroken linear routes: just assemble
in the obvious way, no matter if sorted or unsorted. We don't have any rule
for anything more complicated that mappers can follow to get the desired
effect. We already fail with something as simple as a directed unbroken
linear routes and circular routes. There is no single recommended way to
define the start point.

A circular route may not even have a start point.  Hikers doing the
Carnberry Lake 50 can start and end it anywhere and do it clockwise or
anti-clockwise (although there happen to be only a couple of good
places to get on and off the circular route).


Assuming we don't care what happens to really botched relations, all cases
except one that I listed initially are covered with one single simple
instruction to the mapper: sort your route.

What remains are routes which are split/have alternatives/access routes etc.
Gut feeling tells that roles will solve those cases but I get back to you
on that once I had a go at implementing it.

If I recall correctly, you're well on the way to handling role=forward
and role=backward splits - I seem to recall that WMT was fairly
graceful about the one or two of those I put in (to repair routes that
were broken altogether - I'm not in the habit of editing cycling
routes otherwise).

For hiking routes, the splits that I have and don't quite know how to
manage are:

- Short diversions. Some of the trails that I've mapped have short
segments for winter and summer routes, or marked alternatives for use
in case of high water, fire-season trail closures, or beaver activitty
(which, I suppose is a special case of high water).

- Access ways. Ordinarily these are marked separately from the main
trail and I just carry them as separate routes. The only case where
I've really wanted to make some sort of association is that the Green
Mountain Club, in addition to the 'end to end' award on the Long Trail
(for hiking the main stem) offers a much more difficult 'side to side'
award for hiking each of the approach trails. I have Absolutely No
Idea how to represent this, if I were to do so.

- Major diversions. For the 'end to end' award on New York's Long
Path, the suburban sections in Orange County are recognized to be a
problem for hikers, and a recognized alternative is to leave the Long
Path in Harriman Park, follow the Appalachian Trail to High Point, New
Jersey, and then the Shawangunk Ridge Trail to rejoin the Long Path in
Otisville.  I'm perfectly fine, though, with simply offering this as
narrative, and having the relations show this as three separate
trails. Hikers have to make their own decisions sometime!

- Trails that are waymarked only in one direction. I do this with
'oneway=yes' on the relation, and order the ways accordingly, but I
did encounter a circular route that seemed to be ambiguous however I
did it. (The trail maintainers rendered this one moot by installing
signs facing the other way.)

The same sort of things seem to infect road routes:

- Routes that begin and end at the interchanges among dual
carriageways, which give no single point that can be indentified as an
endpoint because the geographic endpoints are different in the two
directions. JOSM has a real problem sorting these.

- Multiple-carriageway routes, where there are grade-separated ways
between 'express' and 'local', or between 'auto' and 'hgv' or between
'vehicles with transponders' and 'vehicles paying cash'.  This is an
additional layer of split on top of 'forward' and 'backward' and is
even worse for messing up sorting.

- The same thing can happen on surface streets where there are
numbered routes that are bannered 'ALT, 'BUSINESS', 'TRUCK', etc. For
these, though, I'm perfectly fine with saying that the loops and spurs
are entirely separate routes. The signage is distinct, and people in
the affected areas are used to being directed onto 'US 20 Business' or
whatever.

We have 'forward' and 'backward' pretty much conquered (except for the
dual-carriageway case). WMT already appears to figure it out, (well,
mostly), and JOSM successfully sorts these, even when routes traverse
roundabouts.

I'd like to hear from data consumers in particular what tagging they'd
like to see for

- diversions and alternatives
- routes with different endpoints in the forward/backward directions
- spur routes
- one-way routes that may be circular


There needs to be roles for these (primarily a mapper here).

Are not diversions and alternatives the same thing? Or at least close enough 
that they can use the same OSM tags?

I see spurs differently from access tracks. Spurs may be dead ends off to a 
look out or camp site.

Access tracks provide access to the actual route, they 

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Joseph Eisenberg]

Re: produce,

It's much harder for a mapper to find out if a herd of goats is used
to produce milk, meat or cheese than to just tag "there are goats
here", even if you are doing a local survey. Unless the farm has a
sign like "Farmer Joe's Eggs", it's not easy to tell if chickens are
raised for meat or eggs, or for live sale to other farms. This is why
I believe it would be useful to have a standard key to tag livestock
animals on farms, just as there are tags for the type of crops growing
on farmland, the type of orchard/plantation trees/plants, and the type
of aquatic organism raised in aquaculture ponds.

It's okay if mappers want to add produce=cheese to an farmyard where
goats are kept, but it's still useful to add animal/livestock=goats -
this also shows that it's goat cheese, not regular cow milk cheese.

Joseph

On 8/20/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 19. Aug 2019, at 15:28, Joseph Eisenberg 
>> wrote:
>>
>> If we remove the animal=yes tags, there are about 247 uses of animal=*
>> on landuse=farmyard, landuse=meadow, and landuse=farmland combined, so
>> it's not huge.
>
>
> animal=yes/no would already be a quite useful generic distinction for
> farmyards
> It’s not very common, I agree.
>
> 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] Forward/backward routes

[Peter Elderson]

Well, the simple version I got from bicycle route mappers is: members in the 
main direction have no roles. The fact that there is a role tells you it’s a 
way for the opposite direction, and then forward tells you the opposite travel 
direction goes against the mapped direction of that member way, and the 
backward role tells you the opposite travel direction goes with the mapped 
direction of the way.

I don’t see the merit of this... Who or what needs this information?  Roles 
should simply tell you the role the way plays in the route. Then you need only 
one: backward. Everything that’s not backward is the main (forward) route. 
Further, all members without a role should add up to one linear chain. All 
members with a role, being the deviations for the opposite direction, that 
could be a lot of small chains and even single ways. I am sure data users have 
means to determine which parts of the forward chain should be used reversely to 
produce the complete route for opposite direction. Maybe the order of the ways 
is a clue?

Mvg Peter Elderson

> Op 20 aug. 2019 om 00:28 heeft Kevin Kenny  het 
> volgende geschreven:
> 
>> On Mon, Aug 19, 2019 at 6:05 PM Volker Schmidt  wrote:
>>> On Mon, 19 Aug 2019 at 15:21, Kevin Kenny  wrote:
>>> ... when the forward/backward roles do not indicate the direction of 
>>> travel, as is the case with bicycle routes.
> 
> That was Peter Elderson, not me, so I'll defer to him for an answer to
> your question.
> 
> ___
> 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] Multiple values in isced:level

[Martin Koppenhoefer]

sent from a phone

> On 20. Aug 2019, at 00:54, Andrew Davidson  wrote:
> 
> Is there a ISCED level 1A?


maybe not, or not currently (they could introduce them at some point), what I 
wanted to say is that you need to know all possible values to make sense of a 
range, while you need no knowledge about possible values to get the information 
from a list.


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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Peter Elderson]

> Volker Schmidt  het volgende geschreven:
> 
>> On Mon, 19 Aug 2019 at 15:40, Peter Elderson  wrote:
>> Ideally, you should not have to create gpx-s from them and you should need 
>> no ordering or routing at all, because they ARE the routes. An app or 
>> gps-device should use them as is, just tell the user what to do next. Since 
>> no app currently does that (future still has to arrive) we resort to 
>> transferring the route to them as tracks, i.e. gpx.
> 
> Now we are getting closer to the point. You are correctly saying "no app is 
> currently doing that". So why should we sort topologically non-sortable 
> route-relations members? We have a solution that works with existing tools on 
> unsorted hiking/cycling routes, and that is routing with strong preference on 
> the use of ways that are part of cycling/hiking routes.
> I see the problem from the mapper's perspective (as I map a lot) and from the 
> end-users perspective (I very often design bicycle tour routes from OSM 
> data). 
> I am not a data consumer in the sense I do not write software thta uses OSM 
> data, I am an end usere, eclusivley using the software produced by others) 
> and I acknowledge that  my experience is limited to cycling/hiking routes. I 
> am sure there are routes that have different problems and may need sorting, 
> One such category are most likely public transport routes, which are used in 
> a completely different way.

Routes in osm describe closely the routes found on the road. They are described 
as the chain of ways you follow. If they don’t, that should be fixed so they 
again reflect the situation on the road. The osm route IS the route, and it 
should be usable as is, without redoing the routing. If you find it necessary 
to do the routing again, no matter how cleverly you do that, you don’t fix the 
problem, you are just fixing errors at the wrong end, leaving the osm data as 
flawed as before. (Question: where does your weighted routing start and end?)

If you have a method of fixing the data, I would like it better if you make 
that avaible as a tool to enhance/ensure the quality of the osm-data, so the 
recorded routes can be used as the ready-to-use routes they are supposed to 
reflect.

Once routes are reliable for direct use, they will be used much more frequently 
in real applications. Osmand could use it, they now demand a linear gpx even 
for routes that are already known and displayed because you just can’t rely on 
OSM routes. If they could, exact turnbyturn instructions could be given to the 
user, complete with other map info, without any routing algorithm, because the 
route is already there.

In the current state, reliability is simply too low for direct use. If that 
remains the case over the next few years, mark my words, you can stop putting 
routes into osm, because other sources will offer far better functionality 
based on actually reliable data. The people who mark the ways will record 
changes realtime, and that will be available for users with apps near realtime. 
Then osm mappers who now often are faster with updates, will always be slower 
and they will be recording things that are already done better elsewhere (and 
shown on the OSM of course, just leaving out the messy data)


> 
> 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] Multiple values in isced:level

[Andrew Davidson]

On Tue, Aug 20, 2019 at 8:22 AM Martin Koppenhoefer 
wrote:

> they are not the same. 0-2 could also be the same as 0;1A;1B;2
>
>
Is there a ISCED level 1A?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Forward/backward routes

[Kevin Kenny]

On Mon, Aug 19, 2019 at 6:05 PM Volker Schmidt  wrote:
> On Mon, 19 Aug 2019 at 15:21, Kevin Kenny  wrote:
>> ... when the forward/backward roles do not indicate the direction of travel, 
>> as is the case with bicycle routes.

That was Peter Elderson, not me, so I'll defer to him for an answer to
your question.

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

Re: [Tagging] Multiple values in isced:level

[Martin Koppenhoefer]

sent from a phone

> On 20. Aug 2019, at 00:06, Andrew Harvey  wrote:
> 
> End of the day, it's easy for a computer to read "0-2" and "0 to 2" and 
> "0,1,2" and "0;1;2" as all the same,


they are not the same. 0-2 could also be the same as 0;1A;1B;2

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

Re: [Tagging] Multiple values in isced:level

[Andrew Harvey]

https://taginfo.openstreetmap.org/keys/grades#values overwhelmingly uses
the dash to show a range, and to a lesser degree the comma to list multiple
values. In fact this is what is suggested at
https://wiki.openstreetmap.org/wiki/Key:grades. To use a semicolon in this
context or something like grades:1=yes, grades:2=yes etc. goes against that
common practice.

End of the day, it's easy for a computer to read "0-2" and "0 to 2" and
"0,1,2" and "0;1;2" as all the same, so really mappers should be able to
use what makes the most sense for them or what's less error prone and
simpler, as they all should be easily interpreted by the downstream data
consumer.

On Tue, 20 Aug 2019 at 04:53, Jo  wrote:

> Wonderful, thank you for your contribution to standardising, by doing your
> own thing anyway. Really great.
>
> Jo
>
>
>
> On Mon, Aug 19, 2019 at 3:46 PM Andrew Harvey 
> wrote:
>
>> I'll still be using a range with a -. so 0-2 to mean from 0 to 2
>> inclusive. I've used it all over my state for schools together with the
>> grades key. To me it's a lot clearer and simpler than the semicolon or
>> multiple yes/no values.
>>
>> On Sat, 17 Aug 2019 at 16:53, Lanxana .  wrote:
>>
>>> Hi!
>>>
>>> so, after reading the different opinions, I understand that I can use
>>> the semicolon (;) or boolean values (yes/no), and both systems would be
>>> correct, is it? And, in any case, it should be documented in the wiki.
>>>
>>> And I understand too, that it was a war of editions about the use of
>>> semicolon like a value separator, so my question is now that if the current
>>> version of the page it's ok or not, because I'd like complete its
>>> translation into Spanish.
>>>
>>> Thanks!
>>>

>>>
>>> 
>>>  Libre
>>> de virus. www.avast.com
>>> 
>>> <#m_-2274713851610012818_m_-8517338411723742137_m_-315500903686677547_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>>> ___
>>> 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 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] Forward/backward routes

[Volker Schmidt]

On Mon, 19 Aug 2019 at 15:21, Kevin Kenny  wrote:

> ... when the forward/backward roles do not indicate the direction of
> travel, as is the case with bicycle routes.
>

If that statement is correct I have mistagged hundreds or more km of cycle
routes.
I use role=forward typically on oneway streets where bicycles are not
allowed against the direction of the motorised traffic and where the
opposite direction bicyle traffic on the bicycle route is using
neighbouring streets for the bicycle route in the opposite direction of the
route relation, but as long as the bicycle flow is in the direction of the
oneway I use role forward. The only case where I would use role=backward
(in a bicycle route) is when there is a contra-flow cycle lane tagged on a
one-way street.

Similarly when a bicycle route include roundabouts (in that case I split
the roundabout and use two "role=forward" segments to carry the bicycle
route.along the roundabout.

I admit that I learned this approach from other mappers, but I am not sure
it's documented in the wiki, now that I am thinking about it.

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Martin Koppenhoefer]

sent from a phone

> On 19. Aug 2019, at 17:01, Richard Fairhurst  wrote:
> 
> (I have elided most of the intermediate steps.)


and a lot of preparatory steps: you need to buy a computer, find a wall outlet 
to plug it in, find the power button, find an internet provider and subscribe 
to a plan, configure your modem, ...

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Volker Schmidt]

On Mon, 19 Aug 2019 at 15:40, Peter Elderson  wrote:

> Ideally, you should not have to create gpx-s from them and you should need
> no ordering or routing at all, because they ARE the routes. An app or
> gps-device should use them as is, just tell the user what to do next. Since
> no app currently does that (future still has to arrive) we resort to
> transferring the route to them as tracks, i.e. gpx.
>

Now we are getting closer to the point. You are correctly saying "no app is
currently doing that". So why should we sort topologically non-sortable
route-relations members? We have a solution that works with existing tools
on unsorted hiking/cycling routes, and that is routing with strong
preference on the use of ways that are part of cycling/hiking routes.
I see the problem from the mapper's perspective (as I map a lot) and from
the end-users perspective (I very often design bicycle tour routes from OSM
data).
I am not a data consumer in the sense I do not write software thta uses OSM
data, I am an end usere, eclusivley using the software produced by others)
and I acknowledge that  my experience is limited to cycling/hiking routes.
I am sure there are routes that have different problems and may need
sorting, One such category are most likely public transport routes, which
are used in a completely different way.

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

Re: [Tagging] Signposts in Roles of route members

[Volker Schmidt]

On Mon, 19 Aug 2019 at 19:52, Andy Townsend  wrote:

> The method for mapping the signposts is not quite the same as the CAI
> page.  Signposts are mapped as either guidepost (see e.g.
> https://www.openstreetmap.org/node/5894712185 ) or route_marker (
> https://www.openstreetmap.org/node/5734015420 ) depending on what form
> the route marker takes.  Each has the role "marker" within the relation.
>
The CAI approach, at present at least, is to only map guideposts, but not
markers.
Guideposts in the CAI scheme always have direction indications (typically
destination and distance and/or walking time). Painted markers or symbols
are not normally mapped.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Peter Elderson]

Andy Townsend :

> On 19/08/2019 17:21, Peter Elderson wrote:
>
>  the only way for the likes of me is to use detection tools and
> maintenance tools to order data by hand at the mapping level, so ordinary
> people can use waymarkedtrails to get usable linear gpx-s for their
> basecamps, route editors, trip planners, navigation apps and devices.
>
> You keep perpetrating this myth - you're suggesting again that ways in
> routes need to be sorted before they can be used in Garmin software and
> navigation devices.  It simply isn't true.  For about 11 years now I've
> been creating Garmin maps based on OSM data, and I've been walking along
> local and national trails in the UK for far longer.  Never have I needed to
> "follow a GPX" - it seems a very alien thing to want to do, and (as
> mentioned previously) isn't actually supported by any of the various Garmin
> hiking GPSs that I've used.  If you want to do that - fine - but not
> everyone does.
>
Ok, I accept I just don't know how it's done. So how is that done? How do I
tell my Garmin to guide me along, say, the Limes trail through the
Netherlands? It's mapped in OSM as a series of sections, each relation
encompassing one days walking, and all the sections are in a parent route,
which in turn is part of the international Limes trail.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Jo]

OK, I have fixed my fair share of route relations, both public transport
and bicycle and foot routes.

I find it easier to EDIT them, when they are sorted. To figure out there
are problems with them, when they are sorted. JOSM actually does a great
job with the sorting. For bicycle, foot and horse route relations it can
handle forward/backward roles very well, when they branch.

I've been developing PT_Assistant for the parts that are missing in JOSM.
It now comes with routing helper functionality, which works for bicycle
routes too since this summer.

Instead of having to manually select, split, deselect not needed part of
ways manually, you can simply direct it by pressing numbers, which
correspond to segments rendered in different colours. It would be wonderful
if that could be implemented in iD as well. No need to know much about the
underlying relations. If you know the itinerary you want to add, you're
good to go.

It takes into account oneway traffice and turn restrictions for the mode of
transport of the route relation you are editing. So it behaves differently
when you are closing gaps in bus route relations than when you're doing the
same for bicycle route relations.

It still requires lots of JOSM atm. I'll give a demo/workshop of how it
works during SotM in Heidelberg. In the mean time I'm creating videos on
Youtube.

https://www.youtube.com/user/yoyo7yoyo

Polyglot

On Mon, Aug 19, 2019 at 6:57 PM Andy Townsend  wrote:

> On 19/08/2019 17:21, Peter Elderson wrote:
>
>  the only way for the likes of me is to use detection tools and
> maintenance tools to order data by hand at the mapping level, so ordinary
> people can use waymarkedtrails to get usable linear gpx-s for their
> basecamps, route editors, trip planners, navigation apps and devices.
>
> You keep perpetrating this myth - you're suggesting again that ways in
> routes need to be sorted before they can be used in Garmin software and
> navigation devices.  It simply isn't true.  For about 11 years now I've
> been creating Garmin maps based on OSM data, and I've been walking along
> local and national trails in the UK for far longer.  Never have I needed to
> "follow a GPX" - it seems a very alien thing to want to do, and (as
> mentioned previously) isn't actually supported by any of the various Garmin
> hiking GPSs that I've used.  If you want to do that - fine - but not
> everyone does.
>
> I suspect that "Ordinary people" will just download OSM maps from
> http://garmin.openstreetmap.nl/or one of the alternatives - they'll see
> the route on-screen and they will navigate using that.  Sometimes they'll
> stray from it because they've arranged somewhere to eat or stay; they're
> not limited to "only walking along the actual ways that form the official
> route" which you seem to be.
>
> If you have a different requirement then that's very much a personal
> requirement for you; please don't try and dissuade "ordinary people" from
> contributing to mapping hiking routes.  If you want to manually sort and
> rearrange hiking route data in a way that doesn't prevent everyone else
> from contributing that's also fine, but please don't raise the bar to
> contributions so high that people can't contribute at all. You'd
> essentially be filling the role that Kevin Kenny identified above as
> "Someone in the community who can handle relations will then have the
> geometry already established, so tidying the topology becomes a clerical
> task".
>
> The people we want adding hiking routes to OSM are people who've just
> taken their boots off, know where routes have been diverted, and know what
> the surface tags etc. should be, not people who've never emerged from
> behind a PC.
>
> Best Regards,
>
> Andy
>
> ___
> 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] Signposts in Roles of route members

[Andy Townsend]

On 19/08/2019 09:50, Volker Schmidt wrote:
Let me also introduce a further complication in the "sorting" 
discussion for hiking and cycling route relations.
Some mappers like the idea to keep signposts in the same route 
relation as the ways making up the route.


By way of example, here's one near me:

https://www.openstreetmap.org/relation/370667

The method for mapping the signposts is not quite the same as the CAI 
page.  Signposts are mapped as either guidepost (see e.g. 
https://www.openstreetmap.org/node/5894712185 ) or route_marker ( 
https://www.openstreetmap.org/node/5734015420 ) depending on what form 
the route marker takes.  Each has the role "marker" within the relation.


Best Regards,

Andy


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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Martin Koppenhoefer]

sent from a phone

> On 19. Aug 2019, at 15:28, Joseph Eisenberg  
> wrote:
> 
> If we remove the animal=yes tags, there are about 247 uses of animal=*
> on landuse=farmyard, landuse=meadow, and landuse=farmland combined, so
> it's not huge.


animal=yes/no would already be a quite useful generic distinction for farmyards
It’s not very common, I agree.

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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Martin Koppenhoefer]

sent from a phone

> On 19. Aug 2019, at 15:20, Joseph Eisenberg  
> wrote:
> 
> similar and in many places it can be hard to distinguish hay meadow
> from grazing pasture during most of the year.


the presence of a fence aiming at keeping the animals inside may be an 
indication, although not everywhere (if there’s someone keeping an eye on the 
animals or the area is quite remote you may not need the fence, and fences may 
be used in some areas to keep people off the meadow although no animals are 
grazing there).

Still in many other places it would work. With profound on the ground knowledge 
(continued observation) you may tell, but we are not generally having this many 
eyes on the ground (yet ;-) ).

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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Martin Koppenhoefer]

sent from a phone

> On 19. Aug 2019, at 13:13, Warin <61sundow...@gmail.com> wrote:
> 
> So the produce key is used for the output, if that is live animals then they 
> can be tagged that way.
> If the output is milk then produce=milk not produce=cow.


+1, similarly for chicken, which are usually either kept for eggs or for meat


> 
> If the output is goats then produce=goats.


or animal=goat produce=cheese?


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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Martin Koppenhoefer]

sent from a phone

> On 19. Aug 2019, at 12:35, marc marc  wrote:
> 
> 16% of landuse=farmyard have a anima=* tag.
> I didn't understand what argument to hope that the
> current most used tag would change in favor of a marginal tag.


generally I would expect a farmyard to contain several buildings with possibly 
many different animals, either outside of in buildings, so these tags often 
would not be associated with the farmyard but with parts of it. 

The tag building=farm_auxiliary is amongst the most popular building tags, but 
is very generic and could mean a stable, cowshed, pigsty, sheep pen, barn, 
henhouse, garage, etc. IMHO it would be desirable to be more specific at this 
level as well. 

While livestock is technically more precise, I would be fine with a generic and 
easy to understand, generic „animal“ tag as well.

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Andy Townsend]

On 19/08/2019 17:21, Peter Elderson wrote:
 the only way for the likes of me is to use detection tools and 
maintenance tools to order data by hand at the mapping level, so 
ordinary people can use waymarkedtrails to get usable linear gpx-s for 
their basecamps, route editors, trip planners, navigation apps and 
devices.


You keep perpetrating this myth - you're suggesting again that ways in 
routes need to be sorted before they can be used in Garmin software and 
navigation devices.  It simply isn't true.  For about 11 years now I've 
been creating Garmin maps based on OSM data, and I've been walking along 
local and national trails in the UK for far longer.  Never have I needed 
to "follow a GPX" - it seems a very alien thing to want to do, and (as 
mentioned previously) isn't actually supported by any of the various 
Garmin hiking GPSs that I've used.  If you want to do that - fine - but 
not everyone does.


I suspect that "Ordinary people" will just download OSM maps from 
http://garmin.openstreetmap.nl/or one of the alternatives - they'll see 
the route on-screen and they will navigate using that.  Sometimes 
they'll stray from it because they've arranged somewhere to eat or stay; 
they're not limited to "only walking along the actual ways that form the 
official route" which you seem to be.


If you have a different requirement then that's very much a personal 
requirement for you; please don't try and dissuade "ordinary people" 
from contributing to mapping hiking routes.  If you want to manually 
sort and rearrange hiking route data in a way that doesn't prevent 
everyone else from contributing that's also fine, but please don't raise 
the bar to contributions so high that people can't contribute at all. 
You'd essentially be filling the role that Kevin Kenny identified above 
as "Someone in the community who can handle relations will then have the 
geometry already established, so tidying the topology becomes a clerical 
task".


The people we want adding hiking routes to OSM are people who've just 
taken their boots off, know where routes have been diverted, and know 
what the surface tags etc. should be, not people who've never emerged 
from behind a PC.


Best Regards,

Andy

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Peter Elderson]

Richard Fairhurst :

> On mobile, on train, apologies for lack of formatting. :)
>
> Sarah - the problem is that when you say “one single simple
> instruction to the mapper: sort your route“, the instruction might be
> simple
> but carrying it out isn’t.
>
> Let’s say we have a cyclist, new to OSM, who wants to add a newly opened
> section to an existing route. As Peter says, doing this to said
> specification “usually requires lots of JOSM”.


That was about repairing a broken and corrupted route relation.


> The steps involved to do this
> in sorted order are:
>
> 1. spend half the afternoon trudging through contradictory pages on the OSM
> wiki to find out what you have to do
> 2. apparently it involves this thing called “JOSM”. Download that
> 3. apparently that involves this thing called “Java”. Download that too
> 4. learn to use this 80s throwback of a GIS program with the UI of a
> startled warthog
> 5. find route sorting stuff in JOSM somewhere
> 6. make edit
> 7. get shouted at by sociopaths in changeset comments because unwittingly
> you did something wrong
>

You simply can't do enough without JOSM if you really want to maintain
routes. Other method are not up to the task. Entering en new section is
easy. Yes, you have to set up and learn the editor and learn about routes
and relations. If you don't want to do that, you can't do it. It should be
easier - but it isn't. Smartphone apps will not do.


> (I have elided most of the intermediate steps.)
>
> That isn’t how OSM works. It might be how Wikipedia works but we are better
> than that.
>

No we are not. OSM is very primitive, chaotic and unreliable. If things
were better, simple edits would not be allowed to break relations.


> _If_ route ordering is to be expected, then the burden needs to be on the
> editing software, not the mapper. That means invisible support in iD, P2,
> and I’m guessing Vespucci and Go Map (I don’t know what their current
> support is like). And tbh the burden of providing patches is on the few
> people who are asking for it. Certainly I’m happy to implement something in
> P2 if it’s an afternoon’s work and I’m given a fully fleshed out algorithm
> which copes with the partly loaded relations that are standard for an
> online
> editor, but I’m not going to spend two days of dev time on something for
> which there is no great clamour outwith a couple of people on the tagging
> list.


If nobody has a better way and people who say they have solutions do not
provide that knowledge in a usable form e.g. an extraction method or
linking method that solves the problems, the only way for the likes of me
is to use detection tools and maintenance tools to order data by hand at
the mapping level, so ordinary people can use waymarkedtrails to get usable
linear gpx-s for their basecamps, route editors, trip planners, navigation
apps and devices.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] roads with many names

[Rob Savoye]

On 8/18/19 10:05 PM, Kevin Kenny wrote:

> route=road relations provide a way to group all the individual
> segments of a numbered route into a coherent whole, and allow for
> better handling of things like the choice of highway shield and the
> handling of concurrencies (where two numbered routes run along the
> same roadway).

  Interesting, this answers something I've wondered about. Sometimes I
see ways in data that you can tell the GPS signal dropped, those I just
connect. I'm mapping locally, so have a sense of when that's
appropriate, and can drive there to validate. When the metadata changes
sometimes in the segments, those have to be separate to preserve that.
For us that's often where you park the fire truck and get the UTV
going... Anyway, as a long term solution, route=road seems the way to go
after I get all the data cleaned up.

> For your example, the 'ref' on the way would be 'CR2;FS 729.2B'. The
> way would be a member of two route relations, one for the county road
> and one for the Forest Service route.

 If I ever got around to adding all these relations, it might improve
search. A big task unfortunately. There are other issues with how search
works in OsmAnd, that's a different email list. :-)

- rob -

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Kevin Kenny]

On Mon, Aug 19, 2019 at 11:10 AM Paul Allen  wrote:
> And say what you like about Warthogs being ugly, the Fairchild Republic A-10
> Thunderbolt II (aka Warthog) was a very effective war plane, both in kill 
> power and
> survivability.  Please don't make JOSM's UI seem better than it is by 
> comparing it
> to the Warthog.

If we're talking about the aircraft, you're right that the A-10 is an
amazing aircraft; even now, the USAF doesn't have anything that does
its mission nearly as well as it does. (Of course, close air support
isn't nearly glamourous enough for the flyboys. The Army would love to
take over the A-10 or develop a successor, but isn't allowed
fixed-wing aircraft in its ambit.)

If we're talking about the beast, beauty is in the eye of the
beholder. Gentlemen warthogs appear to find lady warthogs quite
attractive, since there seems still to be no shortage of warthog
piglets.
-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Kevin Kenny]

On Mon, Aug 19, 2019 at 11:02 AM Richard Fairhurst  wrote:
> Let’s say we have a cyclist, new to OSM, who wants to add a newly opened
> section to an existing route. As Peter says, doing this to said
> specification “usually requires lots of JOSM”. The steps involved to do this
> in sorted order are:
>
> 1. spend half the afternoon trudging through contradictory pages on the OSM
> wiki to find out what you have to do
> 2. apparently it involves this thing called “JOSM”. Download that
> 3. apparently that involves this thing called “Java”. Download that too
> 4. learn to use this 80s throwback of a GIS program with the UI of a
> startled warthog
> 5. find route sorting stuff in JOSM somewhere
> 6. make edit
> 7. get shouted at by sociopaths in changeset comments because unwittingly
> you did something wrong

I'd much rather that the novice's task be:

1. Map the ways making up the new section of the route.
2. If you or your editor can't handle route relations of the
complexity that you encounter, don't worry about it. Either flag the
changeset for review or leave an OSM note indicating that the work is
undone.
3. Someone in the community who can handle relations will then have
the geometry already established, so tidying the topology becomes a
clerical task.

Of course, this depends on the solution to step (7) above, for which I
have no good answer.

I have absolutely no problem with tidying a route anywhere within a
hundred miles of my home base if a mapper can explain to me in words
what's in the field, and has created ways so that I have the geometry.
There aren't *that* many routes out there. I understand that route
relations can be complex, and there's no need for everyone to be able
to edit them. If we are a global collaborative community, can't we act
like one and admit that there may be cases that require specialists to
manage? (By the way, the "explain in words" may be a sticking point.
There seem to be a lot of people who want to give me a bucket of data
without explanation, and think that the data speak for themselves.)

There's also something to be said for using the ugly editors to prove
the concept, because at this point, we don't yet know how to do
everything, much less how to make it novice-friendly! The exception is
simple linear routes, and Sarah or I can give you algorithms - or at
least heuristics - for maintaining sort order on those. But we're
perfectly happy to consume those unsorted, precisely because we do
know how to automate cleaning them up.

I do want editors minimally to observe the 'don't break the route'
principle. About 80% of the broken-route problem can be solved simply
by, "when splitting a way, both the pieces become members of any route
relations in which the original way appeared, with the same role if
one is specified, preferably preserving continuity if either or both
endpoints was shared with the neighbouring way in the relation." At
least iD, Meerkartor and JOSM all do that. (It means downloading the
two neighbouring ways. This doesn't appear to be a problem for iD).
It's a purely local check, not requiring full analysis of the route.
I'm willing to delegate all the more complex stuff to a specialist
editor.

For what it's worth, I think that the "route editing is complex"
problem partly drives the 'startled warthog' and '1980s throwback'
issues. In my experience, newer and prettier UI's try so very hard to
be pretty and novice-friendly that in many cases, they simply reach a
ceiling of complexity beyond which they can't cope or become an
obstacle to the power user. (I'm looking at *you*, LabView!)  Beyond
that point, "ugly but serviceable" starts looking a lot more like the
ideal approach. I'm not saying that any OSM editor falls in this
category, but I've used far too many applications where the UI
designer ruled, and the thing I want to do becomes impossible because
the designer couldn't figure out a way to make it attractive enough.
(I've even had the misfortune of developing applications in that sort
of political environment. They were less than 100% successful.) Of
course, I write this as a grumpy old man, so take my comment as senile
raving if you wish.

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Martin Koppenhoefer]

sent from a phone

> On 19. Aug 2019, at 12:17, Joseph Eisenberg  
> wrote:
> 
> Unfortunately, the key animal=* has also been used for zoo animals
> (see elephant, etc) and some of the values are rare, proposed separate
> features like animal=wellness and animal=cemetery.


I would not see a problem in the animal key being used in zoos and for 
livestock, as this could still be seen as consistent use. Animal=wellness or 
cemetery on the other hand follow a different concept (IMHO schemes like this 
are not favorable, similar to camp_site=toilets etc, because I would prefer 
schemes where A=B means that B is a kind of A rather than A a context)

Cheers Martin 




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

Re: [Tagging] Branched and alternative roujtes

[Richard Fairhurst]

My use-case for cycle.travel is having a single polyline that I can make into
a route guide at https://cycle.travel/routes . Currently there’s two dozen:
I’d like there to be thousands. So:

> - diversions and alternatives 

Give them consistent roles so I can ignore them. 

> - routes with different endpoints in the forward/backward directions 

Not fussed. I only do the route in one direction. 

> - spur routes 

Again, consistent roles so I can filter them out. 

> - one-way routes that may be circular 

If there’s an agreed start point, then put the node in the relation with an
appropriate role. 

cheers
Richard



--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Paul Allen]

On Mon, 19 Aug 2019 at 16:02, Richard Fairhurst 
wrote:

Let’s say we have a cyclist, new to OSM, who wants to add a newly opened
> section to an existing route. As Peter says, doing this to said
> specification “usually requires lots of JOSM”. The steps involved to do
> this
> in sorted order are:
>
> 1. spend half the afternoon trudging through contradictory pages on the OSM
> wiki to find out what you have to do
> 2. apparently it involves this thing called “JOSM”. Download that
> 3. apparently that involves this thing called “Java”. Download that too
> 4. learn to use this 80s throwback of a GIS program with the UI of a
> startled warthog
> 5. find route sorting stuff in JOSM somewhere
> 6. make edit
> 7. get shouted at by sociopaths in changeset comments because unwittingly
> you did something wrong
>
> (I have elided most of the intermediate steps.)
>

It's that easy?  Last time I did it, it seemed a lot harder than that.

And say what you like about Warthogs being ugly, the Fairchild Republic A-10
Thunderbolt II (aka Warthog) was a very effective war plane, both in kill
power and
survivability.  Please don't make JOSM's UI seem better than it is by
comparing it
to the Warthog.

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Richard Fairhurst]

On mobile, on train, apologies for lack of formatting. :)

Sarah - the problem is that when you say “one single simple 
instruction to the mapper: sort your route“, the instruction might be simple
but carrying it out isn’t.

Let’s say we have a cyclist, new to OSM, who wants to add a newly opened
section to an existing route. As Peter says, doing this to said
specification “usually requires lots of JOSM”. The steps involved to do this
in sorted order are:

1. spend half the afternoon trudging through contradictory pages on the OSM
wiki to find out what you have to do
2. apparently it involves this thing called “JOSM”. Download that
3. apparently that involves this thing called “Java”. Download that too
4. learn to use this 80s throwback of a GIS program with the UI of a
startled warthog
5. find route sorting stuff in JOSM somewhere 
6. make edit
7. get shouted at by sociopaths in changeset comments because unwittingly
you did something wrong 

(I have elided most of the intermediate steps.)

That isn’t how OSM works. It might be how Wikipedia works but we are better
than that. 

_If_ route ordering is to be expected, then the burden needs to be on the
editing software, not the mapper. That means invisible support in iD, P2,
and I’m guessing Vespucci and Go Map (I don’t know what their current
support is like). And tbh the burden of providing patches is on the few
people who are asking for it. Certainly I’m happy to implement something in
P2 if it’s an afternoon’s work and I’m given a fully fleshed out algorithm
which copes with the partly loaded relations that are standard for an online
editor, but I’m not going to spend two days of dev time on something for
which there is no great clamour outwith a couple of people on the tagging
list. 

cheers
Richard




--
Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html

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

Re: [Tagging] Branched and alternative roujtes

[Paul Allen]

On Mon, 19 Aug 2019 at 15:13, Kevin Kenny  wrote:

> (Summary: What do the data *consumers* want to see in the tagging for
> route alternatives, circular routes, and routes that begin and end on
> dual carriageways?)
>

Since you've broadened the discussion to deal with more than just walking/
hiking/cycling routes, I'll take the opportunity to mention a bus route
(yes,
THAT one, yet again).  It may seem somewhat irrelevant to walking routes
as it has complications they (usually) do not, but a solution that handles
this bus route well would probably be useful for other bus routes and other
types of route.

It's a very messy circular route.  I don't see how any algorithm could
correctly
figure out the actual sequence of ways traversed unless they were sorted
correctly.  Three times it goes into a cul-de-sac, reverses into a side-road
(that is also a cul-de-sac) then goes forward in the opposite direction from
whence it came.  In one place it does the same reverse-turn trick in the
middle
of a very long road because it doesn't go all the way.  In another place it
goes around
four sides of a square, looping the loop.  In one place it traverses the
same sequence
of ways twice, about 30 minutes apart.  Even the drivers occasionally get it
wrong.  It's this: https://www.openstreetmap.org/relation/8592409

Even with a close inspection of the one-way streets along the route, it's
impossible to figure out exactly the sequence in which it traverses the
route.
And yet the information is there (I hope, but there may be errors) in the
ordering
of the relation.  We don't seem to have a tool that would let an ordinary
user
figure it out easily, but a user could (with a great deal of time and
effort)
use the query tool of standard carto to get the route, then work his or way
through
the list of ways in the route by clicking on them in turn, then returning
back to the list
each time. A slightly more savvy user would right-click on each way in turn
to open
it in a new tab, but it's still a lot of time and effort.

At this point I had a thought.  Given what we already have in standard
carto's query
tool, it would be a Simple Matter Of Programming[tm] to add a way of
dealing with
routes.  When I say "SMOP" it could be anything from an hour of trivial
coding to
weeks and weeks of a complete rewrite, but that's just a matter of details
and
some Dunning-Krugeresque hand waving on my part.

The way the query tool works is to return a list of nearby objects.  Hover
over any
object in the list and it is highlighted in a browny-orange.  Very useful.
Suppose
that sort of highlighting also worked with the list of ways in a route
relation (as in
the link above).  The whole route is highlighted in browny-orange.  But if
hovering
over a way in the list caused that way to be highlighted in a different
colour, you
could easily see the steps in the route and the sequence in which they are
traversed (assuming it was correctly sorted, of course), by hovering your
way through
the list.

Things get complicated with alternate routes and variant routes, but I'll
just
do some more Dunning-Krugeresque hand-waving here.

Of course, we're always going to have routes that aren't sorted.  Partly
because
some editors disordered routes (they seem not to do so these days, although
it's
possible they get confused by rare cases).  Partly because some mappers
don't
realize they should do so (although mappers would tend to add the ways of a
route
in sequence and a good editor would maintain that sequence).  Partly
because some
mappers think it's their mother's job to tidy their bedroom (sorry, I meant
the router's
job to make sense of what they've mapped).  I suspect that if standard
carto's query
permitted routes to be inspected that way, more mappers would take care to
ensure
their routes were sorted.

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

Re: [Tagging] Forward/backward routes

[Paul Johnson]

On Mon, Aug 19, 2019, 08:20 Kevin Kenny  wrote:

> On Mon, Aug 19, 2019 at 6:34 AM Peter Elderson 
> wrote:
> > Keeping linear main route and alteratives separate is actually quite
> straightforward and much less work than creating and maintaining routes
> with roles. Especially when the forward/backward roles do not indicate the
> direction of travel, as is the case with bicycle routes.
>
> The 'forward' and 'backward' roles are well defined. At least two
> editors that I've used understand them. JOSM appears to sort them
> correctly. (It does stumble a bit in the special case where a
> route=road ends at junction among dual carriageways, because it cannot
> find a single endpoint.)  We seem to have this problem mostly solved.
>
> I disagree with the 'much less work' when you're maintaining a route
> that's hundreds of km long, follows dedicated trails or rural roads
> most of the way, but once in a while enters a city and splits because
> of one-way streets. Maintaining separate 'forward' and 'backward'
> relations for the whole thing would be quite annoying.
>

Depends.  I prefer to split to separate forward and backward relations when
the number of members gets to be extremely large or when either or both
ends of a route is not single carriageway, because it gets to be a real
pain in the butt to validate and maintain otherwise.

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

[Tagging] Branched and alternative roujtes

[Kevin Kenny]

(Summary: What do the data *consumers* want to see in the tagging for
route alternatives, circular routes, and routes that begin and end on
dual carriageways?)

On Mon, Aug 19, 2019 at 3:47 AM Sarah Hoffmann  wrote:
> We do happen to have a clear rule for unbroken linear routes: just assemble
> in the obvious way, no matter if sorted or unsorted. We don't have any rule
> for anything more complicated that mappers can follow to get the desired
> effect. We already fail with something as simple as a directed unbroken
> linear routes and circular routes. There is no single recommended way to
> define the start point.

A circular route may not even have a start point.  Hikers doing the
Carnberry Lake 50 can start and end it anywhere and do it clockwise or
anti-clockwise (although there happen to be only a couple of good
places to get on and off the circular route).

> Assuming we don't care what happens to really botched relations, all cases
> except one that I listed initially are covered with one single simple
> instruction to the mapper: sort your route.
>
> What remains are routes which are split/have alternatives/access routes etc.
> Gut feeling tells that roles will solve those cases but I get back to you
> on that once I had a go at implementing it.

If I recall correctly, you're well on the way to handling role=forward
and role=backward splits - I seem to recall that WMT was fairly
graceful about the one or two of those I put in (to repair routes that
were broken altogether - I'm not in the habit of editing cycling
routes otherwise).

For hiking routes, the splits that I have and don't quite know how to
manage are:

- Short diversions. Some of the trails that I've mapped have short
segments for winter and summer routes, or marked alternatives for use
in case of high water, fire-season trail closures, or beaver activitty
(which, I suppose is a special case of high water).

- Access ways. Ordinarily these are marked separately from the main
trail and I just carry them as separate routes. The only case where
I've really wanted to make some sort of association is that the Green
Mountain Club, in addition to the 'end to end' award on the Long Trail
(for hiking the main stem) offers a much more difficult 'side to side'
award for hiking each of the approach trails. I have Absolutely No
Idea how to represent this, if I were to do so.

- Major diversions. For the 'end to end' award on New York's Long
Path, the suburban sections in Orange County are recognized to be a
problem for hikers, and a recognized alternative is to leave the Long
Path in Harriman Park, follow the Appalachian Trail to High Point, New
Jersey, and then the Shawangunk Ridge Trail to rejoin the Long Path in
Otisville.  I'm perfectly fine, though, with simply offering this as
narrative, and having the relations show this as three separate
trails. Hikers have to make their own decisions sometime!

- Trails that are waymarked only in one direction. I do this with
'oneway=yes' on the relation, and order the ways accordingly, but I
did encounter a circular route that seemed to be ambiguous however I
did it. (The trail maintainers rendered this one moot by installing
signs facing the other way.)

The same sort of things seem to infect road routes:

- Routes that begin and end at the interchanges among dual
carriageways, which give no single point that can be indentified as an
endpoint because the geographic endpoints are different in the two
directions. JOSM has a real problem sorting these.

- Multiple-carriageway routes, where there are grade-separated ways
between 'express' and 'local', or between 'auto' and 'hgv' or between
'vehicles with transponders' and 'vehicles paying cash'.  This is an
additional layer of split on top of 'forward' and 'backward' and is
even worse for messing up sorting.

- The same thing can happen on surface streets where there are
numbered routes that are bannered 'ALT, 'BUSINESS', 'TRUCK', etc. For
these, though, I'm perfectly fine with saying that the loops and spurs
are entirely separate routes. The signage is distinct, and people in
the affected areas are used to being directed onto 'US 20 Business' or
whatever.

We have 'forward' and 'backward' pretty much conquered (except for the
dual-carriageway case). WMT already appears to figure it out, (well,
mostly), and JOSM successfully sorts these, even when routes traverse
roundabouts.

I'd like to hear from data consumers in particular what tagging they'd
like to see for

- diversions and alternatives
- routes with different endpoints in the forward/backward directions
- spur routes
- one-way routes that may be circular

[End of technical discussion. Political jeremiad follows. Feel free to ignore.]

With my data consumer hat on, I want to be able to consume the data
describing these situations without having to guess, because computers
are very, very bad at guesswork.

With my mapper hat on (the current one is a faded and stained baseball
cap bearing the logo of a 

Re: [Tagging] Multiple values in isced:level

[Andrew Harvey]

I'll still be using a range with a -. so 0-2 to mean from 0 to 2 inclusive.
I've used it all over my state for schools together with the grades key. To
me it's a lot clearer and simpler than the semicolon or multiple yes/no
values.

On Sat, 17 Aug 2019 at 16:53, Lanxana .  wrote:

> Hi!
>
> so, after reading the different opinions, I understand that I can use the
> semicolon (;) or boolean values (yes/no), and both systems would be
> correct, is it? And, in any case, it should be documented in the wiki.
>
> And I understand too, that it was a war of editions about the use of
> semicolon like a value separator, so my question is now that if the current
> version of the page it's ok or not, because I'd like complete its
> translation into Spanish.
>
> Thanks!
>
>>
>
> 
>  Libre
> de virus. www.avast.com
> 
> <#m_-315500903686677547_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Peter Elderson]

You can't seem to let go of your routing. The routes in OSM represent
routes that are already there. They are sequences of ways to follow in the
order given, not sequences of points to route to.

Ideally, you should not have to create gpx-s from them and you should need
no ordering or routing at all, because they ARE the routes. An app or
gps-device should use them as is, just tell the user what to do next. Since
no app currently does that (future still has to arrive) we resort to
transferring the route to them as tracks, i.e. gpx.
Exporting as a gpx loses the way information. THEN you need rerouting, to
turn them back into a chain of censecutive ways to follow.

The rerouting should return exactly the original route. Of course this only
works when the routing software uses exactly the same map, i.e. knows
exactly all the ways used to create the transport gpx-file.

Some imperfections in various stages can be helped by routing. his means
you get a route over a gap, but you can't be sure it will be the waymarked
OSM-route as it is found on the road. Routing along with planning is a big
help in trip planning, but it should not touch the route itself.

So, it's not all about getting there. It's about doing the way. As hikers
use to say, the way is the goal. Very Tao.

Fr gr Peter Elderson


Op ma 19 aug. 2019 om 14:46 schreef Volker Schmidt :

> Maybe it's the summer heat, or my age, but I still don't get the essential
> step in both Sarah's and Peter's reasoning.
> Let's assume that for hiking and cycling type relations I do have all
> component ways in some, generally agreed, -sequence in the database.
> How do I get this information out of the database and converted nto a
> navigation aid for me as end user?
> I see four basically different options:
> 1) a paper map or a sequence of paper maps
> 2) a road book with turn instructions
> 3) a GPX track to follow on a navigation device
> 4) real time navigation with turn instructions on a navigation device
>
> All four do not need the sorting of the relation members under the
> condition that the routing algorithm gives very strong preference those
> ways that are part of a hiking/biking route relation.
>
> There is theoretically a fifth option:
> I tell my intelligent navigation device "bring me to route XVZ and guide
> me along that route in direction N / S / E / W
> But also in that case the sequence of the ways in the route relation seems
> irrelevant.
>
> I must be missing a crucial point in your reasoning.
>
> Best regards
>
> Volker
>
> On Mon, 19 Aug 2019 at 13:16, Sarah Hoffmann  wrote:
>
>> On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:
>> > On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann  wrote:
>> >
>> > Assuming we don't care what happens to really botched relations, all
>> cases
>> > > except one that I listed initially are covered with one single simple
>> > > instruction to the mapper: sort your route.
>> >
>> > I strongly disagree with this advice, at least as far as cycle routes
>> are
>> > concerned (disclaimer: I have mapped many bicycle route relations)
>> > Even many run-of-the mill "linear" (A-to-B) routes have the problem that
>> > the the precise A-to-B route is different form the B-to-A version of the
>> > "same" route. The reasons are mainly
>> >
>> >- roundabouts
>> >- one-way cycle paths
>> >- oneway streets without bicycle:oneway=no (frequent in
>> agglomerations,
>> >the route A-to-B uses different streets from the B-to-A route)
>>
>> > At the practical level it is impossible to sort these route relations
>> > automatically (in JOSM for example) or manually.
>>
>> I disagree that a) it is not possible to sort such routes and
>> b) that sorting doesn't help.
>>
>> A route that goes like this:
>>
>>   A -> X -> B
>> <- Y <-
>>
>> can be put into the relation in order A, X, Y, B or A, Y, X, B.
>> Or to put it more formally: If you take only ways used to get from
>> A to B, you should get a linear route. And if you take only ways
>> that are used to get from B to A, you still get a linear route.
>>
>> You get a nicely sorted route with one break in there. It's easy
>> to do in any editor where sorting is easy to do and there is no need
>> for nested relations.
>>
>> To convert something like this into a linear geometry, do:
>>
>> 1. Go through relation and reverse all ways as necessary to create a
>>route with minimal gaps.
>> 2. For each way that is tagged forward/backward you can now determine
>>from the direction of the way and its role if it is part of A->B
>>  or B->A.
>> 3. Filter all ways that are two-way or marked A->B, line them up and
>>you have one direction of the route.
>> 4. Rinse and repeat for direction B->A.
>>
>> Or to put it in other words: you can use exactly the same algorithm
>> as for linear routes and just add a bit of oneway detection on top.
>>
>> (I am aware that roundabouts are a special case that should be handled
>> to spare the mapper splitting of 

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[marc marc]

Le 19.08.19 à 15:28, Joseph Eisenberg a écrit :
>>> The tag livestock=*
>>> used 132 times
>>
>> 16% of landuse=farmyard have a animal=* tag.
> 
> I think you misread taginfo.

you're right.

> If we remove the animal=yes tags

in stead of a replay, can you explain
why those valid datas need to be removed ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Joseph Eisenberg]

>> The tag livestock=*
>> used 132 times
>
> 16% of landuse=farmyard have a animal=* tag.

I think you misread taginfo. There are over 800,000 landuse=farmyard
features, and only  1764 have an animal=* tag, so that is 0.22% - the
16% on the right means that 16% of uses of animal are found on
landuse=farmyard.

If we remove the animal=yes tags, there are about 247 uses of animal=*
on landuse=farmyard, landuse=meadow, and landuse=farmland combined, so
it's not huge.

I'd be happy to use either animal=* or livestock=*, myself, but I was
concerned that they wide variety of uses for the animal=* key would be
a problem with getting a proposal approved.

Joseph

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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Joseph Eisenberg]

1) Landuse=meadow has been used for pastures for a very long time, and
the wiki page and definition make it clear that this is fine.
Previously landuse=pasture was proposed, but rejected since it's quite
similar and in many places it can be hard to distinguish hay meadow
from grazing pasture during most of the year.

2) Ok, I agree that probably paddocks / pens / corrals which are bare
soil or another non-vegetated surface should be included in
landuse=farmyard. However, if an area used for horses is
grass-covered, I don't see how most mappers could distinguish it from
a pasture or meadow, so landuse=meadow would work.

On 8/19/19, Paul Allen  wrote:
> On Mon, 19 Aug 2019 at 11:21, Joseph Eisenberg 
> wrote:
>
>>  Landuse=meadow can be tagged with meadow=pasture or
>> =paddock, but again this does not specify the type of animal in the
>> pasture.
>>
>
> There are two problems with that statement.
>
> 1) In normal usage, a pasture is not a category of meadow.  Pasture has
> animals
> grazing directly upon it.  Meadows are where the grass is mown for hay to
> later be fed
> to animals.  But this error in terminology is probably too embedded to fix.
>
> 2) According to the wiki, paddock is definitely not a category of meadow.
> See
> https://wiki.openstreetmap.org/wiki/Riding  which explicitly states that a
> paddock is not a grazing area (but it also admits that in some parts of the
> world usage goes against that statement).   I haven't found anything in the
> wiki to
> suggest that meadow=paddock is documented.
>
> --
> Paul
>

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

[Tagging] Forward/backward routes

[Kevin Kenny]

On Mon, Aug 19, 2019 at 6:34 AM Peter Elderson  wrote:
> Keeping linear main route and alteratives separate is actually quite 
> straightforward and much less work than creating and maintaining routes with 
> roles. Especially when the forward/backward roles do not indicate the 
> direction of travel, as is the case with bicycle routes.

The 'forward' and 'backward' roles are well defined. At least two
editors that I've used understand them. JOSM appears to sort them
correctly. (It does stumble a bit in the special case where a
route=road ends at junction among dual carriageways, because it cannot
find a single endpoint.)  We seem to have this problem mostly solved.

I disagree with the 'much less work' when you're maintaining a route
that's hundreds of km long, follows dedicated trails or rural roads
most of the way, but once in a while enters a city and splits because
of one-way streets. Maintaining separate 'forward' and 'backward'
relations for the whole thing would be quite annoying.

> The point of route relations is that they are already routed, i.e. they 
> prescribe exacty what ways to travel. They are not suggestions for routing. 
> Of course, if there are problems, you can try to make up for that using 
> routng techniques, but you should not turn that around and say hey, I am 
> routing anyway, so forget the data issues. The idea is to record exactly how 
> to travel, so people can travel along the path without rerouting. Just take a 
> way, then the next, etc until the end. These are not suggestions, it's a 
> prescribed route to follow, as seen on the road because it's 
> signposted/waymarked.

Right. Structuring the route in that form also allows software to
produce the skeleton of the route book.  I started with the output of
a PostgreSQL query when I wrote the initial draft of
http://www.nptrail.org/trip-planning/section-descriptions-and-mileages/
(I found several gross errors in the 'official' route book that way:
there was one segment that was shown as 1700 m shorter than its actual
length, for instance).

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[marc marc]

Le 19.08.19 à 13:34, Paul Allen a écrit :
> On Mon, 19 Aug 2019 at 12:16, Warin wrote:
>I like property tags that can be used anywhere appropriate.
> 
> The authors of at least one editor disagree with you there.   
> Unless all of the possible
> values are applicable to all objects for which that property is 
> appropriate, they won't implement a preset for it.

to use Warin's example, this would mean that the tag height is bad, 
because not all height values (including those of hudge building) are 
applicable to street cabinets.
The iD team's choice not to filter the context makes the height list not 
very useful for street cabinet. do we have to change the tag height into 
streetcabinet:height ? and then we also change the tag name to have 
building:name ? or simply to find that this choice of editor is not optimal?
josm's team has (it seems to me) made the choice to take into account 
the context
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Transclusion (was: Merging Tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes)

[Joseph Eisenberg]

> the second way is preferred in this particular case as it's not a stand-alone 
> page.

Agreed. I just did this to make a page for Key:roof:shape, by making a
template called Template:Roof:shape with the content that should be
the same on that page and on the Simple 3D buildings page and then I
added {{Template:Roof:shape}} in the right place on both pages.

Not too hard. But make sure you include some small text at the bottom
with a link on the template like: "This page is a template, editable
[[Template:page|at this link]] - so people will be able to figure out
how to edit it when they see the main pages.

On 8/19/19, Paul Allen  wrote:
> On Mon, 19 Aug 2019 at 12:17, s8evq  wrote:
>
>>
>> Perhaps going off topic, but does somebody know how to do this exactly?
>> I'm trying to add "{{Tile of the wiki page}}", but it doesn't work.
>>
>
> I've not done it, but see this in the transclusion page:
>
>- *{{Stochastic processes}}* will transclude from the page
> Template:Stochastic
>processes 
>- *{{:Stochastic processes}}* will transclude from the page Stochastic
>processes  (an
>article, in the Main namespace)
>- *{{WP:Assume good faith}}* will transclude from the page
> Wikipedia:Assume
>good faith 
>
> So it looks like you need to use {{:Title of the wiki page}} unless it's in
> the Template namespace.
> And since the thing you're trying to transclude is what the wiki calls a
> template (it's not
> a stand-alone page in its own right), you'd probably be better changing the
> name to put it
> in the Template namespace and using the syntax {{Title of the wiki page}}
> to transclude it.
> If the documentation is correct then either way should work, but the second
> way is preferred
> in this particular case as it's not a stand-alone page.
>
> --
> Paul
>

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Volker Schmidt]

Maybe it's the summer heat, or my age, but I still don't get the essential
step in both Sarah's and Peter's reasoning.
Let's assume that for hiking and cycling type relations I do have all
component ways in some, generally agreed, -sequence in the database.
How do I get this information out of the database and converted nto a
navigation aid for me as end user?
I see four basically different options:
1) a paper map or a sequence of paper maps
2) a road book with turn instructions
3) a GPX track to follow on a navigation device
4) real time navigation with turn instructions on a navigation device

All four do not need the sorting of the relation members under the
condition that the routing algorithm gives very strong preference those
ways that are part of a hiking/biking route relation.

There is theoretically a fifth option:
I tell my intelligent navigation device "bring me to route XVZ and guide me
along that route in direction N / S / E / W
But also in that case the sequence of the ways in the route relation seems
irrelevant.

I must be missing a crucial point in your reasoning.

Best regards

Volker

On Mon, 19 Aug 2019 at 13:16, Sarah Hoffmann  wrote:

> On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:
> > On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann  wrote:
> >
> > Assuming we don't care what happens to really botched relations, all
> cases
> > > except one that I listed initially are covered with one single simple
> > > instruction to the mapper: sort your route.
> >
> > I strongly disagree with this advice, at least as far as cycle routes are
> > concerned (disclaimer: I have mapped many bicycle route relations)
> > Even many run-of-the mill "linear" (A-to-B) routes have the problem that
> > the the precise A-to-B route is different form the B-to-A version of the
> > "same" route. The reasons are mainly
> >
> >- roundabouts
> >- one-way cycle paths
> >- oneway streets without bicycle:oneway=no (frequent in
> agglomerations,
> >the route A-to-B uses different streets from the B-to-A route)
>
> > At the practical level it is impossible to sort these route relations
> > automatically (in JOSM for example) or manually.
>
> I disagree that a) it is not possible to sort such routes and
> b) that sorting doesn't help.
>
> A route that goes like this:
>
>   A -> X -> B
> <- Y <-
>
> can be put into the relation in order A, X, Y, B or A, Y, X, B.
> Or to put it more formally: If you take only ways used to get from
> A to B, you should get a linear route. And if you take only ways
> that are used to get from B to A, you still get a linear route.
>
> You get a nicely sorted route with one break in there. It's easy
> to do in any editor where sorting is easy to do and there is no need
> for nested relations.
>
> To convert something like this into a linear geometry, do:
>
> 1. Go through relation and reverse all ways as necessary to create a
>route with minimal gaps.
> 2. For each way that is tagged forward/backward you can now determine
>from the direction of the way and its role if it is part of A->B
>  or B->A.
> 3. Filter all ways that are two-way or marked A->B, line them up and
>you have one direction of the route.
> 4. Rinse and repeat for direction B->A.
>
> Or to put it in other words: you can use exactly the same algorithm
> as for linear routes and just add a bit of oneway detection on top.
>
> (I am aware that roundabouts are a special case that should be handled
> to spare the mapper splitting of roundabouts. But, again, if the route
> is sorted, then detecting this is a piece of cake, even when the
> roundabout is split at inconvenient places.)
>
> > Let me also introduce a further complication in the "sorting" discussion
> > for hiking and cycling route relations.
> > Some mappers like the idea to keep signposts in the same route relation
> as
> > the ways making up the route. This strategy has been adopted in an
> > important collaboration between the Italian Alpine Club (CAI) and OSM (in
> > Italy represented by WIkimedia Italia). Unfortunately the corresponding
> > wiki page  is only available in
> > Italian.
>
> This is not relevant for sorting during processing. Those members are
> stripped
> away first thing. If it bothers you during editing, I have to say that I
> have
> little sympathy as those guideposts don't belong into the relation in the
> first place. Use
> https://wiki.openstreetmap.org/wiki/Relation:destination_sign
> instead.
>
> Sarah
>
> ___
> 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] Transclusion (was: Merging Tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes)

[Paul Allen]

On Mon, 19 Aug 2019 at 12:17, s8evq  wrote:

>
> Perhaps going off topic, but does somebody know how to do this exactly?
> I'm trying to add "{{Tile of the wiki page}}", but it doesn't work.
>

I've not done it, but see this in the transclusion page:

   - *{{Stochastic processes}}* will transclude from the page
Template:Stochastic
   processes 
   - *{{:Stochastic processes}}* will transclude from the page Stochastic
   processes  (an
   article, in the Main namespace)
   - *{{WP:Assume good faith}}* will transclude from the page Wikipedia:Assume
   good faith 

So it looks like you need to use {{:Title of the wiki page}} unless it's in
the Template namespace.
And since the thing you're trying to transclude is what the wiki calls a
template (it's not
a stand-alone page in its own right), you'd probably be better changing the
name to put it
in the Template namespace and using the syntax {{Title of the wiki page}}
to transclude it.
If the documentation is correct then either way should work, but the second
way is preferred
in this particular case as it's not a stand-alone page.

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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Paul Allen]

On Mon, 19 Aug 2019 at 12:16, Warin <61sundow...@gmail.com> wrote:

That is a negative for me, I like property tags that can be used anywhere
> appropriate.
>

The authors of at least one editor disagree with you there.  Unless all of
the possible
values are applicable to all objects for which that property is
appropriate, they won't
implement a preset for it.  If objects of type A get one subset of values
but objects
of type B get a different subset of values then it won't get implemented.
Because
they populate drop-downs from the wiki and/or wikidata.  In this particular
case,
all farm animals might be found in zoos but not all zoo animals will be
found on
farms.  Having a common property tag would lead to a drop-down for farm
animals including pandas, bears, gold eagles, reticulated pythons, etc.
because
it would be populated from the same (hypothetical) wiki(data) page that
covers zoo
and farm animals.

I don't necessarily agree with the thinking of those editors in all the
cases they've
applied it to, but that IS what they think.  And if a tag isn't supported
by popular editors
it won't get used much.  In this case, I wouldn't want to have to wade
through a drop-down
of all zoo animals to add farm animals, so I tend to agree with them.

OSM does not have separate  height tags for buildings, bridges, signs,
> fences etc etc. One tag makes much more sense.
>

A height is a height is a height, whatever it is applied to.  Many zoo
animals are not farm animals.
A height is a numeric value, a list of animals is a list: editors handle
numeric values and lists
with different GUI interfaces to make life easier (type in a number versus
add items in a list).

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Warin]

On 19/08/19 21:14, ael wrote:

On Mon, Aug 19, 2019 at 05:21:22PM +0900, Joseph Eisenberg wrote:

Interesting!

I remembered a problem with "trade=*" - it's already been used almost
5000 times to specify the type of trade goods sold at a shop=trade -
see https://taginfo.openstreetmap.org/keys/trade and
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade

Yes. I invented that tag and have already noted the possible confusion
earlier in this thread.

I have dithered about whether this second usage of "trade" would be
confusing. Just as long as it can be used in a clearly distinct way, and
the documentation clearly notes the other use and indicates how they are
distinguished, I guess it would be OK.



I am not proposing that 'trade' be used in OSM in that way, but if it were then 
there can be problems.
 If necessary then something along the lines of payment=trade;cash;* Long way 
off topic.

I would certainly not use trade=* to indicate what is for sale in shop=* other 
than shop=trade.



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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[ael]

On Mon, Aug 19, 2019 at 08:25:30PM +1000, Warin wrote:
> On 19/08/19 19:12, Mateusz Konieczny wrote:
> > 
> > 
> > 
> > 19 Aug 2019, 10:44 by 61sundow...@gmail.com:
> > 
> > On 19/08/19 18:21, Joseph Eisenberg wrote:
> > 
> > Interesting!
> > 
> > I remembered a problem with "trade=*" - it's already been used
> > almost
> > 5000 times to specify the type of trade goods sold at a
> > shop=trade -
> > see https://taginfo.openstreetmap.org/keys/trade and
> > https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade
> > 
> > 
> > Not a 'good tag' as it can only be used with shop=trade.
> > 
> > Why? It can be added to any shop,
> > not only ones tagged with shop=trade.
> 
> If I saw a shop=car with trade=car I would tend to think I could trade my
> car for another car.

I would think it mistagged. :-)

shop=trade
trade=motor_dealing

is my best, but horrible, invention of a value to indicate a place
probably auctioning cars for the motor trade. But I wouldn't use shop
as the primary tag for such a place.

The point is to indicate the sort of tagging already established for the
trade tag, rather than to suggest anyone do that.

ael


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

Re: [Tagging] Signposts in Roles of route members

[Warin]

On 19/08/19 18:50, Volker Schmidt wrote:


Let me also introduce a further complication in the "sorting" 
discussion for hiking and cycling route relations.
Some mappers like the idea to keep signposts in the same route 
relation as the ways making up the route. This strategy has been 
adopted in an important collaboration between the Italian Alpine Club 
(CAI) and OSM (in Italy represented by WIkimedia Italia). 
Unfortunately the corresponding wiki page 
 is only available in Italian.
I have done some minor work in that direction on one or two cycle 
route relations, where I was involved in placing the signposts and for 
that reason had direct access at the position data.




As these may be in any order???
Then group them together or not. Accept them in a separate relation if 
wanted. And have them with a suitable role that users can ignore or use 
as they like.

The same with any other POI like log books etc.

Those who like sequential order in the routes can then place them all at 
the bottom and deal with the ways as they please.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[ael]

On Mon, Aug 19, 2019 at 11:12:58AM +0200, Mateusz Konieczny wrote:
> 
> 
> 
> 19 Aug 2019, 10:44 by 61sundow...@gmail.com:
> 
> > On 19/08/19 18:21, Joseph Eisenberg wrote:
> >
> >> Interesting!
> >>
> >> I remembered a problem with "trade=*" - it's already been used almost
> >> 5000 times to specify the type of trade goods sold at a shop=trade -
> >> see https://taginfo.openstreetmap.org/keys/trade and
> >> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade
> >>
> >
> > Not a 'good tag' as it can only be used with shop=trade.
> >
> Why? It can be added to any shop,
> not only ones tagged with shop=trade.
> 
> Though I agree "sells" would be a probably
> more clear name.

Again, sells is not equivalent to trade which has a distinct meaning
about to whom it sells (primarily). Not quite the same as wholesale,
but a certain similarity.

ael


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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Paul Allen]

On Mon, 19 Aug 2019 at 11:21, Joseph Eisenberg 
wrote:

>  Landuse=meadow can be tagged with meadow=pasture or
> =paddock, but again this does not specify the type of animal in the
> pasture.
>

There are two problems with that statement.

1) In normal usage, a pasture is not a category of meadow.  Pasture has
animals
grazing directly upon it.  Meadows are where the grass is mown for hay to
later be fed
to animals.  But this error in terminology is probably too embedded to fix.

2) According to the wiki, paddock is definitely not a category of meadow.
See
https://wiki.openstreetmap.org/wiki/Riding  which explicitly states that a
paddock is not a grazing area (but it also admits that in some parts of the
world usage goes against that statement).   I haven't found anything in the
wiki to
suggest that meadow=paddock is documented.

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[ael]

On Mon, Aug 19, 2019 at 06:44:31PM +1000, Warin wrote:
> On 19/08/19 18:21, Joseph Eisenberg wrote:
> > Interesting!
> > 
> > I remembered a problem with "trade=*" - it's already been used almost
> > 5000 times to specify the type of trade goods sold at a shop=trade -
> > see https://taginfo.openstreetmap.org/keys/trade and
> > https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade
> 
> Not a 'good tag' as it can only be used with shop=trade.
> 

Where it has a distinct meaning about *whom* a shop serves, as well
as indicating what is sold. I simplify for brevity here.

So you are overlooking the full semantics of the shop=trade tag.

ael


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

[Tagging] Transclusion (was: Merging Tagging scheme on wiki pages of Hiking, route=hiking, route=foot and Walking routes)

[s8evq]

On Tue, 13 Aug 2019 11:31:05 +0100, Paul Allen  wrote:

> One way of handling this is a link.  Another way of doing it offered by the
> wiki is transclusion.
> See https://en.wikipedia.org/wiki/Wikipedia:Transclusion and
> https://en.wikipedia.org/wiki/Wikipedia:Transclusion/How_Transclusion_Works
> (the first of those two links transcludes the second of those links, just
> so you can see how
> it looks).
> 

Perhaps going off topic, but does somebody know how to do this exactly? I'm 
trying to add "{{Tile of the wiki page}}", but it doesn't work. 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Sarah Hoffmann]

On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:
> On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann  wrote:
> 
> Assuming we don't care what happens to really botched relations, all cases
> > except one that I listed initially are covered with one single simple
> > instruction to the mapper: sort your route.
> 
> I strongly disagree with this advice, at least as far as cycle routes are
> concerned (disclaimer: I have mapped many bicycle route relations)
> Even many run-of-the mill "linear" (A-to-B) routes have the problem that
> the the precise A-to-B route is different form the B-to-A version of the
> "same" route. The reasons are mainly
> 
>- roundabouts
>- one-way cycle paths
>- oneway streets without bicycle:oneway=no (frequent in agglomerations,
>the route A-to-B uses different streets from the B-to-A route)

> At the practical level it is impossible to sort these route relations
> automatically (in JOSM for example) or manually.

I disagree that a) it is not possible to sort such routes and
b) that sorting doesn't help.

A route that goes like this:

  A -> X -> B
<- Y <-

can be put into the relation in order A, X, Y, B or A, Y, X, B.
Or to put it more formally: If you take only ways used to get from
A to B, you should get a linear route. And if you take only ways
that are used to get from B to A, you still get a linear route.

You get a nicely sorted route with one break in there. It's easy
to do in any editor where sorting is easy to do and there is no need
for nested relations.

To convert something like this into a linear geometry, do:

1. Go through relation and reverse all ways as necessary to create a
   route with minimal gaps.
2. For each way that is tagged forward/backward you can now determine
   from the direction of the way and its role if it is part of A->B
 or B->A.
3. Filter all ways that are two-way or marked A->B, line them up and
   you have one direction of the route.
4. Rinse and repeat for direction B->A.

Or to put it in other words: you can use exactly the same algorithm
as for linear routes and just add a bit of oneway detection on top.

(I am aware that roundabouts are a special case that should be handled
to spare the mapper splitting of roundabouts. But, again, if the route
is sorted, then detecting this is a piece of cake, even when the
roundabout is split at inconvenient places.)

> Let me also introduce a further complication in the "sorting" discussion
> for hiking and cycling route relations.
> Some mappers like the idea to keep signposts in the same route relation as
> the ways making up the route. This strategy has been adopted in an
> important collaboration between the Italian Alpine Club (CAI) and OSM (in
> Italy represented by WIkimedia Italia). Unfortunately the corresponding
> wiki page  is only available in
> Italian.

This is not relevant for sorting during processing. Those members are stripped
away first thing. If it bothers you during editing, I have to say that I have
little sympathy as those guideposts don't belong into the relation in the
first place. Use https://wiki.openstreetmap.org/wiki/Relation:destination_sign
instead.

Sarah

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[ael]

On Mon, Aug 19, 2019 at 05:21:22PM +0900, Joseph Eisenberg wrote:
> Interesting!
> 
> I remembered a problem with "trade=*" - it's already been used almost
> 5000 times to specify the type of trade goods sold at a shop=trade -
> see https://taginfo.openstreetmap.org/keys/trade and
> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade

Yes. I invented that tag and have already noted the possible confusion
earlier in this thread.

I have dithered about whether this second usage of "trade" would be
confusing. Just as long as it can be used in a clearly distinct way, and
the documentation clearly notes the other use and indicates how they are
distinguished, I guess it would be OK.

ael


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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Warin]

On 19/08/19 20:17, Joseph Eisenberg wrote:

What is the best tag to specify the livestock animals in a farmyard or meadow?

I checked, and currently a number of farmyards are tagged with
farmyard=*, but most values describe the feature, like
farmyard=feedlot. Landuse=meadow can be tagged with meadow=pasture or
=paddock, but again this does not specify the type of animal in the
pasture.

Some mappers have used animal=* or livestock=* with landuse=farmyard
and landuse=meadow.

The tag animal=* has been 2137 times - but most of the values are
animal=yes (unhelpful!), leaving slightly under 200 uses of animal
types like chicken, cow, cattle, goat, sheep, horse and pig.


What reason is there not to us animal? It already exists as a tag, has some use.

Animal in OSM has low usage for animal facilities, and some use for the actual 
kind of animal.



Unfortunately, the key animal=* has also been used for zoo animals
(see elephant, etc) and some of the values are rare, proposed separate
features like animal=wellness and animal=cemetery.


Ostriches are zoo animals... but I think they were farmed, and may still be?
No reason to reject animal simply because it has use for other animals?



The tag livestock=* is more specific for farming - livestock are
domestic, agricultural animals, and livestock=* has been used 132
times with landuse=farmyard or =meadow, mostly with values cattle,
poultry, horse, pig, and chicken.


Specific to farming, so it cannot be used elsewhere?

That is a negative for me, I like property tags that can be used anywhere 
appropriate.
OSM does not have separate  height tags for buildings, bridges, signs, fences 
etc etc. One tag makes much more sense.



There's also the key produce=, which has been used about 190 times
with the two features, however most values used on these features are
products like meat=, eggs=, milk= and dairy= - only 61 features have
an animal name like goat= or hen= (chicken?), so it appears that most
mappers do not use this tag to specify types of animals raised on
farmland or meadows.


Produce: Describes a feature's agricultural output produced though a natural 
process of growing or breeding.

So the produce key is used for the output, if that is live animals then they 
can be tagged that way.
If the output is milk then produce=milk not produce=cow.

If the output is goats then produce=goats.
 



So it looks like livestock=* is probably the best option.

I'm asking about these landuse=meadow and landuse=farmyard in
particular, because the other agricultural features already have a way
to specify the plant or animal that is grown or raised:


If the animal is grown or raised there and is the output of that feature then 
use the produce key - that is what it is for.

There is use of livestock:goat=yes/some number... and I like it some and can be 
used to indicate the presence of goats.

The output could be milk, meat and/or hides as well as live goats.


* landuse=orchard (that is, the plants or trees in the orchard or
plantation), trees=* is used (also includes shurbs like tea and tall
plants like bananas).
* landuse=aquaculture area, aquaculture=* is used (eg =shrimp, fish, mussels)
* landuse=farmland, crop=* is usually used.


Is there a need to specify the output of  landuse=meadow in some way that is 
separate from all the others?

meadow:output=*

And then yet another key to specify the output for landuse=farmyard?

farmland:output=*
I don't think so. Nor do I like the other examples - yes they have some use, 
but I don't regard them as good tags.

---
There are two things here - the presence of something and the output of 
something.
These are 2 separate features and need separate tags.
But the tags should not be artificially limited, the more universal they are 
the easier for people to learn them, remember them, use them and perhaps render 
them.

The key produce works well as it will work for any output (other than man made 
- ie product).


For the presence of an animal? Livestock limits it to agricultural activities.

animal:goat=yes/number ??? Can be used on anything that has these animals, zoos 
or farms.


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

Re: [Tagging] Livestock=* to specify the livestock animals in a farmyard or meadow?

[marc marc]

Le 19.08.19 à 12:17, Joseph Eisenberg a écrit :
> The tag animal=* has been 2137 times
> animal=yes (unhelpful!)

I wonder why it's useless.
if the contributor does not know if they are cows or calves,
this allows him to enter "there are farm animals there" and any 
application can easily target for improvement (e.g. StreetComplete).
what would be useless is to force the contributor to be an expert in 
biology to inform "there are animals there".
it would be just as useless as trying to remove all the key=yes
that are the very basis of the incremental contribution,
one of power of osm

> The tag livestock=*
> used 132 times

16% of landuse=farmyard have a anima=* tag.
I didn't understand what argument to hope that the
current most used tag would change in favor of a marginal tag.

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Warin]

On 19/08/19 19:12, Mateusz Konieczny wrote:




19 Aug 2019, 10:44 by 61sundow...@gmail.com:

On 19/08/19 18:21, Joseph Eisenberg wrote:

Interesting!

I remembered a problem with "trade=*" - it's already been used
almost
5000 times to specify the type of trade goods sold at a
shop=trade -
see https://taginfo.openstreetmap.org/keys/trade and
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade


Not a 'good tag' as it can only be used with shop=trade.

Why? It can be added to any shop,
not only ones tagged with shop=trade.


If I saw a shop=car with trade=car I would tend to think I could trade 
my car for another car.





Though I agree "sells" would be a probably
more clear name.


___
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] Livestock=* to specify the livestock animals in a farmyard or meadow?

[Joseph Eisenberg]

What is the best tag to specify the livestock animals in a farmyard or meadow?

I checked, and currently a number of farmyards are tagged with
farmyard=*, but most values describe the feature, like
farmyard=feedlot. Landuse=meadow can be tagged with meadow=pasture or
=paddock, but again this does not specify the type of animal in the
pasture.

Some mappers have used animal=* or livestock=* with landuse=farmyard
and landuse=meadow.

The tag animal=* has been 2137 times - but most of the values are
animal=yes (unhelpful!), leaving slightly under 200 uses of animal
types like chicken, cow, cattle, goat, sheep, horse and pig.

Unfortunately, the key animal=* has also been used for zoo animals
(see elephant, etc) and some of the values are rare, proposed separate
features like animal=wellness and animal=cemetery.

The tag livestock=* is more specific for farming - livestock are
domestic, agricultural animals, and livestock=* has been used 132
times with landuse=farmyard or =meadow, mostly with values cattle,
poultry, horse, pig, and chicken.

There's also the key produce=, which has been used about 190 times
with the two features, however most values used on these features are
products like meat=, eggs=, milk= and dairy= - only 61 features have
an animal name like goat= or hen= (chicken?), so it appears that most
mappers do not use this tag to specify types of animals raised on
farmland or meadows.

So it looks like livestock=* is probably the best option.

I'm asking about these landuse=meadow and landuse=farmyard in
particular, because the other agricultural features already have a way
to specify the plant or animal that is grown or raised:
* landuse=orchard (that is, the plants or trees in the orchard or
plantation), trees=* is used (also includes shurbs like tea and tall
plants like bananas).
* landuse=aquaculture area, aquaculture=* is used (eg =shrimp, fish, mussels)
* landuse=farmland, crop=* is usually used.

- Joseph

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Mateusz Konieczny]

19 Aug 2019, 10:44 by 61sundow...@gmail.com:

> On 19/08/19 18:21, Joseph Eisenberg wrote:
>
>> Interesting!
>>
>> I remembered a problem with "trade=*" - it's already been used almost
>> 5000 times to specify the type of trade goods sold at a shop=trade -
>> see https://taginfo.openstreetmap.org/keys/trade and
>> https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade
>>
>
> Not a 'good tag' as it can only be used with shop=trade.
>
Why? It can be added to any shop,
not only ones tagged with shop=trade.

Though I agree "sells" would be a probably
more clear name.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Volker Schmidt]

On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann  wrote:

Assuming we don't care what happens to really botched relations, all cases
> except one that I listed initially are covered with one single simple
> instruction to the mapper: sort your route.
>

I strongly disagree with this advice, at least as far as cycle routes are
concerned (disclaimer: I have mapped many bicycle route relations)
Even many run-of-the mill "linear" (A-to-B) routes have the problem that
the the precise A-to-B route is different form the B-to-A version of the
"same" route. The reasons are mainly

   - roundabouts
   - one-way cycle paths
   - oneway streets without bicycle:oneway=no (frequent in agglomerations,
   the route A-to-B uses different streets from the B-to-A route)

At the practical level it is impossible to sort these route relations
automatically (in JOSM for example) or manually.
The only clean solution for these cases would be separate A-to-B an B-to-A
route relations for the same linear bicycle route.
Apart from the enormous additional work, this does not solve the case of
branched routes, for example.
And I still do not see the benefit of having sorted cycling (an hiking)
relations. I have planned hundreds of cycling tours, which often run along
cycle routes, and have not yet come across a single case, where I would
have needed a sorted list of the ways in the relation. I use rout planners
that visualize cycling routes, and that's it.

Let me also introduce a further complication in the "sorting" discussion
for hiking and cycling route relations.
Some mappers like the idea to keep signposts in the same route relation as
the ways making up the route. This strategy has been adopted in an
important collaboration between the Italian Alpine Club (CAI) and OSM (in
Italy represented by WIkimedia Italia). Unfortunately the corresponding
wiki page  is only available in
Italian.
I have done some minor work in that direction on one or two cycle route
relations, where I was involved in placing the signposts and for that
reason had direct access at the position data.

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Warin]

On 19/08/19 18:21, Joseph Eisenberg wrote:

Interesting!

I remembered a problem with "trade=*" - it's already been used almost
5000 times to specify the type of trade goods sold at a shop=trade -
see https://taginfo.openstreetmap.org/keys/trade and
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade


Not a 'good tag' as it can only be used with shop=trade.

Much better to have a universal shop tag that can be used with any shop.

The word that most people (non OSM) would use is 'sells'.

Some think OSM should use the word 'vending' as that is what is used for 
vending machines.

However I disagree, I would much rather have a word that is in common use 
rather than have a word that few would use in relation to a shop.


I have raised this before ... and got nowhere, so it looks to me like each shop 
will have it's own unique tag to describe what it supplies.
What a confusing mess that will be.
 



On 8/19/19, Martin Koppenhoefer  wrote:


sent from a phone


On 19. Aug 2019, at 02:28, Joseph Eisenberg 
wrote:

But trade= is better than generic business= for the workshop of an
individual tradesperson.


by the time craft was introduced, it should probably have been “trade”, IIRR
the craft tag was invented by Germans and intended for tradespeople,
basically it’s a dictionary accident...
(German: Handwerk)

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




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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Joseph Eisenberg]

Interesting!

I remembered a problem with "trade=*" - it's already been used almost
5000 times to specify the type of trade goods sold at a shop=trade -
see https://taginfo.openstreetmap.org/keys/trade and
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade

On 8/19/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 19. Aug 2019, at 02:28, Joseph Eisenberg 
>> wrote:
>>
>> But trade= is better than generic business= for the workshop of an
>> individual tradesperson.
>
>
> by the time craft was introduced, it should probably have been “trade”, IIRR
> the craft tag was invented by Germans and intended for tradespeople,
> basically it’s a dictionary accident...
> (German: Handwerk)
>
> 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] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Volker Schmidt]

On Sun, 18 Aug 2019 at 18:26, Richard Fairhurst 
wrote:

> I'd fully agree on roles. The use of 'alternate' and 'forward'/'reverse'
> roles for bike route relations dates back to the earliest days of bike
> route
> mapping in OSM and is well established by now.
>
I suppose this is a typo:
It should be 'forward'/'backward' and not  'forward'/'reverse'
(see the wiki page: Cycle Routes
:
"*Relation role*: Cycle routes sometimes have different paths depending on
the direction you are travelling. In this case, ways in the relation should
have a role of *forward* or *backward* as described in
Relation:route#Members
. The direction
is rendered on the cycle map (example
)")

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

Re: [Tagging] Keys to which new values can be added without a proposal: craft=, shop=, building=, office=, sport=?

[Martin Koppenhoefer]

sent from a phone

> On 19. Aug 2019, at 02:28, Joseph Eisenberg  
> wrote:
> 
> But trade= is better than generic business= for the workshop of an individual 
> tradesperson.


by the time craft was introduced, it should probably have been “trade”, IIRR 
the craft tag was invented by Germans and intended for tradespeople, basically 
it’s a dictionary accident...
(German: Handwerk)

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

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Sarah Hoffmann]

On Sun, Aug 18, 2019 at 09:25:01AM -0700, Richard Fairhurst wrote:
> But just as long established in OSM is the principle that - since mappers
> are our most precious resource - we optimise for the mapper, not for ease of
> consumption. Allowing relations to be unsorted is an example of that. If a
> relation represents a linear route, it's a SMOP to put the ways in the right
> order. 

Sure, we are not talking about the 80% linear routes (of which less than a
quarter is unsorted btw, so it doesn't seem to be a too difficult thing to
do for the mapper.) Happy to processed them in any order. 

We are talking about routes which are non-linear by design (split direction,
alternatives, accesses, circular, self-intersecting), broken relations,
unfinished relations, directed routes (think MTB downhill) and truely
botched relations.

> There are two obvious strategies. 1 is: create an empty polyline P with
> endpoints P1 and P2; iterate through the relation members; every time you
> encounter a way with an endpoint P1 or P2, add it to the polyline
> (potentially in reverse order) and remove it from consideration; repeat
> until there are no ways left. This is broadly the approach I've used until
> now.
> 
> 2 is more involved but more fault-tolerant and flexible; create a routing
> graph, then route from the relation's startpoint to its endpoint using a
> very heavy uplift for members of this relation. This is a useful approach
> where the route actually _is_ non-contiguous but you nonetheless want to
> include connecting routes between the sections. (Quite a lot of American
> rail-trails are like this, as are several UK National Cycle Network routes.)
> This is an approach I'm investigating at present.

I have experimented quite extensively with using routing algorithms for the
relation assembly. Even determining a start and endpoint of the relation is
already messy. There are corner cases everywhere. Example: a relation with
exactly two open ends should be an open and shut case, right? Wrong! It might
also be a circular route with two access ways.

Any sorting suggestion that either starts with "Step 1: install a planet-
wide OSRM with a foot profile" or involves a complicate algorithm that makes
a lot of undocumented assumptions about the relations cannot be in the
interest of OSM.

The first hinders the use of our data. You shouldn't need be able to afford a
2000$ server just to assemble a couple of routes.

The second makes life harder for mappers because it becomes non-obvious how
they can fix their stuff when it breaks in their favourite software. And
worse, even if they fix it for one, it might acutally breaks the other software
which is working on different assumptions.

We do happen to have a clear rule for unbroken linear routes: just assemble
in the obvious way, no matter if sorted or unsorted. We don't have any rule
for anything more complicated that mappers can follow to get the desired
effect. We already fail with something as simple as a directed unbroken
linear routes and circular routes. There is no single recommended way to
define the start point.

 
> Approach 1 does of course fail if the relation doesn't represent a single
> linear route. That would, however, still be true if the route was ordered.

With sorted routes, your approach 1 becomes quite a bit simpler: just take
ways in order, adapt direction so that the gaps are minimal. Assemble.

That algorithm gives you reasonable results for the following cases
automatically: linear, broken, unfinished, circular and self-intersecting
routes.

Assuming we don't care what happens to really botched relations, all cases
except one that I listed initially are covered with one single simple
instruction to the mapper: sort your route.
 
What remains are routes which are split/have alternatives/access routes etc.
Gut feeling tells that roles will solve those cases but I get back to you
on that once I had a go at implementing it.

Sarah

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