Re: [Tagging] Unifying large multi-location store chains

[marc marc]

Hello,

It's a good deal to fix spelling variant.
but why keeping the brand in the key name if it's not a name ?
maybe it's only due the fact that some render use the name and doesn't 
fall back to use the brand is the name is unset.
maybe an issue to those render is needed to fix this mistake.

Regards,
Marc

Le 03. 05. 18 à 19:08, Leon Karcher a écrit :
> Hi Marc,
> 
> Yes, I'm aware of the fact that names may differ for some brands, but 
> espacially American companies use the brand's name for all their 
> locations. That's also a reason why I want to review the changed objects 
> manually, because if the name may differ, like [brand name] [city name], 
> I would not change it. The main reason to change the names is because 
> there are a lot of different variants of a name in our database, like 
> "Applebee's", "applebee's", "Applebees" or "Applebee`s". So I'll mainly 
> fix the spelling and apostrophe mistakes ( ' ` ).
> 
> 2018-05-03 18:58 GMT+02:00 marc marc  >:
> 
> Hello,
> 
> Le 03. 05. 18 à 18:34, Leon Karcher a écrit :
> > I thought about unifying large store/restaurant chains
> 
> if X is a brand, it's not a name for every poi of this brand.
> for exemple if several poi have name=Applebees,
> then Applebees is maybe an brand or an operator
> but it is no more the name of each poi
> 
> Regards,
> Marc
> ___
> 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] Mapping generic sheds

[marc marc]

Hello,

Le 04. 05. 18 à 00:06, Warin a écrit :
> building=farm_auxiliary
> farm_auxiliary:architecture=shed/*

this combination makes no sense.
building value is about appearance.
so if the appearance is a shed, then building=shed

 > farm_auxiliary:function=sheeps;cows;horses;*

or building:usage ?
but a cow is not a usage, nor a function.

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

Re: [Tagging] Unifying large multi-location store chains

[Leon Karcher]

Hello Graeme,

Thanks for your feedback. I've never encountered such international
differences. The only one that is close is that there are two different
supermarket chains called "Netto" here in Germany. But I think that it
should be no problem because after a short research on the Internet one can
find such differences very quickly and since I'm updating the brands
country by country / state by state it should be manageable. I could also
add a new column for such information in my table.

Regards,
Leon

Graeme Fitzpatrick  schrieb am Do., 3. Mai 2018,
23:28:

> Hi
>
> I think I can see what you're getting at, but, as always, international
> usage is going to rear it's ugly head!
>
> We have Target & K-mart (not Big K-mart) in Australia, but over here
> Lowe's is a men's wear chain (Lowe's hardware was called Masters, but it
> crashed)
>
> There are also Woolworth's Supermarkets, but they are in no way related to
> the US or UK Woolworth chains.
>
> How do we get around problems like these?
>
>
> Thanks
>
> Graeme
>
> On 4 May 2018 at 04:58, Leon Karcher  wrote:
>
>> > It would, but it would be even better to substitute, or add,
>> > wikidata:brand= at the same time.
>>
>> Yeah, that's also part of my plan. It's already included in my tagging
>> list .
>>
>> 2018-05-03 20:44 GMT+02:00 Andy Mabbett :
>>
>>> On 3 May 2018 at 18:24, Mike H <1jg...@gmail.com> wrote:
>>>
>>> > I'd like to point out that I've seen a lot of chains like these tagged
>>> with
>>> > a wikipedia=* tag for the brand, they should use the brand:wikipedia
>>> tag
>>> > instead. This is a big problem for Nominatim right now, as it ranks
>>> results
>>> > based on wiki tags. So if you are going through these it would be a
>>> great
>>> > time to fix these as well.
>>>
>>> It would, but it would be even better to substitute, or add,
>>> wikidata:brand= at the same time.
>>>
>>> --
>>> Andy Mabbett
>>> @pigsonthewing
>>> http://pigsonthewing.org.uk
>>>
>>> ___
>>> 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] Route members: ordered or not

[Kevin Kenny]

On Thu, May 3, 2018 at 12:42 PM, Volker Schmidt  wrote:

> I will try to explain this in a more systematic way:
>
> Routes belong to either of two categories:
> (A) Those whose members can be sorted into a single ordered sequence
> (B) Those that cannot be sorted into a single ordered sequence of members
> Sorting makes only sense for category (A)
> Routes of type (B) can be subdivided into routes of type (A), each of
> which can be sorted, but the overall route can not be sorted.
>
> There are many routes with loops, spurs, roundabouts, etc. for which it
makes eminent sense to sort the "main stem" of the route - and that don't
turn to hash on Waymarked Trails.

One that I assembled (and now find damaged - I have to hunt down how it
acquired 'Genesee Valley Greenway' and lost 'Erie Canalway Trail'!) is the
Mohawk-Hudson Bikeway.  https://www.openstreetmap.org/relation/306742

I tried to have the ways sorted as much as possible, and to keep the places
where it splits as near contiguous as possible. None of the tools seem to
have any problem with having the divided sections like the pair
https://www.openstreetmap.org/way/43395984  and
https://www.openstreetmap.org/way/5592813 as long as one direction is
chosen as the 'main stem' and left contiguous.

I haven't yet hit this situation with walking trails.  The most complex
situation I've seen so far for them has been high-water, bad-weather, or
beaver bypasses; I map those as separate trails and explain in the
description. That sort of thing isn't uncommon around me. People, for
instance, often walk the circuit of the rim trails in one of my local
nature preserves, and take https://www.openstreetmap.org/way/201998754 only
if the ford is impassable at https://www.openstreetmap.org/way/201998755

The tools are also becoming more tolerant of gaps. I know that I still have
a half-dozen or so gaps to fill in
https://hiking.waymarkedtrails.org/#route?id=919642 but Waymarked Trails is
no longer refusing to show elevation profiles.

Since I use JOSM almost exclusively, I'm happy to re-sort routes when I
come upon mis-sorted ones. It would be good if people learnt to do better,
but I'm not annoyed at all about doing that sort of tidying.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Mapping generic sheds

[Warin]

On 04/05/18 07:44, Rachele Amerini wrote:

Hello everyone,

I'm mapping rural areas of Central Asia after an expedition there.
I've found a lot of sheds, where many animals coexisted (sheeps, cows, 
horses...). I'd like to map them but I'm in doubt about the right tag:
*building=shed* "refers to a simple, single-storey structure that is 
used for storage, hobbies, or as a workshop. They can often be found 
in a back garden, on an allotment, or at site with groundskeeping" 
which is not.

*=stable* refers to horses
*=cowshed* refers to cows
*=sty *refers to pigs

I think would be better in this case to use something more generic 
like *cattleshed, *but this would be a new tag.

Any suggestion about how proceed?



Best fit for the moment is

building=farm_auxiliary

https://wiki.openstreetmap.org/wiki/Tag:building%3Dfarm_auxiliary

You could add some sub tags? Such as

farm_auxiliary:function=sheeps;cows;horses;* farm_auxiliary:architecture=shed/*

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

Re: [Tagging] Slipway vs boat ramp

[Warin]

On 04/05/18 07:11, Graeme Fitzpatrick wrote:

Hi Mike

I agree with you that a slipway is not a boat ramp & vice versa, & 
have wondered the same thing myself when marking them, but don't think 
there are any alternatives?


I guess it's another OSM "one word used worldwide" problem?



Looks like it comes from wkipedias definition. 
https://en.wikipedia.org/wiki/Slipway

That looks to have many inconstancies to my eye.

Note that OSM slipway was never approved by this tagging group.

If it were then probably;

leisure key would be rejected - slipways are used for work not just 
leisure, so man_made would be better.


slipways would be distinguished from boat ramps as they have different 
facilities and may lack car/trailer abilities.


Maybe this needs to be addressed?


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

Re: [Tagging] Route members: ordered or not

[Warin]

I have ordered a few bus, train, cycling and walking routes.

In principle:

Both bus and train routes need to be ordered in version 2 of public transport 
(both stop positions and ways need to be ordered from start to finish).

Cycling and walking routes should be ordered for correct interpretation by data 
users.






On 04/05/18 04:13, James wrote:
bus route relations can get very complexe if they are not ordered. I 
order them to make sure I haven't missed anything


On Thu, May 3, 2018, 11:28 AM Yves, > wrote:


Un-ordered route members make it very hard to detect a broken route.
Best practice :
1. If you edit a route, order it at best and check if you haven't
broken it.
2. If you find an unordered route, order it, check if broken and
try to repair it.

Use for instance http://ra.osmsurround.org/.
Yves

Le 3 mai 2018 17:05:32 GMT+02:00, Michael Andersen > a écrit :

I regularly edit a number of cycle routes (primarily the danish national
cycleroutes) and do my best to sort/order the members (it's helpfull 
when
looking for gaps and other peculiarities in JOSM), but have found that 
it's
often near impossible to make them perfectly sorted.

Consider for examplehttps://www.openstreetmap.org/relation/20828.  
Where's the
end points here?

Also note that inexperienced mappers doing minor edits somewhere along 
a route
cannot be expected to reorder it.

On torsdag den 3. maj 2018 07.38.04 CEST Tod Fitch wrote:

While I’ve mapped a number of trails most of them are not
part of a designated larger route so I am not 100% sure,
but I think hiking routes are much like highway routes:
The ways in the relation should be ordered. Not sure why
you’d need a node in there, especially without an explicit
role. If the route ways are ordered it is obvious where
the end points are. Cheers!

On May 3, 2018, at 5:06 AM, David Marchal
> wrote:
Hello, there. I recently worked a bit on hiking
routes, and noticed that some routes have unordered
members. That's particularly noticeable on
waymarkedtrails.org 
, as it makes the
elevation graph rubbish and useless. I read the
relation:route wiki page, but there is only advice
regarding stops order, and not way members order.
Shouldn't there be a note on this page regarding the
importance of sorting the ways to have a more useful
relation than only spaghettis? By the way, I saw some
hiking relations having a node without explicit role,
seemingly as a start point; is it a generally
accepted, used feature, or only an idiosyncrasy?
Awaiting your answers, Regards.





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

[Tagging] Mapping generic sheds

[Rachele Amerini]

Hello everyone,

I'm mapping rural areas of Central Asia after an expedition there.
I've found a lot of sheds, where many animals coexisted (sheeps, cows,
horses...). I'd like to map them but I'm in doubt about the right tag:
*building=shed* "refers to a simple, single-storey structure that is used
for storage, hobbies, or as a workshop. They can often be found in a back
garden, on an allotment, or at site with groundskeeping" which is not.
*=stable* refers to horses
*=cowshed* refers to cows
*=sty *refers to pigs

I think would be better in this case to use something more generic
like *cattleshed,
*but this would be a new tag.
Any suggestion about how proceed?

Thank you,

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

Re: [Tagging] Unifying large multi-location store chains

[Graeme Fitzpatrick]

Hi

I think I can see what you're getting at, but, as always, international
usage is going to rear it's ugly head!

We have Target & K-mart (not Big K-mart) in Australia, but over here Lowe's
is a men's wear chain (Lowe's hardware was called Masters, but it crashed)

There are also Woolworth's Supermarkets, but they are in no way related to
the US or UK Woolworth chains.

How do we get around problems like these?


Thanks

Graeme

On 4 May 2018 at 04:58, Leon Karcher  wrote:

> > It would, but it would be even better to substitute, or add,
> > wikidata:brand= at the same time.
>
> Yeah, that's also part of my plan. It's already included in my tagging
> list .
>
> 2018-05-03 20:44 GMT+02:00 Andy Mabbett :
>
>> On 3 May 2018 at 18:24, Mike H <1jg...@gmail.com> wrote:
>>
>> > I'd like to point out that I've seen a lot of chains like these tagged
>> with
>> > a wikipedia=* tag for the brand, they should use the brand:wikipedia tag
>> > instead. This is a big problem for Nominatim right now, as it ranks
>> results
>> > based on wiki tags. So if you are going through these it would be a
>> great
>> > time to fix these as well.
>>
>> It would, but it would be even better to substitute, or add,
>> wikidata:brand= at the same time.
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> ___
>> 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] Slipway vs boat ramp

[Graeme Fitzpatrick]

Hi Mike

I agree with you that a slipway is not a boat ramp & vice versa, & have
wondered the same thing myself when marking them, but don't think there are
any alternatives?

I guess it's another OSM "one word used worldwide" problem?

Thanks

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

Re: [Tagging] Slipway vs boat ramp

[Dave F]

Yes. A sub-tag should be used to distinguish. Something like 'rails'?

---

I'm more concerned at the lack of water into which a vessel could be 
launched. Is the reservoir accurate? Does the level fluctuate?


DaveF.


On 03/05/2018 19:16, Malcolm Herring wrote:

On 03/05/2018 17:14, Mike H wrote:

there are two different kinds of slipway


Yes, but both are commonly called "slipway". See 
:https://en.wikipedia.org/wiki/Slipway



___
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] Unifying large multi-location store chains

[Leon Karcher]

> It would, but it would be even better to substitute, or add,
> wikidata:brand= at the same time.

Yeah, that's also part of my plan. It's already included in my tagging list
.

2018-05-03 20:44 GMT+02:00 Andy Mabbett :

> On 3 May 2018 at 18:24, Mike H <1jg...@gmail.com> wrote:
>
> > I'd like to point out that I've seen a lot of chains like these tagged
> with
> > a wikipedia=* tag for the brand, they should use the brand:wikipedia tag
> > instead. This is a big problem for Nominatim right now, as it ranks
> results
> > based on wiki tags. So if you are going through these it would be a great
> > time to fix these as well.
>
> It would, but it would be even better to substitute, or add,
> wikidata:brand= at the same time.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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] Unifying large multi-location store chains

[Andy Mabbett]

On 3 May 2018 at 18:24, Mike H <1jg...@gmail.com> wrote:

> I'd like to point out that I've seen a lot of chains like these tagged with
> a wikipedia=* tag for the brand, they should use the brand:wikipedia tag
> instead. This is a big problem for Nominatim right now, as it ranks results
> based on wiki tags. So if you are going through these it would be a great
> time to fix these as well.

It would, but it would be even better to substitute, or add,
wikidata:brand= at the same time.

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

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

Re: [Tagging] Slipway vs boat ramp

[Malcolm Herring]

On 03/05/2018 17:14, Mike H wrote:

there are two different kinds of slipway


Yes, but both are commonly called "slipway". See 
:https://en.wikipedia.org/wiki/Slipway



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

Re: [Tagging] Route members: ordered or not

[James]

bus route relations can get very complexe if they are not ordered. I order
them to make sure I haven't missed anything

On Thu, May 3, 2018, 11:28 AM Yves,  wrote:

> Un-ordered route members make it very hard to detect a broken route.
> Best practice :
> 1. If you edit a route, order it at best and check if you haven't broken
> it.
> 2. If you find an unordered route, order it, check if broken and try to
> repair it.
>
> Use for instance http://ra.osmsurround.org/.
> Yves
>
> Le 3 mai 2018 17:05:32 GMT+02:00, Michael Andersen  a écrit
> :
>>
>> I regularly edit a number of cycle routes (primarily the danish national
>> cycleroutes) and do my best to sort/order the members (it's helpfull when
>> looking for gaps and other peculiarities in JOSM), but have found that it's
>> often near impossible to make them perfectly sorted.
>>
>> Consider for example https://www.openstreetmap.org/relation/20828. Where's 
>> the
>> end points here?
>>
>> Also note that inexperienced mappers doing minor edits somewhere along a 
>> route
>> cannot be expected to reorder it.
>>
>> On torsdag den 3. maj 2018 07.38.04 CEST Tod Fitch wrote:
>>
>>>  While I’ve mapped a number of trails most of them are not part of a
>>>  designated larger route so I am not 100% sure, but I think hiking routes
>>>  are much like highway routes: The ways in the relation should be ordered.
>>>
>>>  Not sure why you’d need a node in there, especially without an explicit
>>>  role. If the route ways are ordered it is obvious where the end points are.
>>>
>>>  Cheers!
>>>
>>>  On May 3, 2018, at 5:06 AM, David Marchal  wrote:

  Hello, there.

  I recently worked a bit on hiking routes, and noticed that some routes
  have unordered members. That's particularly noticeable on
  waymarkedtrails.org , as it makes the
  elevation graph rubbish and useless. I read the relation:route wiki page,
  but there is only advice regarding stops order, and not way members
  order. Shouldn't there be a note on this page regarding the importance of
  sorting the ways to have a more useful relation than only spaghettis?

  By the way, I saw some hiking relations having a node without explicit
  role, seemingly as a start point; is it a generally accepted, used
  feature, or only an idiosyncrasy?

  Awaiting your answers,

  Regards.
 --

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

>>>
>>
>>
>> --
>>
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
> Yves
> ___
> 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] Route members: ordered or not

[Yves]

@Volker, no need to classify all possibilities, it's certainly endless :-)

I wrote 'order at best' cause of course some cases are tricky.
That being said, the (few) route relations I take care of I take the time to 
reorder them before upload, it's easy in JOSM. All have a beginning and a 
start, most loops and some take the same way twice in opposite direction.
Yves 

Le 3 mai 2018 18:42:38 GMT+02:00, Volker Schmidt  a écrit :
>I will try to explain this in a more systematic way:
>
>Routes belong to either of two categories:
>(A) Those whose members can be sorted into a single ordered sequence
>(B) Those that cannot be sorted into a single ordered sequence of
>members
>Sorting makes only sense for category (A)
>Routes of type (B) can be subdivided into routes of type (A), each of
>which
>can be sorted, but the overall route can not be sorted.
>
>Routes are of type (A) if
>(1) the path from begin to end is identical to the reverse path with 
>all
>members traversed in the reverse order and in the opposite direction
>or
>(2) all members have the role forward
>or
>(3) all members have the role backward
>
>Any route
>(1) that has more than two ends
>or
>(2) that contains any loop (except the case that the entire route is a
>single loop)
>or
>(3) that contains any element with role forword or role backward
>(except
>the cases of all-forward or all-backward)
>or
>(4) that contains node or area elements
>is of type B
>
>I am not sure if I have taken care of all cases - please complete as
>necessary

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

Re: [Tagging] Route members: ordered or not

[Volker Schmidt]

My fault.
Loops (in the sense of self-intersections)  are not a problem. Drop rule
B(2)!
What I had in mind was roundabouts. They are not loops. Thy are special
cases of the rule B(3)

On 3 May 2018 at 19:10, marc marc  wrote:

> "impossible" only due to missing tools to be able to do the job
> and the time it take do it "by hand"
> try to order this one http://www.openstreetmap.org/relation/1744381
> I spent a little time sorting these members, but it's a waste,
> it's deteriorating faster than it's getting better.
>
> Le 03. 05. 18 à 18:49, Colin Smale a écrit :
> > Why does a loop make it impossible to sort the ways? It implies that a
> > section of the route is present twice in the relation, but there is
> > surely no distinction between the first traversal of a way and the
> > second traversal?
> >
> >
> > On 2018-05-03 18:42, Volker Schmidt wrote:
> >
> >> I will try to explain this in a more systematic way:
> >>
> >> Routes belong to either of two categories:
> >> (A) Those whose members can be sorted into a single ordered sequence
> >> (B) Those that cannot be sorted into a single ordered sequence of
> members
> >> Sorting makes only sense for category (A)
> >> Routes of type (B) can be subdivided into routes of type (A), each of
> >> which can be sorted, but the overall route can not be sorted.
> >>
> >> Routes are of type (A) if
> >> (1) the path from begin to end is identical to the reverse path with
> >> all members traversed in the reverse order and in the opposite direction
> >> or
> >> (2) all members have the role forward
> >> or
> >> (3) all members have the role backward
> >>
> >> Any route
> >> (1) that has more than two ends
> >> or
> >> (2) that contains any loop (except the case that the entire route is a
> >> single loop)
> >> or
> >> (3) that contains any element with role forword or role backward
> >> (except the cases of all-forward or all-backward)
> >> or
> >> (4) that contains node or area elements
> >> is of type B
> >>
> >> I am not sure if I have taken care of all cases - please complete as
> >> necessary
> >>
> >>
> >>
> >> ___
> >> 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] Unifying large multi-location store chains

[Mike H]

I'd like to point out that I've seen a lot of chains like these tagged with
a wikipedia=* tag for the brand, they should use the brand:wikipedia tag
instead. This is a big problem for Nominatim right now, as it ranks results
based on wiki tags. So if you are going through these it would be a great
time to fix these as well.

On Thu, May 3, 2018 at 1:09 PM Leon Karcher 
wrote:

> Hi Marc,
>
> Yes, I'm aware of the fact that names may differ for some brands, but
> espacially American companies use the brand's name for all their locations.
> That's also a reason why I want to review the changed objects manually,
> because if the name may differ, like [brand name] [city name], I would not
> change it. The main reason to change the names is because there are a lot
> of different variants of a name in our database, like "Applebee's",
> "applebee's", "Applebees" or "Applebee`s". So I'll mainly fix the spelling
> and apostrophe mistakes ( ' ` ).
>
> 2018-05-03 18:58 GMT+02:00 marc marc :
>
>> Hello,
>>
>> Le 03. 05. 18 à 18:34, Leon Karcher a écrit :
>> > I thought about unifying large store/restaurant chains
>>
>> if X is a brand, it's not a name for every poi of this brand.
>> for exemple if several poi have name=Applebees,
>> then Applebees is maybe an brand or an operator
>> but it is no more the name of each poi
>>
>> Regards,
>> Marc
>> ___
>> 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] Route members: ordered or not

[marc marc]

"impossible" only due to missing tools to be able to do the job
and the time it take do it "by hand"
try to order this one http://www.openstreetmap.org/relation/1744381
I spent a little time sorting these members, but it's a waste,
it's deteriorating faster than it's getting better.

Le 03. 05. 18 à 18:49, Colin Smale a écrit :
> Why does a loop make it impossible to sort the ways? It implies that a 
> section of the route is present twice in the relation, but there is 
> surely no distinction between the first traversal of a way and the 
> second traversal?
> 
> 
> On 2018-05-03 18:42, Volker Schmidt wrote:
> 
>> I will try to explain this in a more systematic way:
>>
>> Routes belong to either of two categories:
>> (A) Those whose members can be sorted into a single ordered sequence
>> (B) Those that cannot be sorted into a single ordered sequence of members
>> Sorting makes only sense for category (A)
>> Routes of type (B) can be subdivided into routes of type (A), each of 
>> which can be sorted, but the overall route can not be sorted.
>>
>> Routes are of type (A) if
>> (1) the path from begin to end is identical to the reverse path with  
>> all members traversed in the reverse order and in the opposite direction
>> or
>> (2) all members have the role forward
>> or
>> (3) all members have the role backward
>>
>> Any route
>> (1) that has more than two ends
>> or
>> (2) that contains any loop (except the case that the entire route is a 
>> single loop)
>> or
>> (3) that contains any element with role forword or role backward 
>> (except the cases of all-forward or all-backward)
>> or
>> (4) that contains node or area elements
>> is of type B
>>
>> I am not sure if I have taken care of all cases - please complete as 
>> necessary
>>
>>
>>
>> ___
>> 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] Unifying large multi-location store chains

[Leon Karcher]

Hi Marc,

Yes, I'm aware of the fact that names may differ for some brands, but
espacially American companies use the brand's name for all their locations.
That's also a reason why I want to review the changed objects manually,
because if the name may differ, like [brand name] [city name], I would not
change it. The main reason to change the names is because there are a lot
of different variants of a name in our database, like "Applebee's",
"applebee's", "Applebees" or "Applebee`s". So I'll mainly fix the spelling
and apostrophe mistakes ( ' ` ).

2018-05-03 18:58 GMT+02:00 marc marc :

> Hello,
>
> Le 03. 05. 18 à 18:34, Leon Karcher a écrit :
> > I thought about unifying large store/restaurant chains
>
> if X is a brand, it's not a name for every poi of this brand.
> for exemple if several poi have name=Applebees,
> then Applebees is maybe an brand or an operator
> but it is no more the name of each poi
>
> Regards,
> Marc
> ___
> 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] Route members: ordered or not

[Volker Schmidt]

@Colin:
You got me there: I implicitly excluded the possibility that a way may be
part of the route more than once.
I assumed this to be a general rule.
If you do not exclude it also the more than-than-two-ends exclusion rule
falls apart.
@Adrian:
What does RA do with routes where the same member appears several times?



On 3 May 2018 at 18:49, Colin Smale  wrote:

> Why does a loop make it impossible to sort the ways? It implies that a
> section of the route is present twice in the relation, but there is surely
> no distinction between the first traversal of a way and the second
> traversal?
>
>
>
> On 2018-05-03 18:42, Volker Schmidt wrote:
>
> I will try to explain this in a more systematic way:
>
> Routes belong to either of two categories:
> (A) Those whose members can be sorted into a single ordered sequence
> (B) Those that cannot be sorted into a single ordered sequence of members
> Sorting makes only sense for category (A)
> Routes of type (B) can be subdivided into routes of type (A), each of
> which can be sorted, but the overall route can not be sorted.
>
> Routes are of type (A) if
> (1) the path from begin to end is identical to the reverse path with  all
> members traversed in the reverse order and in the opposite direction
> or
> (2) all members have the role forward
> or
> (3) all members have the role backward
>
> Any route
> (1) that has more than two ends
> or
> (2) that contains any loop (except the case that the entire route is a
> single loop)
> or
> (3) that contains any element with role forword or role backward (except
> the cases of all-forward or all-backward)
> or
> (4) that contains node or area elements
> is of type B
>
> I am not sure if I have taken care of all cases - please complete as
> necessary
>
>
>
>
> ___
> 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] Unifying large multi-location store chains

[marc marc]

Hello,

Le 03. 05. 18 à 18:34, Leon Karcher a écrit :
> I thought about unifying large store/restaurant chains

if X is a brand, it's not a name for every poi of this brand.
for exemple if several poi have name=Applebees,
then Applebees is maybe an brand or an operator
but it is no more the name of each poi

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

Re: [Tagging] Unifying large multi-location store chains

[Colin Smale]

There was an action a couple of years ago in the Netherlands to unify
the orthography of shop names. It was very successful, after a
consultation.

Here's the link to the discussion on the forum - unfortunately it's all
in Dutch... https://forum.openstreetmap.org/viewtopic.php?id=33909 

The originator of the project was Matthijs Melissen, who make wiki pages
for the mechanical edit process that ensued:
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Math1985_mechanical


Colin 

On 2018-05-03 18:34, Leon Karcher wrote:

> Hello, 
> 
> I thought about unifying large store/restaurant chains with several locations 
> for many times now. There are some tags that are applicable to all locations 
> of a specific brand like brand=*, amenity=*/shop=*, cuisine=* for restaurants 
> and for some also name=*. Espacially name=* and brand=* are important to find 
> and filter POI. 
> 
> To have an overview I created a list in the wiki [1] which includes 
> applicable tags of some brands, but it's still under construction and only 
> shows the ones that I know. So feel free to help. 
> 
> I already did a small unification for "Applebee's" locations in Ohio (see 
> this changeset [2]). To do so I filtered out name=Applebee's and 
> name=Applebees via Overpass and reviewed the changes manually. Even though I 
> did the changes manually, this is sort of a mechanical edit, which is the 
> reason for me to ask on this mailing list on your opinion about such changes. 
> And also: What do you think of having such a list of brands? 
> 
> Hope to hear some opinions, 
> Leon/doktorpixel14 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 

Links:
--
[1] https://wiki.openstreetmap.org/wiki/User:Doktorpixel14/Brands
[2] https://www.openstreetmap.org/changeset/58652839___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route members: ordered or not

[Colin Smale]

Why does a loop make it impossible to sort the ways? It implies that a
section of the route is present twice in the relation, but there is
surely no distinction between the first traversal of a way and the
second traversal?

On 2018-05-03 18:42, Volker Schmidt wrote:

> I will try to explain this in a more systematic way:
> 
> Routes belong to either of two categories: (A) Those whose members can be 
> sorted into a single ordered sequence (B) Those that cannot be sorted into a 
> single ordered sequence of members Sorting makes only sense for category (A) 
> Routes of type (B) can be subdivided into routes of type (A), each of which 
> can be sorted, but the overall route can not be sorted.
> 
> Routes are of type (A) if 
> (1) the path from begin to end is identical to the reverse path with  all 
> members traversed in the reverse order and in the opposite direction 
> or 
> (2) all members have the role forward 
> or 
> (3) all members have the role backward
> 
> Any route 
> (1) that has more than two ends 
> or 
> (2) that contains any loop (except the case that the entire route is a single 
> loop) 
> or 
> (3) that contains any element with role forword or role backward (except the 
> cases of all-forward or all-backward) 
> or
> (4) that contains node or area elements 
> is of type B
> 
> I am not sure if I have taken care of all cases - please complete as 
> necessary 
> 
> ___
> 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] Route members: ordered or not

[Volker Schmidt]

I will try to explain this in a more systematic way:

Routes belong to either of two categories:
(A) Those whose members can be sorted into a single ordered sequence
(B) Those that cannot be sorted into a single ordered sequence of members
Sorting makes only sense for category (A)
Routes of type (B) can be subdivided into routes of type (A), each of which
can be sorted, but the overall route can not be sorted.

Routes are of type (A) if
(1) the path from begin to end is identical to the reverse path with  all
members traversed in the reverse order and in the opposite direction
or
(2) all members have the role forward
or
(3) all members have the role backward

Any route
(1) that has more than two ends
or
(2) that contains any loop (except the case that the entire route is a
single loop)
or
(3) that contains any element with role forword or role backward (except
the cases of all-forward or all-backward)
or
(4) that contains node or area elements
is of type B

I am not sure if I have taken care of all cases - please complete as
necessary
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Unifying large multi-location store chains

[Leon Karcher]

Hello,

I thought about unifying large store/restaurant chains with several
locations for many times now. There are some tags that are applicable to
all locations of a specific brand like brand=*, amenity=*/shop=*, cuisine=*
for restaurants and for some also name=*. Espacially name=* and brand=* are
important to find and filter POI.

To have an overview I created a list in the wiki
 which
includes applicable tags of some brands, but it's still under construction
and only shows the ones that I know. So feel free to help.

I already did a small unification for "Applebee's" locations in Ohio (see this
changeset ). To do so I
filtered out name=Applebee's and name=Applebees via Overpass and reviewed
the changes manually. Even though I did the changes manually, this is sort
of a mechanical edit, which is the reason for me to ask on this mailing
list on your opinion about such changes. And also: What do you think of
having such a list of brands?

Hope to hear some opinions,
Leon/doktorpixel14
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route members: ordered or not

[Colin Smale]

Good idea to re-order the ways within a route relation, but please,
don't reverse the ways to make them join up nicely head-to-tail! The
direction of ways is used for so many things that this could cause
untold collateral damage.

This might be obvious to many mappers, but it is definitely something
that well-meaning inexperienced mappers need to understand. 

Colin 

On 2018-05-03 17:26, Yves wrote:

> Un-ordered route members make it very hard to detect a broken route.
> Best practice :
> 1. If you edit a route, order it at best and check if you haven't broken it.
> 2. If you find an unordered route, order it, check if broken and try to 
> repair it.
> 
> Use for instance http://ra.osmsurround.org/.
> Yves 
> 
> Le 3 mai 2018 17:05:32 GMT+02:00, Michael Andersen  a écrit : 
> 
> I regularly edit a number of cycle routes (primarily the danish national 
> cycleroutes) and do my best to sort/order the members (it's helpfull when 
> looking for gaps and other peculiarities in JOSM), but have found that it's 
> often near impossible to make them perfectly sorted.
> 
> Consider for example https://www.openstreetmap.org/relation/20828. Where's 
> the 
> end points here? 
> 
> Also note that inexperienced mappers doing minor edits somewhere along a 
> route 
> cannot be expected to reorder it. 
> 
> On torsdag den 3. maj 2018 07.38.04 CEST Tod Fitch wrote:
> While I've mapped a number of trails most of them are not part of a
> designated larger route so I am not 100% sure, but I think hiking routes
> are much like highway routes: The ways in the relation should be ordered.
> 
> Not sure why you'd need a node in there, especially without an explicit
> role. If the route ways are ordered it is obvious where the end points are.
> 
> Cheers!
> 
> On May 3, 2018, at 5:06 AM, David Marchal  wrote:
> 
> Hello, there.
> 
> I recently worked a bit on hiking routes, and noticed that some routes
> have unordered members. That's particularly noticeable on
> waymarkedtrails.org , as it makes the
> elevation graph rubbish and useless. I read the relation:route wiki page,
> but there is only advice regarding stops order, and not way members
> order. Shouldn't there be a note on this page regarding the importance of
> sorting the ways to have a more useful relation than only spaghettis?
> 
> By the way, I saw some hiking relations having a node without explicit
> role, seemingly as a start point; is it a generally accepted, used
> feature, or only an idiosyncrasy?
> 
> Awaiting your answers,
> 
> Regards.
> 
> -
> 
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
> 

-

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

Yves
___
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] Slipway vs boat ramp

[Mike H]

Oops, I forgot to include the changeset discussion. Here it is,
https://www.openstreetmap.org/changeset/58388640#map=17/31.39739/-94.52454


On Thu, May 3, 2018 at 12:16 PM Mike H <1jg...@gmail.com> wrote:

> The user Tex Shotcaller made me realize that there are two different kinds
> of slipway. There is the traditional slipway where you have a track to
> slide the boat down, and then there are boat ramps where you drive a
> trailer into the water and float the boat off the trailer. Both of these
> are very different feature, but they are tagged the same way as
> leisure=slipway.
>
> I think there is a better way to tag these so that it is known what is
> being described. I'm not really sure what the best way to do this is, and
> so I'm asking here for ideas.
>
> Thanks,
>
> Jgon6
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Slipway vs boat ramp

[Mike H]

The user Tex Shotcaller made me realize that there are two different kinds
of slipway. There is the traditional slipway where you have a track to
slide the boat down, and then there are boat ramps where you drive a
trailer into the water and float the boat off the trailer. Both of these
are very different feature, but they are tagged the same way as
leisure=slipway.

I think there is a better way to tag these so that it is known what is
being described. I'm not really sure what the best way to do this is, and
so I'm asking here for ideas.

Thanks,

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

Re: [Tagging] Route members: ordered or not

[Yves]

Un-ordered route members make it very hard to detect a broken route.
Best practice :
1. If you edit a route, order it at best and check if you haven't broken it.
2. If you find an unordered route, order it, check if broken and try to repair 
it.

Use for instance http://ra.osmsurround.org/.
Yves 

Le 3 mai 2018 17:05:32 GMT+02:00, Michael Andersen  a écrit :
>I regularly edit a number of cycle routes (primarily the danish
>national 
>cycleroutes) and do my best to sort/order the members (it's helpfull
>when 
>looking for gaps and other peculiarities in JOSM), but have found that
>it's 
>often near impossible to make them perfectly sorted.
>
>Consider for example https://www.openstreetmap.org/relation/20828.
>Where's the 
>end points here? 
>
>Also note that inexperienced mappers doing minor edits somewhere along
>a route 
>cannot be expected to reorder it. 
>
>On torsdag den 3. maj 2018 07.38.04 CEST Tod Fitch wrote:
>> While I’ve mapped a number of trails most of them are not part of a
>> designated larger route so I am not 100% sure, but I think hiking
>routes
>> are much like highway routes: The ways in the relation should be
>ordered.
>> 
>> Not sure why you’d need a node in there, especially without an
>explicit
>> role. If the route ways are ordered it is obvious where the end
>points are.
>> 
>> Cheers!
>> 
>> > On May 3, 2018, at 5:06 AM, David Marchal  wrote:
>> > 
>> > Hello, there.
>> > 
>> > I recently worked a bit on hiking routes, and noticed that some
>routes
>> > have unordered members. That's particularly noticeable on
>> > waymarkedtrails.org , as it makes the
>> > elevation graph rubbish and useless. I read the relation:route wiki
>page,
>> > but there is only advice regarding stops order, and not way members
>> > order. Shouldn't there be a note on this page regarding the
>importance of
>> > sorting the ways to have a more useful relation than only
>spaghettis?
>> > 
>> > By the way, I saw some hiking relations having a node without
>explicit
>> > role, seemingly as a start point; is it a generally accepted, used
>> > feature, or only an idiosyncrasy?
>> > 
>> > Awaiting your answers,
>> > 
>> > Regards.
>> > ___
>> > Tagging mailing list
>> > Tagging@openstreetmap.org 
>> > https://lists.openstreetmap.org/listinfo/tagging
>> > 
>
>
>
>___
>Tagging mailing list
>Tagging@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] Route members: ordered or not

[Michael Andersen]

I regularly edit a number of cycle routes (primarily the danish national 
cycleroutes) and do my best to sort/order the members (it's helpfull when 
looking for gaps and other peculiarities in JOSM), but have found that it's 
often near impossible to make them perfectly sorted.

Consider for example https://www.openstreetmap.org/relation/20828. Where's the 
end points here? 

Also note that inexperienced mappers doing minor edits somewhere along a route 
cannot be expected to reorder it. 

On torsdag den 3. maj 2018 07.38.04 CEST Tod Fitch wrote:
> While I’ve mapped a number of trails most of them are not part of a
> designated larger route so I am not 100% sure, but I think hiking routes
> are much like highway routes: The ways in the relation should be ordered.
> 
> Not sure why you’d need a node in there, especially without an explicit
> role. If the route ways are ordered it is obvious where the end points are.
> 
> Cheers!
> 
> > On May 3, 2018, at 5:06 AM, David Marchal  wrote:
> > 
> > Hello, there.
> > 
> > I recently worked a bit on hiking routes, and noticed that some routes
> > have unordered members. That's particularly noticeable on
> > waymarkedtrails.org , as it makes the
> > elevation graph rubbish and useless. I read the relation:route wiki page,
> > but there is only advice regarding stops order, and not way members
> > order. Shouldn't there be a note on this page regarding the importance of
> > sorting the ways to have a more useful relation than only spaghettis?
> > 
> > By the way, I saw some hiking relations having a node without explicit
> > role, seemingly as a start point; is it a generally accepted, used
> > feature, or only an idiosyncrasy?
> > 
> > Awaiting your answers,
> > 
> > Regards.
> > ___
> > 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] Route members: ordered or not

[Andy Townsend]

On 03/05/2018 13:06, David Marchal wrote:


I recently worked a bit on hiking routes, and noticed that some routes 
have unordered members.




I wouldn't expect them to be ordered, to be honest - it'd be dependent 
on every OSM editor ordering the members (in some way) on save.


It's also tricky with some relations where there are braids.

Best Regards,

Andy

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

Re: [Tagging] Route members: ordered or not

[Tod Fitch]

While I’ve mapped a number of trails most of them are not part of a designated 
larger route so I am not 100% sure, but I think hiking routes are much like 
highway routes: The ways in the relation should be ordered.

Not sure why you’d need a node in there, especially without an explicit role. 
If the route ways are ordered it is obvious where the end points are.

Cheers!

> On May 3, 2018, at 5:06 AM, David Marchal  wrote:
> 
> Hello, there.
> 
> I recently worked a bit on hiking routes, and noticed that some routes have 
> unordered members. That's particularly noticeable on waymarkedtrails.org 
> , as it makes the elevation graph rubbish and 
> useless. I read the relation:route wiki page, but there is only advice 
> regarding stops order, and not way members order. Shouldn't there be a note 
> on this page regarding the importance of sorting the ways to have a more 
> useful relation than only spaghettis?
> 
> By the way, I saw some hiking relations having a node without explicit role, 
> seemingly as a start point; is it a generally accepted, used feature, or only 
> an idiosyncrasy?
> 
> Awaiting your answers,
> 
> Regards.
> ___
> 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] Route members: ordered or not

[David Marchal]

Hello, there.


I recently worked a bit on hiking routes, and noticed that some routes have 
unordered members. That's particularly noticeable on waymarkedtrails.org, as it 
makes the elevation graph rubbish and useless. I read the relation:route wiki 
page, but there is only advice regarding stops order, and not way members 
order. Shouldn't there be a note on this page regarding the importance of 
sorting the ways to have a more useful relation than only spaghettis?


By the way, I saw some hiking relations having a node without explicit role, 
seemingly as a start point; is it a generally accepted, used feature, or only 
an idiosyncrasy?


Awaiting your answers,


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