Re: [Tagging] New tag proposal: 'addr=milestone'

[Martin Koppenhoefer]

Am Mi., 20. Nov. 2019 um 06:56 Uhr schrieb Jorge Aguirre <
jorge.agui...@kaart.com>:

> I had been out for the last few weeks and had left this proposal in
> standby.  I am back now and have revised and updated the original proposal
> and included some images as examples, so hopefully it is all more clear now
> and better explained, so everyone understands just how important this new
> tag is for the address system used in Latin America and several other
> countries in the world.
>
> I would appreciate all to read the newer version found here:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Addr:milestone
>


I welcome the idea to use specific address tags for distance based
addressing information, but I do not believe "milestone" is a good tag for
this, at least not here in my area, because it seems to require to refer to
a specific milestone, while people use distance based information also when
there aren't milestones, or there aren't milestones for the specific
distance.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Jorge Aguirre]

I had been out for the last few weeks and had left this proposal in standby.  I 
am back now and have revised and updated the original proposal and included 
some images as examples, so hopefully it is all more clear now and better 
explained, so everyone understands just how important this new tag is for the 
address system used in Latin America and several other countries in the world.

I would appreciate all to read the newer version found here: 
https://wiki.openstreetmap.org/wiki/Proposed_features/Addr:milestone


Thank you all.


Jorge

> On Oct 10, 2019, at 1:17 AM, tagging-requ...@openstreetmap.org wrote:
> 
> Send Tagging mailing list submissions to
>   tagging@openstreetmap.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.openstreetmap.org/listinfo/tagging
> or, via email, send a message with subject or body 'help' to
>   tagging-requ...@openstreetmap.org
> 
> You can reach the person managing the list at
>   tagging-ow...@openstreetmap.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tagging digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: New tag proposal: 'add=milestone' (Agustin Rissoli)
>   2. Divided highways, and not so divided highways, one way or two
>  (Frederik Ramm)
>   3. Re: Divided highways, and not so divided highways, one way or
>  two (Mateusz Konieczny)
>   4. Re: Divided highways, and not so divided highways, one way or
>  two (Dave Swarthout)
> 
> 
> --
> 
> Message: 1
> Date: Thu, 10 Oct 2019 00:26:07 -0300
> From: Agustin Rissoli 
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] New tag proposal: 'add=milestone'
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
>> 
>> this implies road markers must be present, right? Isn’t this mainly about 
>> the distance from some zero point, even in the absence of road distance 
>> markers?
>> 
>> No, many times there are no marks, for me it does not have to be implicit
> 
> I would not invent myself these numbers, I would copy them from
>> the gate where they have been put by the owner or municipality (regardless
>> of actual distances or even if they are in slight contradiction with nearby
>> road markers, as I have seen occur). If nothing is signposted, I would
>> rather map the road markers nearby (if any).
>> 
>> agree, many times these addresses are calculated by the same owner
> 
> Somebody remarked earlier in the thread that there are places in the US
>> where the distances are
>> used as house numbers.  I think the duck test applies.  It doesn't matter
>> if a house number is
>> assigned sequentially, or is based upon distance from some specified point,
>> or is based upon
>> some mad king throwing darts at a map: if it looks like a house number, is
>> treated like a house
>> number, and appears on the house/gate/whatever as a house number, then it's
>> a house number.
>> House numbers don't have to be sequential or monotonic, I can think of a
>> couple of roads in my
>> town where the house numbers are counter-intuitive.  So it doesn't matter
>> if those house numbers
>> were assigned based on a distance along a road, and that subsequent road
>> remodelling has
>> resulted in them all being inaccurate without a milepost equation: if it
>> quacks like a house
>> number then it's a house number.
>> 
>> If they're not house numbers marked somewhere on the property, and if there
>> are sometimes
>> (as the OP has stated) missing markers, and if road remodelling has
>> rendered the distances
>> incorrect, then what good is addr:road_marker in those particular
>> circumstances?
>> 
>> It appears addr:road_marker is only really applicable where all of the
>> following apply:
>> 
>> 1: The number is not marked on the property (otherwise it's a house number,
>> however
>> derived).
>> 
>> 2) Road remodelling has not significantly changed the distances between the
>> property
>> and the two nearest road markers (so you know it's somewhere between marker
>> X and
>> marker Y).
>> 
>> 3) Road markers have not been recalibrated following extensive road
>> remodelling.
>> 
>> --
>> Paul
>> 
>> In Argentina it is common to have addresses with house number, street
> name, and also address per km., For example Avenida San Martín 5440, Ruta 9
> km 60.5
> It is often used on routes that cross small towns and suburban areas. I
> also s

Re: [Tagging] New tag proposal: 'add=milestone'

[Agustin Rissoli]

>
> this implies road markers must be present, right? Isn’t this mainly about the 
> distance from some zero point, even in the absence of road distance markers?
>
> No, many times there are no marks, for me it does not have to be implicit

I would not invent myself these numbers, I would copy them from
> the gate where they have been put by the owner or municipality (regardless
> of actual distances or even if they are in slight contradiction with nearby
> road markers, as I have seen occur). If nothing is signposted, I would
> rather map the road markers nearby (if any).
>
> agree, many times these addresses are calculated by the same owner

Somebody remarked earlier in the thread that there are places in the US
> where the distances are
> used as house numbers.  I think the duck test applies.  It doesn't matter
> if a house number is
> assigned sequentially, or is based upon distance from some specified point,
> or is based upon
> some mad king throwing darts at a map: if it looks like a house number, is
> treated like a house
> number, and appears on the house/gate/whatever as a house number, then it's
> a house number.
> House numbers don't have to be sequential or monotonic, I can think of a
> couple of roads in my
> town where the house numbers are counter-intuitive.  So it doesn't matter
> if those house numbers
> were assigned based on a distance along a road, and that subsequent road
> remodelling has
> resulted in them all being inaccurate without a milepost equation: if it
> quacks like a house
> number then it's a house number.
>
> If they're not house numbers marked somewhere on the property, and if there
> are sometimes
> (as the OP has stated) missing markers, and if road remodelling has
> rendered the distances
> incorrect, then what good is addr:road_marker in those particular
> circumstances?
>
> It appears addr:road_marker is only really applicable where all of the
> following apply:
>
> 1: The number is not marked on the property (otherwise it's a house number,
> however
> derived).
>
> 2) Road remodelling has not significantly changed the distances between the
> property
> and the two nearest road markers (so you know it's somewhere between marker
> X and
> marker Y).
>
> 3) Road markers have not been recalibrated following extensive road
> remodelling.
>
> --
> Paul
>
> In Argentina it is common to have addresses with house number, street
name, and also address per km., For example Avenida San Martín 5440, Ruta 9
km 60.5
It is often used on routes that cross small towns and suburban areas. I
also saw the same thing in Uruguay, where I got to see addresses with
street name, lot number, km number of the route without house number (the
number of km belongs to the route and not the street numbering )

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

Re: [Tagging] New tag proposal: 'add=milestone'

[François Lacombe]

Hi,

I just want to bring to your attention the work currently done to propose
marker=* key with existing value marker=stone.
https://wiki.openstreetmap.org/wiki/Proposed_features/Utility_markers_proposal#Tagging

This is mainly intended for utility networks but may be useful for highways
milestones.
It starts with the deprecation of pipeline=marker to use marker as a more
general placeholder for marker definition in combination with utility=*

Do you find highway=**_marker desirable?
Will you consider things like highway=marker + marker=plate + ref=*... ?

This is an opportunity to make things to converge towards a common
framework for many kind of markers here

All the best

François

Le mer. 9 oct. 2019 à 22:03, Martin Koppenhoefer  a
écrit :

> Am Mi., 9. Okt. 2019 um 15:11 Uhr schrieb Paul Allen :
>
>> ...some mad king throwing darts at a map: if it looks like a house
>> number, is treated like a house
>> number, and appears on the house/gate/whatever as a house number, then
>> it's a house number.
>> House numbers don't have to be sequential or monotonic, I can think of a
>> couple of roads in my
>> town where the house numbers are counter-intuitive.  So it doesn't matter
>> if those house numbers
>> were assigned based on a distance along a road, and that subsequent road
>> remodelling has
>> resulted in them all being inaccurate without a milepost equation: if it
>> quacks like a house
>> number then it's a house number.
>>
>
>
> there is some sense in understanding the system (if there is), e.g. if not
> all numbers are recorded it allows you to estimate where the one you are
> looking for might be, how far it possibly is etc.. This is a typical use
> case: you have an address and are looking for it on the ground.
>
>
>
>> If they're not house numbers marked somewhere on the property, and if
>> there are sometimes
>> (as the OP has stated) missing markers, and if road remodelling has
>> rendered the distances
>> incorrect, then what good is addr:road_marker in those particular
>> circumstances?
>>
>> It appears addr:road_marker is only really applicable where all of the
>> following apply:
>>
>> 1: The number is not marked on the property (otherwise it's a house
>> number, however
>> derived).
>>
>
>
> there could be 2 numbers, a distance based on and a recently assigned,
> actual housenumber.
> You could also be interested in comparing an official register to the OSM
> data, e.g. to find missing spots, check for completeness etc.
>
>
>
>>
>>
>> 3) Road markers have not been recalibrated following extensive road
>> remodelling.
>>
>>
>
> good luck with this. In regions with lacking housenumbers I wouldn't put
> too much confidence in the road markers...
>
> 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] New tag proposal: 'add=milestone'

[Martin Koppenhoefer]

Am Mi., 9. Okt. 2019 um 15:11 Uhr schrieb Paul Allen :

> ...some mad king throwing darts at a map: if it looks like a house number,
> is treated like a house
> number, and appears on the house/gate/whatever as a house number, then
> it's a house number.
> House numbers don't have to be sequential or monotonic, I can think of a
> couple of roads in my
> town where the house numbers are counter-intuitive.  So it doesn't matter
> if those house numbers
> were assigned based on a distance along a road, and that subsequent road
> remodelling has
> resulted in them all being inaccurate without a milepost equation: if it
> quacks like a house
> number then it's a house number.
>


there is some sense in understanding the system (if there is), e.g. if not
all numbers are recorded it allows you to estimate where the one you are
looking for might be, how far it possibly is etc.. This is a typical use
case: you have an address and are looking for it on the ground.



> If they're not house numbers marked somewhere on the property, and if
> there are sometimes
> (as the OP has stated) missing markers, and if road remodelling has
> rendered the distances
> incorrect, then what good is addr:road_marker in those particular
> circumstances?
>
> It appears addr:road_marker is only really applicable where all of the
> following apply:
>
> 1: The number is not marked on the property (otherwise it's a house
> number, however
> derived).
>


there could be 2 numbers, a distance based on and a recently assigned,
actual housenumber.
You could also be interested in comparing an official register to the OSM
data, e.g. to find missing spots, check for completeness etc.



>
>
> 3) Road markers have not been recalibrated following extensive road
> remodelling.
>
>

good luck with this. In regions with lacking housenumbers I wouldn't put
too much confidence in the road markers...

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

Re: [Tagging] New tag proposal: 'add=milestone'

[Paul Allen]

On Wed, 9 Oct 2019 at 09:39, Martin Koppenhoefer 
wrote:

>
> Funfact, in Rome there is one road, "Via Trionfale",
> https://en.wikipedia.org/wiki/Via_Trionfale which has housenumbers
> (contrary to the rest of the city) that indicate the distance from the
> capitol hill measured at the axxis of the street, so the highest
> housenumber reaches 14500.
> Example: https://www.openstreetmap.org/node/3393609605
>

Somebody remarked earlier in the thread that there are places in the US
where the distances are
used as house numbers.  I think the duck test applies.  It doesn't matter
if a house number is
assigned sequentially, or is based upon distance from some specified point,
or is based upon
some mad king throwing darts at a map: if it looks like a house number, is
treated like a house
number, and appears on the house/gate/whatever as a house number, then it's
a house number.
House numbers don't have to be sequential or monotonic, I can think of a
couple of roads in my
town where the house numbers are counter-intuitive.  So it doesn't matter
if those house numbers
were assigned based on a distance along a road, and that subsequent road
remodelling has
resulted in them all being inaccurate without a milepost equation: if it
quacks like a house
number then it's a house number.

If they're not house numbers marked somewhere on the property, and if there
are sometimes
(as the OP has stated) missing markers, and if road remodelling has
rendered the distances
incorrect, then what good is addr:road_marker in those particular
circumstances?

It appears addr:road_marker is only really applicable where all of the
following apply:

1: The number is not marked on the property (otherwise it's a house number,
however
derived).

2) Road remodelling has not significantly changed the distances between the
property
and the two nearest road markers (so you know it's somewhere between marker
X and
marker Y).

3) Road markers have not been recalibrated following extensive road
remodelling.

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

Re: [Tagging] New tag proposal: 'add=milestone'

[Martin Koppenhoefer]

Am Mi., 9. Okt. 2019 um 09:00 Uhr schrieb Colin Smale :

> I would just like to make a point about mileages/kilometrages. Physically
> marked positions (e.g. a milestone or a sign with an address) can not be
> replaced by, or derived from, the actual distance along the road.
>
> These distances are not constant. Roads get diverted, split, recombined
> etc which can change the distance AND the zero-point. If you follow the
> hectometer (100m) markers on motorways in the Netherlands you will see
> loads of discontinuities caused by changes through the years. Occasionally,
> where a change makes a road longer, a whole segment is "recalibrated" to
> avoid duplicate markers or gaps. Where a road is made shorter, a "jump" in
> the values is used.
>


Agreed, I was proposing a term, not referring to the way it is surveyed /
determined. I would not invent myself these numbers, I would copy them from
the gate where they have been put by the owner or municipality (regardless
of actual distances or even if they are in slight contradiction with nearby
road markers, as I have seen occur). If nothing is signposted, I would
rather map the road markers nearby (if any).

Funfact, in Rome there is one road, "Via Trionfale",
https://en.wikipedia.org/wiki/Via_Trionfale which has housenumbers
(contrary to the rest of the city) that indicate the distance from the
capitol hill measured at the axxis of the street, so the highest
housenumber reaches 14500.
Example: https://www.openstreetmap.org/node/3393609605

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

Re: [Tagging] New tag proposal: 'add=milestone'

[Colin Smale]

I would just like to make a point about mileages/kilometrages.
Physically marked positions (e.g. a milestone or a sign with an address)
can not be replaced by, or derived from, the actual distance along the
road. 

These distances are not constant. Roads get diverted, split, recombined
etc which can change the distance AND the zero-point. If you follow the
hectometer (100m) markers on motorways in the Netherlands you will see
loads of discontinuities caused by changes through the years.
Occasionally, where a change makes a road longer, a whole segment is
"recalibrated" to avoid duplicate markers or gaps. Where a road is made
shorter, a "jump" in the values is used. 

On 2019-10-09 08:43, Martin Koppenhoefer wrote:

> sent from a phone
> 
>> On 9. Oct 2019, at 03:24, Jorge Aguirre  wrote:
>> 
>> After reading all the responses and comments made regarding this issue I 
>> would like to modify the originally proposed tag name ('addr=milestone') to 
>> a new proposal to name it:  'addr=road_marker' - which works for both the 
>> kilometer and mile highway location markers.
> 
> this implies road markers must be present, right? Isn't this mainly about the 
> distance from some zero point, even in the absence of road distance markers? 
> It could be addr:kilometrage to refer specifically to this distance, but I 
> agree on the other hand this would have a reference to kilometers in the tag, 
> which isn't universally working well on a global level 
> 
> 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] New tag proposal: 'add=milestone'

[Martin Koppenhoefer]

sent from a phone

> On 9. Oct 2019, at 03:24, Jorge Aguirre  wrote:
> 
> After reading all the responses and comments made regarding this issue I 
> would like to modify the originally proposed tag name ('addr=milestone’) to a 
> new proposal to name it:  ‘addr=road_marker’ - which works for both the 
> kilometer and mile highway location markers.


this implies road markers must be present, right? Isn’t this mainly about the 
distance from some zero point, even in the absence of road distance markers? 
It could be addr:kilometrage to refer specifically to this distance, but I 
agree on the other hand this would have a reference to kilometers in the tag, 
which isn’t universally working well on a global level 

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

Re: [Tagging] New tag proposal: 'add=milestone'

[Jorge Aguirre]

After reading all the responses and comments made regarding this issue I would 
like to modify the originally proposed tag name ('addr=milestone’) to a new 
proposal to name it:  ‘addr=road_marker’ - which works for both the kilometer 
and mile highway location markers.

The next step will be to propose the change of the existent 'highway:milestone’ 
to a more ‘universal’ and comprehensive name - 'highway=road_marker’  this way 
completing the relation between the address and the actual marker on the road 
and is understandable for all, while not making any reference to the measuring 
units - which in most parts of the world is actually the kilometer - as can be 
seen on the image on this link:

https://en.wikipedia.org/wiki/International_System_of_Units#/media/File:Metric_system_adoption_map.svg


Regards,

Jorge

> On Oct 3, 2019, at 5:00 AM, tagging-requ...@openstreetmap.org wrote:
> 
> Send Tagging mailing list submissions to
>   tagging@openstreetmap.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.openstreetmap.org/listinfo/tagging
> or, via email, send a message with subject or body 'help' to
>   tagging-requ...@openstreetmap.org
> 
> You can reach the person managing the list at
>   tagging-ow...@openstreetmap.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tagging digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: New tag proposal: 'addr=milestone' (Agustin Rissoli)
>   2. Re: New tag proposal: 'addr=milestone' (Joseph Eisenberg)
>   3. Re: New tag proposal: 'addr=milestone' (Martin Koppenhoefer)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 2 Oct 2019 17:54:35 -0300
> From: Agustin Rissoli 
> To: tagging@openstreetmap.org
> Subject: Re: [Tagging] New tag proposal: 'addr=milestone'
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> I think we can add a clarification, which says that these directions are
> not exact, but usually based on the approximate position with respect to a
> milestone on the road.
> 
> Agustín
> 
> 
> Date: Wed, 2 Oct 2019 19:25:29 +0100
> From: Paul Allen 
> To: "Tag discussion, strategy and related tools"
>
> Subject: Re: [Tagging] New tag proposal: 'addr=milestone'
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
> 
> On Wed, 2 Oct 2019 at 18:59, Agustin Rissoli  wrote:
> 
>> 
>>>> Perfect! That is exactly what happens in real life when someone is
>> seeking an address based on location markers once the precision of the
>> distance used in addresses is low.
>> 
>> This description should be in the eventual wiki
>> 
> 
> You think?  That's a description of how somebody navigates to an address
> like that
> without a map.  Keep an eye on the odometer.  Look for "milestones."  If
> you see
> a "milestone" numbered higher than in the address, you've gone too far.
> But it's
> not how you navigate if you have a map.  Especially if the map display is
> capable
> of using GPS to show your current position.
> 
>> 
>> 
> -- 
> Paul
> -- next part --
> An HTML attachment was scrubbed...
> URL: <http://lists.openstreetmap.org/pipermail/tagging/
> attachments/20191002/a1dcde44/attachment-0001.html>
> 
> --
> Subject: Digest Footer
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 
> 
> --
> 
> End of Tagging Digest, Vol 121, Issue 9
> ***
> ---------- next part --
> An HTML attachment was scrubbed...
> URL: 
> <http://lists.openstreetmap.org/pipermail/tagging/attachments/20191002/ff07dd68/attachment-0001.html>
> 
> --
> 
> Message: 2
> Date: Thu, 3 Oct 2019 07:08:31 +0900
> From: Joseph Eisenberg 
> To: "Tag discussion, strategy and related tools"
>   
> Subject: Re: [Tagging] New tag proposal: 'addr=milestone'
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Re: “On standard [OpenStreetMap-]carto (and probably most others)
> highway=milestone doesn't render.”
> 
> There is an open issue and some rendering ideas from a year back:
> 
> https://github.com/gravitystorm/openstreetmap-carto/issues/3605
> 
> If anyone wants to help get historic=milestone rendered, they can help
> design a good rendering or submit a PR on 

Re: [Tagging] New tag proposal: 'addr=milestone'

[Martin Koppenhoefer]

Am Mi., 2. Okt. 2019 um 22:55 Uhr schrieb Agustin Rissoli <
aguztin...@gmail.com>:

> I think we can add a clarification, which says that these directions are
> not exact, but usually based on the approximate position with respect to a
> milestone on the road.
>


Actually I have 2 different cases in my area:
1. approximate positions that aren't signposted (but you can get them for
example on the website of the feature, from business registers or from the
address on the receipt when you buy something), they go like "Motorway A23
X - Y km 35.700"
2. Indications of exact meters, like 3455, which may or may not be accurate
with respect to official road markers / milestones, but are kind of an
"agreed upon" address, and people post them as if they were regular
(consecutive) housenumbers (they might also be official housenumbers, I am
not sure about this, and it may depend on the municipality).

Example for the second case:
https://www.google.com/maps/@42.1655384,12.3482096,3a,16.1y,57.78h,85.37t/data=!3m6!1e1!3m4!1sSFb1ZNg34WWYGflbjVgFNg!2e0!7i16384!8i8192

Examples for the first case:
https://www.myautogrill.it/it/portal/myautogrill_list

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Joseph Eisenberg]

Re: “On standard [OpenStreetMap-]carto (and probably most others)
highway=milestone doesn't render.”

There is an open issue and some rendering ideas from a year back:

https://github.com/gravitystorm/openstreetmap-carto/issues/3605

If anyone wants to help get historic=milestone rendered, they can help
design a good rendering or submit a PR on github: it’s an all-volunteer,
open-source project.

-Joseph

On Wed, Oct 2, 2019 at 9:55 PM Paul Allen  wrote:

> On Wed, 2 Oct 2019 at 13:26, santamariense  wrote:
>
>>
>> > that you should not use the term "milestone" but something like
>> > addr:distance or
>> > addr:road_marker  or whatever, because there are no milestones
>>
>> addr:road_marker seems to be appropriate
>
>
> Or something with similar meaning.  Places that use this addressing system
> presumably
> have some name for that part of an address.  So that if you tell somebody
> what road your house
> is on and they want to know more precisely, they ask you what your X is.
> I doubt they ask you
> what your milestone is.  Same for forms where there are boxes for road,
> town, county (maybe)
> post/zip code (maybe), there is presumably a box labelled X, and I doubt
> that label is
> "milestone."
>
> Also of consideration is that if somebody uses the query tool of standard
> carto to get
> the address of a house, will addr:milestone make any sense to them or will
> it just
> confuse them?
>
> I did some more digging (which the original poster should have done, if
> not at first then at
> least after several people suggested "milestone" was inappropriate).  What
> OSM calls
> highway=milestone is a "highway location marker."  Which is used in
> addresses as a
> "linear referencing system."  So addr:highway_location or
> addr:linear_reference or
> addr:road_marker or something similar based upon what people who live in
> areas with that
> kind of address call that part of the address.
>
> but highway=milestone, even
>> misleading its name can be, is already in use and I think it would be
>> better to keep a relation between their names.
>>
>
> On standard carto (and probably most others) highway=milestone doesn't
> render.  And those
> milestones-that-aren't-really-milestones are probably only rarely mapped,
> whereas
> addresses frequently are mapped.  In any  case, as people have pointed
> out, the highway
> location markers either side of the address may not be present.  So the
> only reason for keeping
> a relation between the names is if we're going to map every marker and use
> an OSM relation to
> bind addresses to markers (which will still fail if there's no marker
> present).
>
> --
> Paul
>
> ___
> 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] New tag proposal: 'addr=milestone'

[Agustin Rissoli]

I think we can add a clarification, which says that these directions are
not exact, but usually based on the approximate position with respect to a
milestone on the road.

Agustín


Date: Wed, 2 Oct 2019 19:25:29 +0100
From: Paul Allen 
To: "Tag discussion, strategy and related tools"

Subject: Re: [Tagging] New tag proposal: 'addr=milestone'
Message-ID:

Content-Type: text/plain; charset="utf-8"

On Wed, 2 Oct 2019 at 18:59, Agustin Rissoli  wrote:

>
> > > Perfect! That is exactly what happens in real life when someone is
> seeking an address based on location markers once the precision of the
> distance used in addresses is low.
>
> This description should be in the eventual wiki
>

You think?  That's a description of how somebody navigates to an address
like that
without a map.  Keep an eye on the odometer.  Look for "milestones."  If
you see
a "milestone" numbered higher than in the address, you've gone too far.
But it's
not how you navigate if you have a map.  Especially if the map display is
capable
of using GPS to show your current position.

>
>
-- 
Paul
-- next part --
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/
attachments/20191002/a1dcde44/attachment-0001.html>

--
Subject: Digest Footer

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


--

End of Tagging Digest, Vol 121, Issue 9
***
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag proposal: 'addr=milestone'

[Paul Allen]

On Wed, 2 Oct 2019 at 18:59, Agustin Rissoli  wrote:

>
> > > Perfect! That is exactly what happens in real life when someone is
> seeking an address based on location markers once the precision of the
> distance used in addresses is low.
>
> This description should be in the eventual wiki
>

You think?  That's a description of how somebody navigates to an address
like that
without a map.  Keep an eye on the odometer.  Look for "milestones."  If
you see
a "milestone" numbered higher than in the address, you've gone too far.
But it's
not how you navigate if you have a map.  Especially if the map display is
capable
of using GPS to show your current position.

>
> @Paul Allen keep calm
>

I am calm.  Very calm.  It's possible to strongly disagree with somebody
whilst remaining
perfectly calm.

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

[Tagging] New tag proposal: 'addr=milestone'

[Agustin Rissoli]

Jorge,
I think we should change the name of the tag to addr:road_marker or
another, as many are not interested in milestone not being the correct
name, nor should they care that it does not match highway=milestone, it is
a lesser evil.

> Think of the ‘milestone’ as a point of reference. The ‘milestone’ only
provides a general idea > of how far or how close you are to a destination.
Once you go beyond and reach the next
> ‘milestone’ you may need to turn around and go slower to find what you
are seeking.

> > Perfect! That is exactly what happens in real life when someone is
seeking an address based on location markers once the precision of the
distance used in addresses is low.

This description should be in the eventual wiki

@Paul Allen keep calm


Saludos, Agustín.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag proposal: 'addr=milestone'

[Paul Allen]

On Wed, 2 Oct 2019 at 14:57, Martin Koppenhoefer 
wrote:

this is also a milestone in OSM: historic=milestone
> https://wiki.openstreetmap.org/wiki/Tag:historic%3Dmilestone
>

There aren't that many milestones (made of stone, marked in miles) around
here but
all of those I'm aware of are historic and many of them are classified as
listed buildings.
I think it's been many decades since any actual milestone was placed and
that they're
probably all historic.  Our road signage is still in miles whilst yours
isn't, but a milestone
is only really usable by walkers, not by car drivers, so they're not very
useful these days.

Here's a summary page (in German):
> https://de.wikipedia.org/wiki/Distanzstein


> I am not sure we would want main tags for all these, would we?
>

A main tag, for each, no.  A collective tag with sub-tags, maybe.  Or just
a collective tag
that fits better than highway=milestone.

I agree a tag like "distance marker" would have been more neutral, but I
> have never had problems with calling something a "milestone" which actually
> uses kilometers as units, or which wasn't made out of stone.
>

When all you have is a hammer, everything looks like a nail.  You and I
live in countries which
has milestones made of stone and marked in miles, even if they serve no
purpose these days.
In a country which has only ever had kilometre markings on metal signs
and/or road markings,
highway=milestone is like trying to rotate a nut with a hammer, and
addr:milestone is like
trying to solder delicate electronics with a hammer.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Martin Koppenhoefer]

Am Mi., 2. Okt. 2019 um 13:33 Uhr schrieb Paul Allen :

> NO.  NO, NO, NO, NO, NO.  That's how we end up with bad tags.  Like
> highway=milestone.
> Outside of OSM, a milestone is a stone with a distance in miles marked
> upon it.  Outside
> of OSM, this is a milestone:
> https://en.wikipedia.org/wiki/File:Milestone@Penrhosgarnedd_2.jpg
>
It's made of stone and the distances are in miles.
>


this is also a milestone in OSM: historic=milestone
https://wiki.openstreetmap.org/wiki/Tag:historic%3Dmilestone

FWIW, in German these things are called "Meilenstein" (=milestone),
although we do not measure in miles (anymore) and regardless of the units
used on the stone. While there are also "Kilometerstein" (kilometerstone)
and "Stationszeichen" (road marker), and "Meilensäule" (mile-column), and
"Stundenstein", "Distanzsäule" (distance column), "Ganzmeilenobelisk"
(whole mile obelisk), etc.etc.. The typical milestones in Germany can be
further classified as Roman Milestone, Prussian Milestone, Berlin
Milestone, Milestones of the various smaller German (ex-)countries

Here's a summary page (in German):
https://de.wikipedia.org/wiki/Distanzstein

I am not sure we would want main tags for all these, would we?
I agree a tag like "distance marker" would have been more neutral, but I
have never had problems with calling something a "milestone" which actually
uses kilometers as units, or which wasn't made out of stone.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Paul Allen]

On Wed, 2 Oct 2019 at 13:26, santamariense  wrote:

>
> > that you should not use the term "milestone" but something like
> > addr:distance or
> > addr:road_marker  or whatever, because there are no milestones
>
> addr:road_marker seems to be appropriated


Or something with similar meaning.  Places that use this addressing system
presumably
have some name for that part of an address.  So that if you tell somebody
what road your house
is on and they want to know more precisely, they ask you what your X is.  I
doubt they ask you
what your milestone is.  Same for forms where there are boxes for road,
town, county (maybe)
post/zip code (maybe), there is presumably a box labelled X, and I doubt
that label is
"milestone."

Also of consideration is that if somebody uses the query tool of standard
carto to get
the address of a house, will addr:milestone make any sense to them or will
it just
confuse them?

I did some more digging (which the original poster should have done, if not
at first then at
least after several people suggested "milestone" was inappropriate).  What
OSM calls
highway=milestone is a "highway location marker."  Which is used in
addresses as a
"linear referencing system."  So addr:highway_location or
addr:linear_reference or
addr:road_marker or something similar based upon what people who live in
areas with that
kind of address call that part of the address.

but highway=milestone, even
> misleading its name can be, is already in use and I think it would be
> better to keep a relation between their names.
>

On standard carto (and probably most others) highway=milestone doesn't
render.  And those
milestones-that-aren't-really-milestones are probably only rarely mapped,
whereas
addresses frequently are mapped.  In any  case, as people have pointed out,
the highway
location markers either side of the address may not be present.  So the
only reason for keeping
a relation between the names is if we're going to map every marker and use
an OSM relation to
bind addresses to markers (which will still fail if there's no marker
present).

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[santamariense]

> which coincidentally can match (or not match) the distance

Well noted. The reference to a location marker used in an address
rarely gives the exact distance. It is an approximated value with low
precision, unlike the tag distance=* that is used with
highway=milestone that is supposed to mark the exact distance of a
road where distance=* is based on an engineering project, usually with
high precision.


> Think of the ‘milestone’ as a point of reference. The ‘milestone’ only 
> provides a general idea > of how far or how close you are to a destination. 
> Once you go beyond and reach the next
> ‘milestone’ you may need to turn around and go slower to find what you are 
> seeking.

Perfect! That is exactly what happens in real life when someone is
seeking an address based on location markers once the precision of the
distance used in addresses is low.


> Wow, that makes them really useful.  It's a road marker that's not made of
> stone, shows kilometres
> rather than miles, and the number shown is wrong.  So you want to call it a
> milestone.

The number shown is not exactly wrong. It is approximated and its
precision can vary up to ~1km because most of the values used in
addresses do not show precision in meters. Examples of common values
are Km 256, Km 7.5; and never Km 97.47247764, for example.


> that you should not use the term "milestone" but something like
> addr:distance or
> addr:road_marker  or whatever, because there are no milestones

addr:road_marker seems to be appropriated but highway=milestone, even
misleading its name can be, is already in use and I think it would be
better to keep a relation between their names.


-/-/-/-/-/-/-/-/

I do not mind what name would be used as a tag to map this address
information as long as a tag is created to map it. However, I
understand the need to create a well-named tag that would be
applicable worldwide and I hope this does not stop the creation of
such tag whatever your name.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Paul Allen]

On Wed, 2 Oct 2019 at 03:40, Jorge Aguirre  wrote:

>
> In all fairness, I think it should not be as difficult to find a good way
> to facilitate entering a complementary address tag, one that is very much
> needed in our part of the world - one which applies to and needed in most
> of the world actually.
>

I haven't seen anybody say such a tag is not needed.  I've seen people in
various parts of the
world say a similar situation applies there.  What people are saying is
that your proposed tag
is not well named.

>
> > I think we're close to hitting the record for how misleading a tag name
> can
> > be.
>
> Getting into analyzing the true definition of an actual ‘milestone’ - in
> this case - is needless.


One of the main reasons this list exists is to try to discourage tags with
misleading names,
because they end up being misunderstood and misused.  The true definition
of milestone,
as it is understood outside of OSM, is VERY relevant: people new to OSM
will interpret
the names of tags according to their common meanings, not OSM "this doesn't
have
the same meaning as in ordinary life" meanings.


> I feel we cannot all become ‘purist’ and try to find the proper
> definitions for terms to be then used as ’universal tags' applicable to the
> entire world.


And yet we must, else we end up with tags that are misunderstood and
misused.  And tags
that mean one thing in Brazil, a different thing in France, and something
else in China.  OSM
is a map of the world, not a collection of country maps.

The best we can all do is adapt and apply what we have at hand.


NO.  NO, NO, NO, NO, NO.  That's how we end up with bad tags.  Like
highway=milestone.
Outside of OSM, a milestone is a stone with a distance in miles marked upon
it.  Outside
of OSM, this is a milestone:
https://en.wikipedia.org/wiki/File:Milestone@Penrhosgarnedd_2.jpg
It's made of stone and the distances are in miles.  That's why it's called
a milestone and not
a kilometremarker.  But when somebody wanted to tag road markings that were
in kilometres
and not on stones, he or she decided to "adapt and apply what we have at
hand."


> So, things may not be perfect, but they are good enough to use and and
> apply to many different
>
cases.


MIsapplying tags to different cases leads to confusion and errors.  If the
cases are different
they need different tags.  If the same tag really does apply to both then
they aren't different.
Your definition of "good enough" is a lot less stringent than mine.


> Most people have come to appreciate the simplicity of using and how
> versatile the OSM project
>
really is.
>

Except that OSM isn't as simple as it could be because people keep coming
up with bad
names for tags.  OSM is stuck with landuse=grass when it should be
landcover=grass
because of a past bad decision.  Because of that past bad decision, people
invent other
landuse tags that should be landcover tags based upon the fact that
landuse=grass exists.
And somebody else insists on addr:milestone because of a past bad decision
about
highway=milestone.

The existent tag known as ‘highway:milestone’ and it’s definition found
> here:


If your friend put his hand in the fire, would you do the same thing?
highway=milestone is
a badly-named tag.


> [https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmilestone] has been
> previously created, accepted and is currently being used by the entire OSM
> community. The point I have based this ‘addr:milestone’ proposal on, is
> what the general concept of the ‘:milestone' stands for: a location marker
> - which may be made of any material including ’stone’ - and which it’s
> primary function is to indicate a location on a road - which coincidentally
> can match (or not match) the distance - in kilometers (or miles), as these
> are internationally accepted measuring units mostly useful for these longer
> distances. But the ‘milestone’ as such, is still only a reference point on
> any given road.
>

Then propose addr:road_marker if, as you say later, that component of the
address is only loosely
based upon the position along the road and the marker is not at the true
distance it claims to
represent.

>
> The ‘milestone’ markers usually indicate a location - and not necessarily
> the distance - but in either case are used as reference points.
>

Wow, that makes them really useful.  It's a road marker that's not made of
stone, shows kilometres
rather than miles, and the number shown is wrong.  So you want to call it a
milestone.

>
> Unfortunately, DISTANCE could require being too exact in a very subjective
> and too ambiguous ‘milestone’ related addressing system.  The concept of
> either of these is not and cannot be an exact science. Most any known
> address system I’ve heard of is just based on proximity to other known
> references.


Are you deliberately being obtuse?  It has already been stated here that a
house between
marker 9 and marker 10 might have "9.5" in the address because it is a
distance of
APPROXIMATELY 

Re: [Tagging] New tag proposal: 'addr=milestone'

[Jorge Aguirre]

Greetings my fellow OSM colleagues. 

In all fairness, I think it should not be as difficult to find a good way to 
facilitate entering a complementary address tag, one that is very much needed 
in our part of the world - one which applies to and needed in most of the world 
actually. 

This has been an interesting experience for me, to find so many different 
opinions and points of view for something that for others is so obviously 
needed. Who could have guessed this? There are barely just over 5,700,000 
contributors, as of some time today, helping with this project.

So hopefully I will help clarify with these following comments:

> I think we're close to hitting the record for how misleading a tag name can
> be.


Getting into analyzing the true definition of an actual ‘milestone’ - in this 
case - is needless. I feel we cannot all become ‘purist’ and try to find the 
proper definitions for terms to be then used as ’universal tags' applicable to 
the entire world. The best we can all do is adapt and apply what we have at 
hand. So, things may not be perfect, but they are good enough to use and and 
apply to many different cases. Most people have come to appreciate the 
simplicity of using and how versatile the OSM project really is. 

> This is a proposal for a tag addr:milestone to allow us to specify a
> distance in kilometres
> (not miles), of a house (not a milestone) and the nearest milestone isn't a
> stone but a sign.


The existent tag known as ‘highway:milestone’ and it’s definition found here: 
[https://wiki.openstreetmap.org/wiki/Tag:highway%3Dmilestone] has been 
previously created, accepted and is currently being used by the entire OSM 
community. The point I have based this ‘addr:milestone’ proposal on, is what 
the general concept of the ‘:milestone' stands for: a location marker - which 
may be made of any material including ’stone’ - and which it’s primary function 
is to indicate a location on a road - which coincidentally can match (or not 
match) the distance - in kilometers (or miles), as these are internationally 
accepted measuring units mostly useful for these longer distances. But the 
‘milestone’ as such, is still only a reference point on any given road.

>  A distance
> from where, exactly?  A highway has two ends, and there may be a milestone 
> 9km from each end.

The ‘milestone’ markers usually indicate a location - and not necessarily the 
distance - but in either case are used as reference points.

As we are now using Guatemala for this example, there is actually a point 
called ‘Kilómetro Cero’, a plaque on a cement sidewalk, located at the entrance 
of the National Palace of Culture from which all major highways in Guatemala 
begin. Even the 30,000 kilometer-long Pan-American Highway which runs from 
Alaska to the Southern tip of Argentina (with the exception of the Darién Gap 
in Panama) runs through Guatemala West to East has ‘milestones’ or markers 
indicating the distance from the National Palace in downtown Guatemala City 
towards the Mexican border on the West side, and towards the El Salvador border 
on the East side.  The kilometer markers (aka 'milestones') have one thing in 
common - whether you are moving to or from any of the borders - the further you 
are from Guatemala City, the higher the kilometer reading is and viceversa. 
There is a starting point and there is a finishing point.

-


> For the same purpose of this proposal I used addr:milestone:distance=*
> but I agree with Paul that there's no need for the milestone in the
> middle.Real distance or not is the same for distance=* when used with
> highway=milestone.


Unfortunately, DISTANCE could require being too exact in a very subjective and 
too ambiguous ‘milestone’ related addressing system.  The concept of either of 
these is not and cannot be an exact science. Most any known address system I’ve 
heard of is just based on proximity to other known references. If otherwise, 
any address would require the use of longer and more complex numbers such as 
‘Km. 9.47836235’ for us to be able to find an address to get to our hotel - 
provided we know where to start measuring that distance. Fortunately we are 
usually capable of 'filling in the blanks' enough to find our destinations 
through this planet. 

A tag name using the term ‘milestone’ to locate an address - as opposed to 
using a tag with the term ‘distance’ - in which that distance is measured from 
a ‘milestone’ (which may or may not be even there) makes no sense to me. As 
occurs in real life, these distances are not even close to being exact on any 
addressing system - they are only approximate distances from a reference point 
and usually expressed in round one (with any luck 2) decimal numbers - give or 
take a few hundred meters…

Re: [Tagging] New tag proposal: 'addr=milestone'

[Joseph Eisenberg]

Yes, we call them "mile markers" in my part of Oregon/Northern
California too, like "the wildfire started on the north side of
Highway 96 at mile marker 23" - but houses and other structures have
addresses with house numbers.

On 10/2/19, Dave Swarthout  wrote:
> The "milestone" value is a misnomer in most modern situations. Here in
> Thailand, many roads have actual mile markers, er kilometer markers, but
> they are not made of stone. They are painted concrete. In the U.S. there
> are very few of these if any. When I'm tagging mile markers in the U.S., I
> include a tag description=Metal flag
>
> One of the things I love to map in Thailand are km=0 milestones which
> denote the beginning of a numbered route. To date, I've added approximately
> 270 of these special milestones.
>
> On Wed, Oct 2, 2019 at 12:43 AM Aaron Young  wrote:
>
>> What I'm unclear on is if these addresses refer to an actual road
>> marker, or an actual distance based upon interpolation between
>> actual road markers.  If you have a road marker at 8km and another
>> road marker at 9km, would a house between the two have addr:milestone
>> 8, 9 or 8.5?  If the address is of an actual road marker then
>> addr:milestone
>> would be appropriate (given that we already misuse highway=milestone
>> to mean kilometre markers); if it's a distance that doesn't correspond to
>> an actual road marker then we need a better name.
>>
>> I would expect the address:milestone=8.5 would be used.  This is
>> something
>> that can be determined by software and is not always written on signage
>> but
>> widely used.
>>
>> There are also usages within the US for emergency response purposes.
>> Highway call boxes often use mile marker or milestone reference to
>> determine location of incident.  US highways have milemarker signage
>> every
>> mile to assist with this purpose.  Utilizing it in address finding
>> throughout the world is a needed tag in my opinion.
>>
>> Aaron
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Dave Swarthout]

The "milestone" value is a misnomer in most modern situations. Here in
Thailand, many roads have actual mile markers, er kilometer markers, but
they are not made of stone. They are painted concrete. In the U.S. there
are very few of these if any. When I'm tagging mile markers in the U.S., I
include a tag description=Metal flag

One of the things I love to map in Thailand are km=0 milestones which
denote the beginning of a numbered route. To date, I've added approximately
270 of these special milestones.

On Wed, Oct 2, 2019 at 12:43 AM Aaron Young  wrote:

> What I'm unclear on is if these addresses refer to an actual road
> marker, or an actual distance based upon interpolation between
> actual road markers.  If you have a road marker at 8km and another
> road marker at 9km, would a house between the two have addr:milestone
> 8, 9 or 8.5?  If the address is of an actual road marker then addr:milestone
> would be appropriate (given that we already misuse highway=milestone
> to mean kilometre markers); if it's a distance that doesn't correspond to
> an actual road marker then we need a better name.
>
> I would expect the address:milestone=8.5 would be used.  This is something
> that can be determined by software and is not always written on signage but
> widely used.
>
> There are also usages within the US for emergency response purposes.
> Highway call boxes often use mile marker or milestone reference to
> determine location of incident.  US highways have milemarker signage every
> mile to assist with this purpose.  Utilizing it in address finding
> throughout the world is a needed tag in my opinion.
>
> Aaron
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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

Re: [Tagging] New tag proposal: 'addr=milestone'

[santamariense]

> I think we're close to hitting the record for how misleading a tag name can
> be.

Maybe.

> This is a proposal for a tag addr:milestone to allow us to specify a
> distance in kilometres
> (not miles), of a house (not a milestone) and the nearest milestone isn't a
> stone but a sign.

It could be in kilometres or miles, depending on the measuring system
of each country. I have already seen literally some milestones at
roads, but yes, they are generally in signs.


> If the locals call the road markers (marked in kilometres and which are not
> stones)
> milestones then there is some slight justification for addr:milestone.  But
> only slight,
> because the address doesn't give the nearest "milestone" but a distance
> along a road.

This could also be understood as follows... I would say that the
address does give the nearest milestone (if it's corrected and
updated) and also gives a distance along a road.


> Unless the locals call road markers "milestones" and think of the "9.5km"
> in terms of
> milestones, addr:milestone is a horrific misnomer and addr:distance better.

As a non-native English speaker, I'll not opine.


> We have a similar system for numbering rural addresses eg
> https://www.google.com/maps/@-28.1554393,153.313766,3a,18.8y,127.92h,70.97t/data=!3m6!1e1!3m4!1sir8KWhNY9fZpBY-ooY_u8g!2e0!7i13312!8i6656,
> 567
> Austinville Rd is 5670 m's from the start of the road, &, because it's an
> odd number, is on the left side.
> I just list them as addr:housenumber

At least in Brazil, some address can contain both values:
addr:housenumber and (proposed) 'addr:milestone'.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Lorenzo Mastrogiacomi]

Il giorno mar, 01/10/2019 alle 23.09 +0200, Tobias Zwick ha scritto:
> Milestones are not necessarily located at the true distance of A to
> B. Not sure why this is the case, but I know that this is true for at
> least Thailand. 
> On 01/10/2019 21:10, Paul Allen wrote:
> > On Tue, 1 Oct 2019 at 19:40, Jorge Aguirre  >  > wrote:
> > The addresses that utilize ‘Km’ as part of the actual address
> > are always related to a specific 'highway:milestone’ on that
> > particular highway. For instance, the address for the Hilton
> > Guatemala Vista Real Hotel in Guatemala - as it appears on their
> > official website: [
> > https://www3.hilton.com/en/hotels/guatemala/hilton-guatemala-city-GUALLHH/index.html
> > ] - is ‘Km. 9.5 CA-1 East Vista Real Complex, Guatemala City,
> > 01015’. What this means is the location is 500 meters from where
> > the 'highway:milestone=9’ on that particular ‘CA-1 East’ highway...
> > 
> > I think we're close to hitting the record for how misleading a tag
> > name can be.
> > This is a proposal for a tag addr:milestone to allow us to specify
> > a distance in kilometres(not miles), of a house (not a milestone)
> > and the nearest milestone isn't a stone but a sign.If the locals
> > call the road markers (marked in kilometres and which are not
> > stones)milestones then there is some slight justification for
> > addr:milestone.  But only slight,because the address doesn't give
> > the nearest "milestone" but a distance along a road.
> > If I understand you correctly, this is actually a distance along a
> > particular highway.  A distancefrom where, exactly?  A highway has
> > two ends, and there may be a milestone (that is neithera stone, nor
> > marked in miles) 9km from each end.  I assume that since the
> > addressis in Guatemala City, that would be what is used for
> > addr:city; I also assume that sincethe street is CA-1 East, that
> > would be what is used for addr:street.  Therefore the onlyother
> > thing required would be addr:distance to specify the distance from
> > addr:cityalong addr:street.
> > Unless the locals call road markers "milestones" and think of the
> > "9.5km" in terms ofmilestones, addr:milestone is a horrific
> > misnomer and addr:distance better.
> > -- Paul

For the same purpose of this proposal I used addr:milestone:distance=*
but I agree with Paul that there's no need for the milestone in the
middle.Real distance or not is the same for distance=* when used with
highway=milestone.I'd also use same rule for the unit, default in
kilometers if no one is given.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Graeme Fitzpatrick]

On Tue, 1 Oct 2019 at 18:11, Mark Wagner  wrote:

> On Tue, 01 Oct 2019 09:01:06 +0200
> Colin Smale  wrote:
> Instead, linear position gets turned into a house number.  For example, a
> building
> eight and a half miles from the start of Long Road might be "850
> Long Road".
>

That's why I asked for a sample of what Jorge was talking about.

We have a similar system for numbering rural addresses eg
https://www.google.com/maps/@-28.1554393,153.313766,3a,18.8y,127.92h,70.97t/data=!3m6!1e1!3m4!1sir8KWhNY9fZpBY-ooY_u8g!2e0!7i13312!8i6656,
567
Austinville Rd is 5670 m's from the start of the road, &, because it's an
odd number, is on the left side.

I just list them as addr:housenumber

Thanks

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Tobias Zwick]

Milestones are not necessarily located at the true distance of A to B. Not sure 
why this is the case, but I know that this is true for at least Thailand. 

On 01/10/2019 21:10, Paul Allen wrote:
> On Tue, 1 Oct 2019 at 19:40, Jorge Aguirre  > wrote:
> 
> The addresses that utilize ‘Km’ as part of the actual address are always 
> related to a specific 'highway:milestone’ on that particular highway. For 
> instance, the address for the Hilton Guatemala Vista Real Hotel in Guatemala 
> - as it appears on their official website: 
> [https://www3.hilton.com/en/hotels/guatemala/hilton-guatemala-city-GUALLHH/index.html]
>  - is ‘Km. 9.5 CA-1 East Vista Real Complex, Guatemala City, 01015’. What 
> this means is the location is 500 meters from where the 'highway:milestone=9’ 
> on that particular ‘CA-1 East’ highway...
> 
> 
> I think we're close to hitting the record for how misleading a tag name can 
> be.
> 
> This is a proposal for a tag addr:milestone to allow us to specify a distance 
> in kilometres
> (not miles), of a house (not a milestone) and the nearest milestone isn't a 
> stone but a sign.
> If the locals call the road markers (marked in kilometres and which are not 
> stones)
> milestones then there is some slight justification for addr:milestone.  But 
> only slight,
> because the address doesn't give the nearest "milestone" but a distance along 
> a road.
> 
> If I understand you correctly, this is actually a distance along a particular 
> highway.  A distance
> from where, exactly?  A highway has two ends, and there may be a milestone 
> (that is neither
> a stone, nor marked in miles) 9km from each end.  I assume that since the 
> address
> is in Guatemala City, that would be what is used for addr:city; I also assume 
> that since
> the street is CA-1 East, that would be what is used for addr:street.  
> Therefore the only
> other thing required would be addr:distance to specify the distance from 
> addr:city
> along addr:street.
> 
> Unless the locals call road markers "milestones" and think of the "9.5km" in 
> terms of
> milestones, addr:milestone is a horrific misnomer and addr:distance better.
> 
> -- 
> Paul
> 
> 
> 
> ___
> 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] New tag proposal: 'addr=milestone'

[Paul Allen]

On Tue, 1 Oct 2019 at 19:40, Jorge Aguirre  wrote:

The addresses that utilize ‘Km’ as part of the actual address are always
> related to a specific 'highway:milestone’ on that particular highway. For
> instance, the address for the Hilton Guatemala Vista Real Hotel in
> Guatemala - as it appears on their official website: [
> https://www3.hilton.com/en/hotels/guatemala/hilton-guatemala-city-GUALLHH/index.html]
> - is ‘Km. 9.5 CA-1 East Vista Real Complex, Guatemala City, 01015’. What
> this means is the location is 500 meters from where the
> 'highway:milestone=9’ on that particular ‘CA-1 East’ highway...
>

I think we're close to hitting the record for how misleading a tag name can
be.

This is a proposal for a tag addr:milestone to allow us to specify a
distance in kilometres
(not miles), of a house (not a milestone) and the nearest milestone isn't a
stone but a sign.
If the locals call the road markers (marked in kilometres and which are not
stones)
milestones then there is some slight justification for addr:milestone.  But
only slight,
because the address doesn't give the nearest "milestone" but a distance
along a road.

If I understand you correctly, this is actually a distance along a
particular highway.  A distance
from where, exactly?  A highway has two ends, and there may be a milestone
(that is neither
a stone, nor marked in miles) 9km from each end.  I assume that since the
address
is in Guatemala City, that would be what is used for addr:city; I also
assume that since
the street is CA-1 East, that would be what is used for addr:street.
Therefore the only
other thing required would be addr:distance to specify the distance from
addr:city
along addr:street.

Unless the locals call road markers "milestones" and think of the "9.5km"
in terms of
milestones, addr:milestone is a horrific misnomer and addr:distance better.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Jorge Aguirre]

Jorge

> On Oct 1, 2019, at 8:25 AM, tagging-requ...@openstreetmap.org wrote:
> 
> Send Tagging mailing list submissions to
>   tagging@openstreetmap.org
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   https://lists.openstreetmap.org/listinfo/tagging
> or, via email, send a message with subject or body 'help' to
>   tagging-requ...@openstreetmap.org
> 
> You can reach the person managing the list at
>   tagging-ow...@openstreetmap.org
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tagging digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: New tag proposal: 'addr=milestone' (Paul Allen)
>   2. Re: Strange tags (Kevin Kenny)
>   3. Re: Was there every a proposal for the disused:key=* /
>  abandoned:key=* lifecycle prefixes? (Kevin Kenny)
>   4. Re: Strange tags (Paul Allen)
>   5. Re: Strange tags (Martin Koppenhoefer)
> 
> 
> --
> 
> Message: 1
> Date: Tue, 1 Oct 2019 14:06:48 +0100
> From: Paul Allen 
> To: "Tag discussion, strategy and related tools"
>   
> Subject: Re: [Tagging] New tag proposal: 'addr=milestone'
> Message-ID:
>   
> Content-Type: text/plain; charset="utf-8"
> 
> On Tue, 1 Oct 2019 at 13:34, santamariense  wrote:
> 
>> 
>> I am not sure about to keep "Km". It might be understandable by the
>> key 'addr:milestone' itself.
> 
> 
> It might.  OSM uses highway=milestone to mean a road marker in general,
> rather than a traditional milestone (which was a stone with distances in
> miles carved on it).  The OSM milestone may not have a distance marked
> on it, but if the distance is given then it is assumed to be in kilometres
> unless
> a unit abbreviation follows.  So "9" would be 9 kilometres but "9 mi" would
> be 9 miles.

The addresses that utilize ‘Km’ as part of the actual address are always 
related to a specific 'highway:milestone’ on that particular highway. For 
instance, the address for the Hilton Guatemala Vista Real Hotel in Guatemala - 
as it appears on their official website: 
[https://www3.hilton.com/en/hotels/guatemala/hilton-guatemala-city-GUALLHH/index.html]
 - is ‘Km. 9.5 CA-1 East Vista Real Complex, Guatemala City, 01015’. What this 
means is the location is 500 meters from where the 'highway:milestone=9’ on 
that particular ‘CA-1 East’ highway... Other than the ‘Km’, there is no other 
reference for anyone to easily find this hotel.  The same occurs for countless 
important (and not so important) POI's lined up on either side of highways 
throughout the country and throughout the entire Latin American region. The Km 
is the only true reference available to locate these.

I agree that the abbreviation for kilometer -Km- is in most cases unnecessary 
in OSM, but in this case think it would be better if it were used. Using the 
same example above, the Hilton’s address in Guatemala - when entered as 
addr:street=CA-1 East + addr:milestone=9.5 would be: ‘9.5 CA-1 East...’ which I 
feel is harder to understand then if it were entered as addr:street=CA-1 East + 
addr:milestone=Km 9.5  for ‘Km 9.5 CA-1 East ...' This is of course mostly 
because of how the address system works in Guatemala and how anyone in 
Guatemala would search for this particular address. 

The main issue is to reach an agreement to create the tag itself: 
'addr:milestone’. To use or not to use the ‘Km’ prefix while entering the 
actual data seems to have taken the spotlight within this proposal - which I 
believe should appear, while others may think otherwise - but in the end I feel 
either way would work. 

I have also written a draft in the wiki for this proposal which may be read at 
[https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Addr:milestone].
 Any comment is welcome and hopefully we may reach an agreement for this soon.

> 
> I have to say that I think using "milestone" to mean a road marker that
> isn't
> a stone and probably isn't marked in miles was an incredibly bad idea.  But
> we're stuck with it.  Even so, a default of kilometres for a thing called a
> milestone is sub-optimal.
> 
> What I'm unclear on is if these addresses refer to an actual road
> marker, or an actual distance based upon interpolation between
> actual road markers.  If you have a road marker at 8km and another
> road marker at 9km, would a house between the two have addr:milestone
> 8, 9 or 8.5?  If the address is of an actual road marker then addr:milestone
> would be appropriate (given that we already misuse highway=milestone
> to mean kilometre markers); if it's a distance that doesn't correspond to
> an actual road marker then we need a better name.
> 
&g

Re: [Tagging] New tag proposal: 'addr=milestone'

[Aaron Young]

What I'm unclear on is if these addresses refer to an actual road
marker, or an actual distance based upon interpolation between
actual road markers.  If you have a road marker at 8km and another
road marker at 9km, would a house between the two have addr:milestone
8, 9 or 8.5?  If the address is of an actual road marker then addr:milestone
would be appropriate (given that we already misuse highway=milestone
to mean kilometre markers); if it's a distance that doesn't correspond to
an actual road marker then we need a better name.
I would expect the address:milestone=8.5 would be used.  This is something that 
can be determined by software and is not always written on signage but widely 
used.

There are also usages within the US for emergency response purposes.  Highway 
call boxes often use mile marker or milestone reference to determine location 
of incident.  US highways have milemarker signage every mile to assist with 
this purpose.  Utilizing it in address finding throughout the world is a needed 
tag in my opinion.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Paul Allen]

On Tue, 1 Oct 2019 at 13:34, santamariense  wrote:

>
> I am not sure about to keep "Km". It might be understandable by the
> key 'addr:milestone' itself.


It might.  OSM uses highway=milestone to mean a road marker in general,
rather than a traditional milestone (which was a stone with distances in
miles carved on it).  The OSM milestone may not have a distance marked
on it, but if the distance is given then it is assumed to be in kilometres
unless
a unit abbreviation follows.  So "9" would be 9 kilometres but "9 mi" would
be 9 miles.

I have to say that I think using "milestone" to mean a road marker that
isn't
a stone and probably isn't marked in miles was an incredibly bad idea.  But
we're stuck with it.  Even so, a default of kilometres for a thing called a
milestone is sub-optimal.

What I'm unclear on is if these addresses refer to an actual road
marker, or an actual distance based upon interpolation between
actual road markers.  If you have a road marker at 8km and another
road marker at 9km, would a house between the two have addr:milestone
8, 9 or 8.5?  If the address is of an actual road marker then addr:milestone
would be appropriate (given that we already misuse highway=milestone
to mean kilometre markers); if it's a distance that doesn't correspond to
an actual road marker then we need a better name.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[santamariense]

This tag only comes to give a standard to something that already is
being mapped off the cuff. When you search by "KM" in
https://taginfo.openstreetmap.org/keys/addr:housenumber#values you
will find 2758 addr:housenumber that contains "KM" as part of their
values. Such information can be even found in addr:street itself. The
string "KM " is found 3025 times as part of the value of addr:street
(https://taginfo.openstreetmap.org/keys/addr:street#values), and 1864
times as part of addr:full
(https://taginfo.openstreetmap.org/keys/addr:full#values). And who
knows how many times people didn't add this information just why they
couldn't find a specific tag for it.

> We want to create a tag to enter this commonly-used data in a logical way
> and therefore propose that it be “addr:milestone=* / (* - Km. ##)”, which
> does seem to meet the criteria and can be easily interpreted and used
> accordingly by any editor.

I am not sure about to keep "Km". It might be understandable by the
key 'addr:milestone' itself. However, a reason to keep "Km" and "Mi"
as a prefix would be to differentiate each other. Anyways I think that
"." must go according to the "International System of Units".

> Could you please give us an example photo, Jorge?

I don't know if such examples could be easily found as images.
Although this is a very common situation in Brazil, it's rare when
people print it in the facade of a building, for example. As an
example of an image, that I personally know, I can present this
(https://imgur.com/a/qxiBmOo) that stands for this
(https://www.openstreetmap.org/way/376981766). The image is not good
enough but it's printed "Av. Pref. Evandro Behr | Km 8 . Nº 7921".
But...
I can present to you guys how many examples of links as you want. I
could say that most of the POIs at highways in rural areas have
milestone as part of their address. Some examples in Brazil:
* http://agrum.com.br/contato.html
* https://www.kmweg.com/company/locations/brazil/santa-maria.html
* http://lisalog.com.br/contato/
* https://www.vilma.com.br/a-vilma/unidades/
* https://portalgirassol.com.br/localizacao/
* http://www.agrex.com.br/contato/
* http://www.goldencargo.com.br/site2/index.php/estrutura/rede-de-filiais
* https://www.cantupneus.com.br/br/filiais
* http://www.jadetransportes.com.br/filiais/

> As they are rare they are either not at all in public records or
> with manipulating the km marker into the Housenumber. Typically
> addresses in Germany are only granted for lots and houses and
> telecoms infrastructure is often in public space so no addresses.

As in Brazil, it's widely used in rural areas, they are in public
records as well. They are used many times even there is a determined
value to addr:housenumber, so 'addr:milestone' could be used with or
without 'addr:housenumber', and always with 'addr:street'.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Mark Wagner]

On Tue, 01 Oct 2019 09:01:06 +0200
Colin Smale  wrote:

> On 2019-10-01 08:18, Florian Lohoff wrote:
> 
> > Hi Jorge,
> > 
> > On Mon, Sep 30, 2019 at 08:15:37PM -0600, Jorge Aguirre wrote: 
> >   
> >> Throughouthe entire Latin American region and some other parts of
> >> the world, it is quite common to find the kilometer (Km.)
> >> information, as may be found on the "highway:milestone", as part
> >> of the actual addresses. Mostly used in suburban and rural areas,
> >> which may usually not even have any visible references or even
> >> house numbers, the use of the milestone is widely utilized to find
> >> an address in these regions.  
> > 
> > We have such addresses in Germany too. They are pretty rare though.
> > sometimes really rural mobile masts or copper distribution
> > street cabinets and stuff carry addresses like this.  
> 
> I may be mistaken but I seem to remember mile markers being used in
> rural areas of the USA to indicate linear position along a main road.

It's extremely rare to use it directly as an address.  Instead, linear
position gets turned into a house number.  For example, a building
eight and a half miles from the start of Long Road might be "850 Long
Road". 

-- 
Mark

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Dave Swarthout]

> I may be mistaken but I seem to remember mile markers being used in rural
areas of the USA to indicate linear position along a main road.

You are not mistaken. Many hotels and parks in the rural areas of Alaska
mark their location that way.

On Tue, Oct 1, 2019 at 2:06 PM Colin Smale  wrote:

> On 2019-10-01 08:18, Florian Lohoff wrote:
>
> Hi Jorge,
>
> On Mon, Sep 30, 2019 at 08:15:37PM -0600, Jorge Aguirre wrote:
>
> Throughouthe entire Latin American region and some other parts of
> the world, it is quite common to find the kilometer (Km.) information,
> as may be found on the "highway:milestone", as part of the actual
> addresses. Mostly used in suburban and rural areas, which may usually
> not even have any visible references or even house numbers, the use of
> the milestone is widely utilized to find an address in these regions.
>
>
> We have such addresses in Germany too. They are pretty rare though.
> sometimes really rural mobile masts or copper distribution
> street cabinets and stuff carry addresses like this.
>
> I may be mistaken but I seem to remember mile markers being used in rural
> areas of the USA to indicate linear position along a main road.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Martin Koppenhoefer]

sent from a phone

> On 1. Oct 2019, at 08:18, Florian Lohoff  wrote:
> 
> We have such addresses in Germany too.


In Italy you can find them as well, they are not uncommon for properties along 
through roads outside of settlements and for highway rest areas.
Currently I’m either using addr:full or in some cases have added them as 
addr:housenumber (when they write the number on the gate)

I would welcome a more structured way to add these.

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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Colin Smale]

On 2019-10-01 08:18, Florian Lohoff wrote:

> Hi Jorge,
> 
> On Mon, Sep 30, 2019 at 08:15:37PM -0600, Jorge Aguirre wrote: 
> 
>> Throughouthe entire Latin American region and some other parts of
>> the world, it is quite common to find the kilometer (Km.) information,
>> as may be found on the "highway:milestone", as part of the actual
>> addresses. Mostly used in suburban and rural areas, which may usually
>> not even have any visible references or even house numbers, the use of
>> the milestone is widely utilized to find an address in these regions.
> 
> We have such addresses in Germany too. They are pretty rare though.
> sometimes really rural mobile masts or copper distribution
> street cabinets and stuff carry addresses like this.

I may be mistaken but I seem to remember mile markers being used in
rural areas of the USA to indicate linear position along a main road.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag proposal: 'addr=milestone'

[Florian Lohoff]

Hi Jorge,

On Mon, Sep 30, 2019 at 08:15:37PM -0600, Jorge Aguirre wrote:
> Throughout the entire Latin American region and some other parts of
> the world, it is quite common to find the kilometer (Km.) information,
> as may be found on the “highway:milestone”, as part of the actual
> addresses. Mostly used in suburban and rural areas, which may usually
> not even have any visible references or even house numbers, the use of
> the milestone is widely utilized to find an address in these regions. 

We have such addresses in Germany too. They are pretty rare though.
sometimes really rural mobile masts or copper distribution
street cabinets and stuff carry addresses like this.

As they are rare they are either not at all in public records or
with manipulating the km marker into the Housenumber. Typically
addresses in Germany are only granted for lots and houses and
telecoms infrastructure is often in public space so no addresses.

I have seen addresses in Telecoms records like "An der Bundesstraße,
Km 4,4".
 
> The highway milestone information may also be found in addresses
> within urban areas, even with the existence of house numbers, as these
> numbers frequently repeat themselves and the only difference between
> them is the exact location on a specific highway - based on and easily
> identified with these milestones.
> 
> We want to create a tag to enter this commonly-used data in a logical
> way and therefore propose that it be “addr:milestone=* / (* - Km.
> ##)”, which does seem to meet the criteria and can be easily
> interpreted and used accordingly by any editor.

So you propose to put the address on the Milestone or on the housing
which uses this Address?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Tagging] New tag proposal: 'addr=milestone'

[Graeme Fitzpatrick]

Could you please give us an example photo, Jorge?

Thanks

Graeme


On Tue, 1 Oct 2019 at 12:18, Jorge Aguirre  wrote:

> Throughout the entire Latin American region and some other parts of the
> world, it is quite common to find the kilometer (Km.) information, as may
> be found on the “highway:milestone”, as part of the actual addresses.
> Mostly used in suburban and rural areas, which may usually not even have
> any visible references or even house numbers, the use of the milestone is
> widely utilized to find an address in these regions.
>
> The highway milestone information may also be found in addresses within
> urban areas, even with the existence of house numbers, as these numbers
> frequently repeat themselves and the only difference between them is the
> exact location on a specific highway - based on and easily identified with
> these milestones.
>
> We want to create a tag to enter this commonly-used data in a logical way
> and therefore propose that it be “addr:milestone=* / (* - Km. ##)”, which
> does seem to meet the criteria and can be easily interpreted and used
> accordingly by any editor.
>
>
> Jorge - JAAS
>
>
> Jorge Aguirre  | Kaart  |  +502.4191.1999  |  jorge.agui...@kaart.com
>
>
> KAART CONFIDENTIAL
> This message (including any attachments) is for the private use of the
> addressee only and may contain confidential or privileged information. If
> you have received this message by mistake please notify the sender by
> return e-mail and delete this message and any attachments from your system.
> Any unauthorized use or dissemination of this message, and any attachments
> in whole or in part is strictly prohibited.
>
>
> ___
> 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] New tag proposal: 'addr=milestone'

[Jorge Aguirre]

Throughout the entire Latin American region and some other parts of the world, 
it is quite common to find the kilometer (Km.) information, as may be found on 
the “highway:milestone”, as part of the actual addresses. Mostly used in 
suburban and rural areas, which may usually not even have any visible 
references or even house numbers, the use of the milestone is widely utilized 
to find an address in these regions. 

The highway milestone information may also be found in addresses within urban 
areas, even with the existence of house numbers, as these numbers frequently 
repeat themselves and the only difference between them is the exact location on 
a specific highway - based on and easily identified with these milestones.

We want to create a tag to enter this commonly-used data in a logical way and 
therefore propose that it be “addr:milestone=* / (* - Km. ##)”, which does seem 
to meet the criteria and can be easily interpreted and used accordingly by any 
editor.


Jorge - JAAS


Jorge Aguirre  | Kaart  |  +502.4191.1999  |  jorge.agui...@kaart.com


KAART CONFIDENTIAL
This message (including any attachments) is for the private use of the 
addressee only and may contain confidential or privileged information. If you 
have received this message by mistake please notify the sender by return e-mail 
and delete this message and any attachments from your system. Any unauthorized 
use or dissemination of this message, and any attachments in whole or in part 
is strictly prohibited.


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

Re: [Tagging] New tag office=consulting was added to Map Features

[marc marc]

Le 28.08.19 à 11:19, Joseph Eisenberg a écrit :
> New description is 'An office for a consulting firm, 
> providing expert professional advice to other companies."

at least a tag to specify the activity should be provided,
because with the current description, an accounting, IT security, 
agricultural consulting, marketing audit can all have this tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] New tag office=consulting was added to Map Features

[Joseph Eisenberg]

Another user just created the page
https://wiki.openstreetmap.org/wiki/Tag:office%3Dconsulting and added
the tag to Map_Features

It's been used since 2012, with over 100 uses since 2013 and now is up
over 600, but it didn't have a page before.

New description is 'An office for a consulting firm, providing expert
professional advice to other companies."

Does this look ok?

We recently discussed whether values of office=* (along with shop=*,
craft=*, building=*)  could be created and added to Map Features
without discussion, though there was not clear consensus on this.

See https://lists.openstreetmap.org/pipermail/tagging/2019-July/046869.html
and continuation in
https://lists.openstreetmap.org/pipermail/tagging/2019-August/046895.html

Joseph

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

Re: [Tagging] New Tag "Departures" voting results.

[Phake Nick]

maybe we can use some keys like eta_link:shortnameofbuscompanyA=*
and eta_link:shortnameofbuscompanyB=* to show different operators
information

在 2019年3月13日週三 15:01，Graeme Fitzpatrick  寫道：

>
>
> On Wed, 13 Mar 2019 at 14:30, Phake Nick  wrote:
>
>> but in term of GTFS I don't think anyone in the world supply data
>> individually for each stops.
>>
>
> Of course!
>
> It would be nice (but probably impossible) to have a single worldwide
> answer but I don't think that will be possible in the foreseeable future :-(
>
> I think it will finish up that we can list this info in this area, people
> can do so there, there & there, but people in those other areas
> unfortunately won't be able to.
>
> I'd say just go with what we can now, & as areas expand, they can all join
> in.
>
> Thanks
>
> Graeme
> ___
> 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] New Tag "Departures" voting results.

[Graeme Fitzpatrick]

On Wed, 13 Mar 2019 at 14:30, Phake Nick  wrote:

> but in term of GTFS I don't think anyone in the world supply data
> individually for each stops.
>

Of course!

It would be nice (but probably impossible) to have a single worldwide
answer but I don't think that will be possible in the foreseeable future :-(

I think it will finish up that we can list this info in this area, people
can do so there, there & there, but people in those other areas
unfortunately won't be able to.

I'd say just go with what we can now, & as areas expand, they can all join
in.

Thanks

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

Re: [Tagging] New Tag "Departures" voting results.

[Phake Nick]

There are processed data for each stop, but in term of GTFS I don't think
anyone in the world supply data individually for each stops. My
understanding is that each GTFS file usually cover a line or a network.

在 2019年3月13日週三 10:32，Graeme Fitzpatrick  寫道：

>
>
> On Wed, 13 Mar 2019 at 11:18, Andrew Davidson  wrote:
>
>> However, you may want to include the feed_id every
>> time to make it easier to search for stops. Also do we want to repeat
>> the same information at every stop or should we store it in a single
>> relation?
>>
>
> Unless I've misunderstood the question / problem (which is quite possible
> :-)), how about both?
>
> Stop info on each stop eg
> https://jp.translink.com.au/plan-your-journey/stops/300699
>
> & route info on the relation eg
> https://jp.translink.com.au/plan-your-journey/timetables/bus/t/756/north/2019-03-13
>
>
> Thanks
>
> Graeme
> ___
> 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] New Tag "Departures" voting results.

[Phake Nick]

For the coordinated schedule, as an example there is a route that departure
at the following time:
08:00, 08:00, 08:03, 08:06, 08:09, 08:12, 08:15, 08:18, 08:22, 08:25,
08:29, 08:33, 08:38, 08:38, 08:38, 08:41, 08:44, 08:47, 08:51, 08:54,
08:57, 09:01, 09:05, 09:09, 09:13, and of these departures, 08:00-08:15
departures are operated by operator A, 08:18-08:33 departures operated by
operator B, 08:38-08:54 departures operated by operator A, and then
08:57-09:13 departures are operated by operator B.

I would say if you map them as multiple relationship then end users would
have no idea which relationship is the one they want. It's also
unnecessarily increasing the number of route variants that need to be
maintained by the order of magnitude of hundreds.

在 2019年3月7日週四 22:17，Martin Koppenhoefer  寫道：

>
>
> sent from a phone
>
> > On 7. Mar 2019, at 15:02, Phake Nick  wrote:
> >
> > The route us currently operated by two different operators on
> coordinated timetable and each operator have their own ETA system. While
> they do not provide a GTFS feed for now, it can be expected that each of
> them will provide their own feed if they would like to do so in the future.
> However it doesn't make sense to have multiple relationship for them as
> they run on exact same route with exact same route number and run on a
> coordinated schedule
>
>
> IMHO it could make sense to have multiple relations, we will also have
> multiple GTFS urls in this case. There are route master relations which can
> group route variants and could be used here as well. A coordinated schedule
> means they have completely different schedules, right? (although the
> customers might not care).
>
> 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] New Tag "Departures" voting results.

[Graeme Fitzpatrick]

On Wed, 13 Mar 2019 at 11:18, Andrew Davidson  wrote:

> However, you may want to include the feed_id every
> time to make it easier to search for stops. Also do we want to repeat
> the same information at every stop or should we store it in a single
> relation?
>

Unless I've misunderstood the question / problem (which is quite possible
:-)), how about both?

Stop info on each stop eg
https://jp.translink.com.au/plan-your-journey/stops/300699

& route info on the relation eg
https://jp.translink.com.au/plan-your-journey/timetables/bus/t/756/north/2019-03-13


Thanks

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

Re: [Tagging] New Tag "Departures" voting results.

[Andrew Davidson]

On 2/3/19 10:02 am, Leif Rasmussen wrote:
> It seems like the best way forward now is for a proposal allowing 
OpenStreetMap data to be tightly integrated with outside sources (such 
as GTFS) to be created by someone.  This would avoid the issues of 
maintainability in OpenStreetMap.


I'm not interested in producing route maps or attempting to route over 
public transport without the aid of external data, so my requirements 
may not meet all of yours.


What I'd like to be able to do in OSM is:

1. Tag the most appropriate OSM object with the stop_id from a GTFS feed.
2. Have some way of tagging which GTFS feed this is from.
3. Handle the case where a stop appears in more than one GTFS feed.

So I see something along the lines of:

=
=

I noticed that someone else mentioned that the same stop can appear in a 
GTFS feed with different stop_ids. This would look like this:


=;
=

If a stop appears in more than one feed then some how we have to map the 
stop_id to the feed. One possible way would be:


:=
:=
.
.
:=the GTFS feed that stop_id_1 comes from>
:=the GTFS feed that stop_id_2 comes from>

.
.

As you can see there are quite a few design question left to be 
answered. For example, the feed_id is only needed if a stop appears in 
more than one feed. However, you may want to include the feed_id every 
time to make it easier to search for stops. Also do we want to repeat 
the same information at every stop or should we store it in a single 
relation?


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

Re: [Tagging] New Tag "Departures" voting results.

[Martin Koppenhoefer]

sent from a phone

> On 7. Mar 2019, at 15:02, Phake Nick  wrote:
> 
> The route us currently operated by two different operators on coordinated 
> timetable and each operator have their own ETA system. While they do not 
> provide a GTFS feed for now, it can be expected that each of them will 
> provide their own feed if they would like to do so in the future. However it 
> doesn't make sense to have multiple relationship for them as they run on 
> exact same route with exact same route number and run on a coordinated 
> schedule


IMHO it could make sense to have multiple relations, we will also have multiple 
GTFS urls in this case. There are route master relations which can group route 
variants and could be used here as well. A coordinated schedule means they have 
completely different schedules, right? (although the customers might not care).

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

Re: [Tagging] New Tag "Departures" voting results.

[Martin Koppenhoefer]

sent from a phone

> On 7. Mar 2019, at 13:06, Paul Allen  wrote:
> 
> It's just that at one time the bus will have the
> livery of "Foo Brothers" and at another time it will have the livery of "Bar 
> Buses."  They're not variant
> routes but variant operators.


the basic options are different routes for each operator, or several operators 
within the same relation (if really all other info is the same, I would 
probably go for the multiple values operator tag).

It is a bit of an edge case, imagine the companies started operating the route 
in a different year, according to what you consider “the route” (route number, 
stops, operator, etc. you might use a different start_date=* for them and will 
require different relations, or if you see the route independently from the 
operator you would have only one start date.

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

Re: [Tagging] New Tag "Departures" voting results.

[Phake Nick]

Nope. For example: https://www.openstreetmap.org/relation/3352395 The route
us currently operated by two different operators on coordinated timetable
and each operator have their own ETA system. While they do not provide a
GTFS feed for now, it can be expected that each of them will provide their
own feed if they would like to do so in the future. However it doesn't make
sense to have multiple relationship for them as they run on exact same
route with exact same route number and run on a coordinated schedule.

在 2019年3月7日週四 14:33，Martin Koppenhoefer  寫道：

>
>
> sent from a phone
>
> > On 5. Mar 2019, at 21:33, Paul Allen  wrote:
> >
> > Routes do exist with more than one operator.
>
>
> wouldn’t these simply be tagged as several relations?
>
>
> 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] New Tag "Departures" voting results.

[Paul Allen]

On Thu, 7 Mar 2019 at 06:33, Martin Koppenhoefer 
wrote:

>
> > On 5. Mar 2019, at 21:33, Paul Allen  wrote:
> >
> > Routes do exist with more than one operator.
>
> wouldn’t these simply be tagged as several relations?
>

I don't know.  It's the same route, with the same service number, the same
destination on the
bus destination board, the same stops.  It's just that at one time the bus
will have the
livery of "Foo Brothers" and at another time it will have the livery of
"Bar Buses."  They're not variant
routes but variant operators.  I hadn't considered the possibility of
treating them as variant routes
and am not sure if that would be considered valid (or sensible).

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

Re: [Tagging] New Tag "Departures" voting results.

[Martin Koppenhoefer]

sent from a phone

> On 5. Mar 2019, at 21:33, Paul Allen  wrote:
> 
> Routes do exist with more than one operator. 


wouldn’t these simply be tagged as several relations? 


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

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Tue, 5 Mar 2019 at 19:07, Jarek Piórkowski  wrote:

>
> Again, frankly - approximately zero general-purpose apps will support
> whatever scheme we could come up with in OpenStreetMap to tag the
> situation "this stop is served by a route that has two separate
> timetables that are both valid, and is also served by another route,
> and here are the links to PDFs of these three timetables".


If we don't come up with a sensible tagging scheme we can guarantee that no
app
will support it.

Yes, url=* would work for a timetable.  But what if we also want to link to
GTFS?  What if a user
clicks on a url=* expecting a timetable and gets a GTFS?  Let's make it
user- and app-friendly,
not user- and app-unfriendly.  It costs us nothing to have specific keys
for these things (except
the time spent arguing here) and has no downside; going with url=* and
finding out later
that it was a bad idea would cause problems.

Routes do exist with more than one operator.  They've happened around here
in the past when
the county council wanted to split subsidized routes between two
operators.  I also encountered
such routes between a large town and a city when both population centres
had town/city
councils who ran their own bus services, on the route between the two
localities.  I encountered
it in a large city after government deregulation meant that a national
operator and the city's own
bus service competed on some routes to nearby commuter villages.

So even if we restrict this to routes and don't put it on stops, we need to
handle the case where two
(or more) operators put up partial timetables or partial GTFS data.  This
isn't an edge case, it's
what happens.  Again, the cost of dealing with it now (even if it's rarely
needed) is minimal; the
cost of changing it later (if we find it's not a rare thing) will not be.
Bad tagging decisions never
die, and they rarely fade away.

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

Re: [Tagging] New Tag "Departures" voting results.

[Jarek Piórkowski]

On Tue, 5 Mar 2019 at 13:35, Paul Allen  wrote:
> But I'd prefer we have specific keys for
> timetables and GTFS data rather than rely upon either of those.  Much better 
> to make things clear
> with timetable=* and gtfs=* (except we have to deal with partial 
> timetables/feeds from operators
> who both run the same route, so we'll need something fancier than that).

Again, frankly - approximately zero general-purpose apps will support
whatever scheme we could come up with in OpenStreetMap to tag the
situation "this stop is served by a route that has two separate
timetables that are both valid, and is also served by another route,
and here are the links to PDFs of these three timetables". So for
these edge cases skip a long discussion, be bold, and just go with
whatever seems to make some sense. And use the time saved to create a
GTFS file instead :)

+1 on the rest of your message.

--Jarek

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

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Tue, 5 Mar 2019 at 17:37, Jarek Piórkowski  wrote:

>
> If your use case is people using the query tool on
> https://openstreetmap.org to follow links to PDFs to plan a journey,
>

Might be a PDF or a simple web page or a Web 2.0 page with funky effects
and even live
updates.  Sadly, given the stupidity of the operators around here, the URL
changes every
time the timetable is updated.

then whatever tagging specification you use doesn't really matter as
> long as it's understandable to the people viewing it - a link looks
> like a link so that's quite easy.


Yes, humans will be OK with whatever key is used as long as the query tool
turns
values that look like URLs into links (which is what it appears to do).
However, it's
nice if we have something consistent and distinct from either website=* or
url=*
which may have other application for the route (or stop, if we add this
information to
stops).  It's always better to make it clear what a link is for than rely
on "that's
a link to something, perhaps it's a timetable."  Especially if we want to
be able
to link to both timetables (for humans) and GTFS data (for apps).

For that matter, for the 10-trips-a-day routes, if you're willing to put in
> the manual

effort, you can probably put the departures into a "departures" tag on the
> stop and it'll be useful when someone queries the stop - the proposal
> got rejected so it's not official guidance, but it doesn't have to be
> official for you to add it and for people to view it.
>

It's not useful on many routes.  Like ones where there's a different
timetable for Saturdays,
no service on Sundays, and one or two of the departures change on school
holidays.  Here
are the codes applying to the T5 route near me:

Sch   Schooldays only
FSVia Fishguard High School on schooldays
S+H Saturday and school holidays only
A  Via Pembrokeshire College on college days
S  Via Aberaeron School on schooldays
SAT  Operates Saturdays only
Col  Connects with College buses
L  Via Llanbadarn Road
HS   Drops off High Street, doesn't drop off at Bus Station
LCVia Llanbadarn Campus, Aberystwyth
X50  Journey destination shows X50, not T5.
T1Change onto T1 service at Aberaeron
FHConnection at Fishguard Square for 410 Fishguard Harbour
FSVia Fishguard School [is this different from the FS above?]
C  Timed to meet with T1 at Aberaeron
cb Connection with Cardi Bach

Actually, it's a little more complex than that. There are other annotations
too.
https://www.richardsbros.co.uk/wp-content/uploads/2018/10/T5-October-2018.pdf

General-purpose transit apps need a machine-readable data format and
> for better or worse, GTFS is the least bad and by far most widespread
> one we've got. Everything else is proprietary, horrible to work with
> (XML SOAP and the like), or both. I know that NaPTAN data got imported
> in some regions of London a good couple of years back, but I really
> draw your attention to the "last modified 2013" in the DfT page you've
> linked - GTFS won and the world has moved on, even Germans are
> starting to publish transit open data as GTFS now.
>

I'm glad GTFS won.  That means we can ignore the NaPTAN stuff.

Where we don't have GTFS, but want to have machine-readable and
> widely-machine-understood timetables for public transit systems,
> building a GTFS file seems a far better option than inventing yet
> another standard within OSM.
>

That seems the best option to me.  It's the primary reason I voted down the
departures
proposal.  There are even sites that give you tools to do that and host it
for you.  Much better
than trying to shoehorn all that into an OSM value.

> I'd use website=* for domains like www.foo.com but url=* for a specific
> page within a website.
>
> I'm not familiar with tagging guidance that suggests this,



>From https://wiki.openstreetmap.org/wiki/Key:url

This tag is being used for very different types of content - official
websites of an amenity or its operator, third-party pages, the object's
Wikipedia entry, photographs featuring the object, or even documentation on
the OSM wiki. So it is advised not to use this tag when more specific
alternatives are available such as website...

So if there's a whole website about an object I use website=* but if it's a
single page within a website
I use url=*.  It's not mandatory (nothing is) but it's what I do.  But I'd
prefer we have specific keys for
timetables and GTFS data rather than rely upon either of those.  Much
better to make things clear
with timetable=* and gtfs=* (except we have to deal with partial
timetables/feeds from operators
who both run the same route, so we'll need something fancier than that).

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

Re: [Tagging] New Tag "Departures" voting results.

[Jarek Piórkowski]

Paul,

If your use case is people using the query tool on
https://openstreetmap.org to follow links to PDFs to plan a journey,
then whatever tagging specification you use doesn't really matter as
long as it's understandable to the people viewing it - a link looks
like a link so that's quite easy. For that matter, for the
10-trips-a-day routes, if you're willing to put in the manual effort,
you can probably put the departures into a "departures" tag on the
stop and it'll be useful when someone queries the stop - the proposal
got rejected so it's not official guidance, but it doesn't have to be
official for you to add it and for people to view it.

But that will never be consumed by transit apps not specialized to a
given area, so the benefit of worldwide standardization is very very
slim.

General-purpose transit apps need a machine-readable data format and
for better or worse, GTFS is the least bad and by far most widespread
one we've got. Everything else is proprietary, horrible to work with
(XML SOAP and the like), or both. I know that NaPTAN data got imported
in some regions of London a good couple of years back, but I really
draw your attention to the "last modified 2013" in the DfT page you've
linked - GTFS won and the world has moved on, even Germans are
starting to publish transit open data as GTFS now.

Where we don't have GTFS, but want to have machine-readable and
widely-machine-understood timetables for public transit systems,
building a GTFS file seems a far better option than inventing yet
another standard within OSM.

> I'd use website=* for domains like www.foo.com but url=* for a specific page 
> within a website.

I'm not familiar with tagging guidance that suggests this, though
everyone may tag as they like, and in the end the tagging doesn't
really matter as any tags on stops that give URLs to HTML or PDF
timetables or departures will not be used by general-purpose transit
apps.

--Jarek

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

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Tue, 5 Mar 2019 at 01:41, Jarek Piórkowski  wrote:

>
> On Sat, 2 Mar 2019 at 19:42, Paul Allen  wrote:
> > As I said, I'd prefer not to use url=* because it could be for anything
> - a page about the history of
> > the bus stop (maybe the shelter is a listed building),
>
> That would rather be website=* though.


Not necessarily.  I'd use website=* for domains like www.foo.com but url=*
for a specific page
within a website.

And to keep it simple, you can do a lot worse than putting an "upcoming
> buses from this
>
stop" page URL into the website=* for vast majority of stops out there. Only
> problem is that doesn't scale very nicely to 1 stops.
>

There are other problems.

1) Many services around here don't have an "upcoming buses from this stop"
page.  We're lucky
they've finally managed to put the timetables on the web.

2) Upcoming buses are useful if you find yourself stranded near a bus
stop.  If you're planning
a future journey you want a timetable.

3) You can always figure out the upcoming buses if you have a timetable;
you cannot figure out
the timetable from upcoming buses.

> or a timetable or whatever web page the
> > mapper happened to think relevant.  I'd prefer to distinguish between a
> human-readable timetable
> > and raw GTFS data (not really human-readable but could be parsed by an
> app).  For lack of anything
> > better, I'd be happy with timetable=* and gtfs=* but I expect somebody
> will be along shortly to explain
> > why those are a very bad idea.
>
> I'd be happy with gtfs= on a possibly high-level
> relation that ultimately includes stops, and timetable= or
> departures= on stops where available as HTML page.
>

Again, "upcoming buses" just doesn't cut it for me.  Great for big towns
and cities.  Not so good
for rural routes.  Great for when you're unexpectedly stranded near a bus
stop.  Not so good for
planning a journey  in advance.

I think the Berlin tagging makes sense:
> https://osm.org/node/1137469153 with website=http://qr.bvg.de/h309003.
> Other pages I'm familiar with are
> https://nb.translink.ca/text/stop/50167 or
>
> http://m.ttc.ca/Schedule/m-schedule.jsp?Route=63N=n.b._on_Shaw_St_at_King_St_West_North_Side=timed


I'm not sure what point you were making there.  They're web pages, not
tagging schemes. If
you wanted me to admire the pretty web pages, that's nice.  If you want to
see what I have to
put up with, here's what one operator has:
https://www.richardsbros.co.uk/wp-content/uploads/2018/08/408-sept-2018.pdf
and here's the
county council's version of the same route (showing more stops):
https://www.ceredigion.gov.uk/media/4410/408.pdf
There is no "next 3 buses" info.  These pages are not updated live.
They're just PDFs.

>From Canadian English perspective, "timetable" would be more likely to
> be interpreted as all departures for the whole week (as on the TTC
> page). "departures" matches the "next 3 buses" case a bit closer. But
> perhaps it's different in British English.
>

>From the perspective of a Brit who uses (but doesn't operate) buses, that
sounds about right.
Where we differ is which is most useful.  We probably need tags for both
(for when both
are available), rather than leave it to the mapper to decide.

> Whatever we go for, we have to cater to the fact that a particular route
> may have more than one
> > operator (I'm not talking about super-routes here).  Around here there
> are many small local operators,
> > and longer routes sometimes split the service between two operators
> (i.e., the route X to Y might
> > be split between an operator based in X and another operator based in Y).
>
> GTFS as a format is operator agnostic (the operator information is not
> in the data at all, only "agency", but each route must be tied to
> exactly one agency). It is more of a question whether a full timetable
> is provided in a given GTFS file or if it is a partial timetable and
> we want to support merging timetables.
>

Good question.  On the routes I have in mind, the county council and one
operator
provided full timetables but the other operator provided a partial
timetable.  The operator
who provided full timetables has managed to produce broken GTFS for some
routes
(it works, but the answers it gives are silly).  I have seen no indication
that the county council
has even heard of GTFS.

What I have seen in transit data collection is one physical stop
> served by multiple agencies which provide separate GTFS files, and
> sometimes they reference the stop using different stop IDs. But in
> that case it would be using different routes, and it should be doable
> with ref:=123 + ref:=abc (where agency_1 and
> agency_2 preferably match the GTFS agency IDs...)
>

Ummm, wouldn't that mean GTFS data about every route by that agency?

However, you've made me abandon hopes of adding this information to stops.
Yes, it
means more steps when using the query tool on standard carto, and some
users won't
be able to handle that, but trying to cater to them 

Re: [Tagging] New Tag "Departures" voting results.

[Jarek Piórkowski]

Hello,

I've gotten paid for wrangling GTFS worldwide before - happy to tell
you some of my experiences.

On Sat, 2 Mar 2019 at 19:42, Paul Allen  wrote:
> As I said, I'd prefer not to use url=* because it could be for anything - a 
> page about the history of
> the bus stop (maybe the shelter is a listed building),

That would rather be website=* though. And to keep it simple, you can
do a lot worse than putting an "upcoming buses from this stop" page
URL into the website=* for vast majority of stops out there. Only
problem is that doesn't scale very nicely to 1 stops.

> or a timetable or whatever web page the
> mapper happened to think relevant.  I'd prefer to distinguish between a 
> human-readable timetable
> and raw GTFS data (not really human-readable but could be parsed by an app).  
> For lack of anything
> better, I'd be happy with timetable=* and gtfs=* but I expect somebody will 
> be along shortly to explain
> why those are a very bad idea.

I'd be happy with gtfs= on a possibly high-level
relation that ultimately includes stops, and timetable= or
departures= on stops where available as HTML page.

I think the Berlin tagging makes sense:
https://osm.org/node/1137469153 with website=http://qr.bvg.de/h309003.
Other pages I'm familiar with are
https://nb.translink.ca/text/stop/50167 or
http://m.ttc.ca/Schedule/m-schedule.jsp?Route=63N=n.b._on_Shaw_St_at_King_St_West_North_Side=timed

From Canadian English perspective, "timetable" would be more likely to
be interpreted as all departures for the whole week (as on the TTC
page). "departures" matches the "next 3 buses" case a bit closer. But
perhaps it's different in British English.

> Whatever we go for, we have to cater to the fact that a particular route may 
> have more than one
> operator (I'm not talking about super-routes here).  Around here there are 
> many small local operators,
> and longer routes sometimes split the service between two operators (i.e., 
> the route X to Y might
> be split between an operator based in X and another operator based in Y).

GTFS as a format is operator agnostic (the operator information is not
in the data at all, only "agency", but each route must be tied to
exactly one agency). It is more of a question whether a full timetable
is provided in a given GTFS file or if it is a partial timetable and
we want to support merging timetables.

Having done some work on merging GTFS, I am afraid the latter is a
deep rabbit hole very few data consumers will go down.

What I have seen in transit data collection is one physical stop
served by multiple agencies which provide separate GTFS files, and
sometimes they reference the stop using different stop IDs. But in
that case it would be using different routes, and it should be doable
with ref:=123 + ref:=abc (where agency_1 and
agency_2 preferably match the GTFS agency IDs...)

Feel free to ask for more technical info about GTFS :) Or for
real-world usage - I've looked at GTFS for most major metros in Canada
and U.S., some smaller metros, data where available in Europe, and a
bit of Australia.

> But stops can be used by
> more than one route.  So then we'd need timetable:route-number:operator=link.

Different route operators with separate timetables is probably in the
"use departures_1 for departures that don't fit" territory. We don't
need to support every edge case to be useful, just the majority of
real world use.

--Jarek

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

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Sun, 3 Mar 2019 at 00:06, Graeme Fitzpatrick 
wrote:

>
> On Sun, 3 Mar 2019 at 00:21, Paul Allen  wrote:
>
>> On Sat, 2 Mar 2019 at 08:14, Warin <61sundow...@gmail.com> wrote:
>>
>>>
>>> So a documented way of including GTFS link in routes?
>>>
>>
>> Yep.  We could just use url=*
>>
>
> When I've been adding bus stops, I've been using timetable= linked to the
> GTFS data for that stop eg https://www.openstreetmap.org/node/6251012182
> links to https://jp.translink.com.au/plan-your-journey/stops/300772,
> which shows the buses for about the next hour, on both routes that service
> that stop. That page (which, incidentally, we have explicit permission to
> use, plus a waiver!) then also links to the full timetable for today &
> other days.
>

That is not the raw GTFS data but a human-readable, active (it uses web 2.0
magic) timetable based
(presumably) on the GTFS data.

When I've looked at stop info via OSMAND on my phone, the URL is there as a
> clickable link so it would appear to work?
>

I'd guess that OSMAND (and the standard carto, which also treats it as a
link) is using a heuristic
along the lines of "If I don't know what the key means AND the value looks
like a URL then treat the
value as a link."  Which is reasonable, but it would be nice to formalize
it.  If for no other reason than
to allow verification tools to know that the value ought to be a link to a
working web page and that
they should check it.

As I said, I'd prefer not to use url=* because it could be for anything - a
page about the history of
the bus stop (maybe the shelter is a listed building), or a timetable or
whatever web page the
mapper happened to think relevant.  I'd prefer to distinguish between a
human-readable timetable
and raw GTFS data (not really human-readable but could be parsed by an
app).  For lack of anything
better, I'd be happy with timetable=* and gtfs=* but I expect somebody will
be along shortly to explain
why those are a very bad idea.

Whatever we go for, we have to cater to the fact that a particular route
may have more than one
operator (I'm not talking about super-routes here).  Around here there are
many small local operators,
and longer routes sometimes split the service between two operators (i.e.,
the route X to Y might
be split between an operator based in X and another operator based in Y).
In the cases where this
has happened one of those operators produced a timetable showing all of the
services irrespective
of the operator whilst the other operator's timetable showed only its own
services.  Since the route
was subsidized by local gov't, there was also a council timetable.
Actually, the route was between
locations in two counties, so there were probably two council timetables.
But there could have been
only two operator timetables that showed only their own services on that
route.  So maybe we need
timetable:operator=link.

Further complication if we want to add this information to bus stops as
well as routes.  An app
ought to be capable of finding the route from a query about a stop and then
getting the appropriate
timetable.  But using the query tool provided by standard carto may require
more smarts than many
data consumers have, so adding the timetable to stops would be nice.  But
stops can be used by
more than one route.  So then we'd need
timetable:route-number:operator=link.

I'm hoping somebody will come up with a better tagging scheme...

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

Re: [Tagging] New Tag "Departures" voting results.

[Graeme Fitzpatrick]

On Sun, 3 Mar 2019 at 00:21, Paul Allen  wrote:

> On Sat, 2 Mar 2019 at 08:14, Warin <61sundow...@gmail.com> wrote:
>
>>
>> So a documented way of including GTFS link in routes?
>>
>
> Yep.  We could just use url=*
>

When I've been adding bus stops, I've been using timetable= linked to the
GTFS data for that stop eg https://www.openstreetmap.org/node/6251012182
links to https://jp.translink.com.au/plan-your-journey/stops/300772, which
shows the buses for about the next hour, on both routes that service that
stop. That page (which, incidentally, we have explicit permission to use,
plus a waiver!) then also links to the full timetable for today & other
days.

When I've looked at stop info via OSMAND on my phone, the URL is there as a
clickable link so it would appear to work?

Thanks

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

Re: [Tagging] New Tag "Departures" voting results.

[Paul Allen]

On Sat, 2 Mar 2019 at 08:14, Warin <61sundow...@gmail.com> wrote:

>
> So a documented way of including GTFS link in routes?
>

Yep.  We could just use url=* but I'd prefer to keep that available for
other things.  Besides,
it would probably be a good idea to allow for a link to the operator's
timetable.  Oh, and there
may be some routes with more than one operator (this has happened around
here where a
route is split between two small local operators).

Routes only, or is there a desire to have this on stops too?
>

There are situations where people want to know the timetable info at a
particular stop.  As in
"My car broke down here, I can see a bus stop, when is the next bus?"  (not
all bus stops indicate
which bus routes they serve).

Depends how sophisticated the data consumer is.  A smart app could figure
out a stop is on one
or more routes then grab the relevant data from the route.  Somebody using
the query tool on
standard carto might have more difficulty.

I think it ought to at least be permissible on stops.   But that requires a
tagging scheme capable
of dealing with stops that serve several routes.

I would think a proposal for routes (ferry or otherwise) where GTFS is not
> freely available is also needed.
>

As others have remarked, there are GTFS servers which allow anyone to set
up a route.  I think
that if we have to add information somewhere, it is better to enter it into
GTFS than to bodge it
into OSM.  Supporting both would make things more complicated for data
consumers.  Also,
the GTFS servers that allow anyone to set up a route have provision to turn
the data over to the
operator of that route as and when that becomes sensible.

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

Re: [Tagging] New Tag "Departures" voting results.

[Mateusz Konieczny]

Mar 2, 2019, 9:12 AM by 61sundow...@gmail.com:

> The other thing picked on it keeping it 'up to date'.
> One says a route is out of date for years (why the contributor does not up 
> date it is not stated)
>
In my case: because updating it would take about half of hour, there are 
multiple ones 
outdated and updating them all would take most of a day.

And all of them will change again once
https://www.openstreetmap.org/way/340398942#map=19/50.07378/19.91285 

is reopened.

Other public transport routes are probably also outdated, but I have more 
interesting things to do
than updating them.

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

Re: [Tagging] New Tag "Departures" voting results.

[Warin]

On 02/03/19 10:27, Jarek Piórkowski wrote:


On Fri, 1 Mar 2019 at 18:02, Leif Rasmussen <354...@gmail.com> wrote:

It seems like the best way forward now is for a proposal allowing OpenStreetMap 
data to be tightly integrated with outside sources (such as GTFS) to be created 
by someone.

+1. To avoid lots of changes, perhaps only set the GTFS link on a
meta-relation where possible, like
https://www.openstreetmap.org/relation/18812


  This would avoid the issues of maintainability in OpenStreetMap.

There is still the concern about GTFS URL changing, which happens
sometimes, but perhaps not as often as schedules in a large city.


So a documented way of including GTFS link in routes?
Routes only, or is there a desire to have this on stops too?

Needs a proposal.




Also, if anyone is interested, I can create a new proposal for adding 
departures times to ferry routes only, and not to bus / train routes.  This 
would be easier to maintain, and as far as I am aware, no GTFS exists for 
ferries.

Just one note - it is possible to have ferry schedules in GTFS. I am
familiar with several cases of these: Berlin city transit ferries;
some ferries in Netherlands in their giant OVapi GTFS file; some
ferries in a Finland; main harbour ferry in Vancouver. You can also
produce your own GTFS for any ferry operation you like (the challenge
is getting people to use it).

It is more a matter of ferries, particularly longer routes, usually
not being operated by public transit bodies that might be more likely
to produce a GTFS feed.


I would think a proposal for routes (ferry or otherwise) where GTFS is not 
freely available is also needed.

The other thing picked on it keeping it 'up to date'.
One says a route is out of date for years (why the contributor does not up date 
it is not stated), so a time table will be even more likely to be out of date.
As these people probably have a GTFS system then a proposal for those who don't 
have GTFS should remove their objection.
But first there needs to be that GTFS link so they can be happy.


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

Re: [Tagging] New Tag "Departures" voting results.

[Jarek Piórkowski]

On Fri, 1 Mar 2019 at 18:02, Leif Rasmussen <354...@gmail.com> wrote:
> It seems like the best way forward now is for a proposal allowing 
> OpenStreetMap data to be tightly integrated with outside sources (such as 
> GTFS) to be created by someone.

+1. To avoid lots of changes, perhaps only set the GTFS link on a
meta-relation where possible, like
https://www.openstreetmap.org/relation/18812

>  This would avoid the issues of maintainability in OpenStreetMap.

There is still the concern about GTFS URL changing, which happens
sometimes, but perhaps not as often as schedules in a large city.

> Also, if anyone is interested, I can create a new proposal for adding 
> departures times to ferry routes only, and not to bus / train routes.  This 
> would be easier to maintain, and as far as I am aware, no GTFS exists for 
> ferries.

Just one note - it is possible to have ferry schedules in GTFS. I am
familiar with several cases of these: Berlin city transit ferries;
some ferries in Netherlands in their giant OVapi GTFS file; some
ferries in a Finland; main harbour ferry in Vancouver. You can also
produce your own GTFS for any ferry operation you like (the challenge
is getting people to use it).

It is more a matter of ferries, particularly longer routes, usually
not being operated by public transit bodies that might be more likely
to produce a GTFS feed.

--Jarek

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

[Tagging] New Tag "Departures" voting results.

[Leif Rasmussen]

Hi everyone,
The proposal for the tag "departures" has finished, and has a final vote of
* 12 "Approve"
* 22 "Reject"
* 3 Comments without vote
* 1 "Degree of incredulity" at the proposal
. . . meaning that the proposal was rejected.

Overall, the main idea voters expressed was that connecting with GTFS and
others would be advantageous over adding the data to OpenStreetMap in the
form of tags, as it would allow data consumers to just download the data
from the original source, making storing the timetables directly in
OpenStreetMap unnecessary.  People living in regions without public GTFS
feeds expressed concerns about cases where OpenStreetMap would be the only
public source of timetable data, however.
Many people agreed on the contrary that the data would still make sense on
ferry routes, which are more essential to car navigation, and usually have
simpler schedules.

It seems like the best way forward now is for a proposal allowing
OpenStreetMap data to be tightly integrated with outside sources (such as
GTFS) to be created by someone.  This would avoid the issues of
maintainability in OpenStreetMap.

Also, if anyone is interested, I can create a new proposal for adding
departures times to ferry routes only, and not to bus / train routes.  This
would be easier to maintain, and as far as I am aware, no GTFS exists for
ferries.

Thank you to everyone who participated in the voting and discussion of this
proposal!
Leif Rasmussen
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag for major recipient postcodes

[Martin Koppenhoefer]

sent from a phone

> On 22. Dec 2017, at 22:27, Rainer  wrote:
> 
> So it would be contact:addr:postcode_major_recipient


nice, maybe we could add the issuer as well, e.g.
contact:addr:deutsche_post_aktiengesellschaft:postcode_major_recipient
;-)

seriously, something more concise would probably 

cheers,
Martin 

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

Re: [Tagging] New tag for major recipient postcodes

[Rainer]

Thinking about contact:addr:*, that sounds like a good idea.

So it would be contact:addr:postcode_major_recipient

Advantage is that it describes the purpose to be used for contacting the 
company, authority, hospital or whatever POI, but not e.g. for 
navigation, because it doesn't have a geographic location.
I would avoid a too generic tag like non-geographic postcode, because it 
is used on POIs and any map that is made from OSM data would show it and 
any user of such POI information wouldn't know, what it is.


- Rainer


Am 19.12.2017 10:50, schrieb althio:

I think one mapping practice with contact:* could help .

1- addr:* tag space is for generic addresses, used by all consumers

2- if there is ambiguity between adresses (postal, physical, ...) then
use several namespaces
2a - addr:* tag space for physical address (used by geocoding, routing, ...)
2a - contact:addr:* space for contact (postal) address (used for
detailed information about one POI)

if 2a is not suitable, consider any of:
physical:addr vs [contact|post|postal|snailmail]:addr

-- althio


On 18 December 2017 at 20:43, Simon Poole  wrote:


Am 17.12.2017 um 21:22 schrieb Warin:

As they are not related to a physical address then why use the address
space?

The addr tag space is for postal addresses, that are not guaranteed to be
physical at all (for example addr:city is the postal city, which might be
completely un-surveyable).

That is not really a problem, the problem is more that we don't have a
scheme for non-postal addresses.

Simon


Possibly the contact space? contact:mail:postcode=*

-
I believe 1800 numbers cannot be used internationally, so I don't use the
ISD codes, that OSM requests, with these.



On 18-Dec-17 12:36 AM, José G Moya Y. wrote:

Do you mean PO box? In some cities, massive PO boxes have a special Zip
code/ postal code. It could be a property of the PObox address.

Maybe an attribute at the POI is right, as POI use to list email addresses
and web addresses, which are independent from actual physical address (as PO
boxes are), also.

National-wide phone numbers treated (such as +1-800-x in USA, cellphones,
"vocal nomad" numbers (+34-51-xx in Spain, if I remember well)  are unlinked
to physical addresses too. Are they directions about how to use it?



El 17/12/2017 13:58, "Tom Pfeifer"  escribió:

As these postcodes are kind of a virtual address that is not tied to a
particular pysical location, my opinion would be _not to add them to OSM_,
which is a geo database and not primarily a post code reference database.

Typically for those companies in DE, there is an additional physical
address which has a different postcode for the street address, which is
regularly tagged on the physical location.

tom

On 17.12.2017 13:42, Rainer wrote:

Hi all,

recently I came across postal codes in POI addresses, which aren't the
classic scheme addr:postcode & addr:city & addr:street & addr:housenumber.
However it is a special postcode that is assigned to recipients that receive
a big amount of post every day, typically big companies or authorities. This
kind of postcode is used only together with addr:city and does not require
street and housenumber. So to say the post company has a big sack for post
to that special postcode, puts in all the letters that are addressed to it
and delivers the sack to the recipient.
After some discussion in the german user forum
https://forum.openstreetmap.org/viewtopic.php?id=60421 I want to propose a
tag for this kind of postcode and would like to discuss it here in the
tagging mailing list.

The proposal is:  addr:postcode_major_recipient

It should be used on POIs, because it is an attribute of the company,
authority or whatever, but not as an address of a building, because it is
not assigned to such directly. Target is to have a separate tag for this
kind of postcode to avoid a mix-up with the normal addr:postcode.

As I am not a native British English speaker, I have asked one and
consulted the english page of the Deutsche Post. Reference:
https://www.postdirekt.de/plzserver/PlzSearchServlet?lang=en_GB -> goto More
-> Find major recipient

Probably similar kinds of postcodes exist also in other post companies in
other countries, so inputs about that are welcome.


Best regards,
Rainer


___
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


___
Tagging mailing list

Re: [Tagging] New tag for major recipient postcodes

[althio]

I think one mapping practice with contact:* could help .

1- addr:* tag space is for generic addresses, used by all consumers

2- if there is ambiguity between adresses (postal, physical, ...) then
use several namespaces
2a - addr:* tag space for physical address (used by geocoding, routing, ...)
2a - contact:addr:* space for contact (postal) address (used for
detailed information about one POI)

if 2a is not suitable, consider any of:
physical:addr vs [contact|post|postal|snailmail]:addr

-- althio


On 18 December 2017 at 20:43, Simon Poole  wrote:
>
>
> Am 17.12.2017 um 21:22 schrieb Warin:
>
> As they are not related to a physical address then why use the address
> space?
>
> The addr tag space is for postal addresses, that are not guaranteed to be
> physical at all (for example addr:city is the postal city, which might be
> completely un-surveyable).
>
> That is not really a problem, the problem is more that we don't have a
> scheme for non-postal addresses.
>
> Simon
>
>
> Possibly the contact space? contact:mail:postcode=*
>
> -
> I believe 1800 numbers cannot be used internationally, so I don't use the
> ISD codes, that OSM requests, with these.
>
>
>
> On 18-Dec-17 12:36 AM, José G Moya Y. wrote:
>
> Do you mean PO box? In some cities, massive PO boxes have a special Zip
> code/ postal code. It could be a property of the PObox address.
>
> Maybe an attribute at the POI is right, as POI use to list email addresses
> and web addresses, which are independent from actual physical address (as PO
> boxes are), also.
>
> National-wide phone numbers treated (such as +1-800-x in USA, cellphones,
> "vocal nomad" numbers (+34-51-xx in Spain, if I remember well)  are unlinked
> to physical addresses too. Are they directions about how to use it?
>
>
>
> El 17/12/2017 13:58, "Tom Pfeifer"  escribió:
>>
>> As these postcodes are kind of a virtual address that is not tied to a
>> particular pysical location, my opinion would be _not to add them to OSM_,
>> which is a geo database and not primarily a post code reference database.
>>
>> Typically for those companies in DE, there is an additional physical
>> address which has a different postcode for the street address, which is
>> regularly tagged on the physical location.
>>
>> tom
>>
>> On 17.12.2017 13:42, Rainer wrote:
>>>
>>> Hi all,
>>>
>>> recently I came across postal codes in POI addresses, which aren't the
>>> classic scheme addr:postcode & addr:city & addr:street & addr:housenumber.
>>> However it is a special postcode that is assigned to recipients that receive
>>> a big amount of post every day, typically big companies or authorities. This
>>> kind of postcode is used only together with addr:city and does not require
>>> street and housenumber. So to say the post company has a big sack for post
>>> to that special postcode, puts in all the letters that are addressed to it
>>> and delivers the sack to the recipient.
>>> After some discussion in the german user forum
>>> https://forum.openstreetmap.org/viewtopic.php?id=60421 I want to propose a
>>> tag for this kind of postcode and would like to discuss it here in the
>>> tagging mailing list.
>>>
>>> The proposal is:  addr:postcode_major_recipient
>>>
>>> It should be used on POIs, because it is an attribute of the company,
>>> authority or whatever, but not as an address of a building, because it is
>>> not assigned to such directly. Target is to have a separate tag for this
>>> kind of postcode to avoid a mix-up with the normal addr:postcode.
>>>
>>> As I am not a native British English speaker, I have asked one and
>>> consulted the english page of the Deutsche Post. Reference:
>>> https://www.postdirekt.de/plzserver/PlzSearchServlet?lang=en_GB -> goto More
>>> -> Find major recipient
>>>
>>> Probably similar kinds of postcodes exist also in other post companies in
>>> other countries, so inputs about that are welcome.
>>>
>>>
>>> Best regards,
>>> Rainer
>>
>>
>> ___
>> 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
>

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

Re: [Tagging] New tag for major recipient postcodes

[Adam Snape]

Hi,

The British terminology for this is a 'non-geographic postcode'. I suggest
that this terminology might make a more appropriate general tag because
a) The purpose of the tag to indicate the non-geographic nature of the
postcode, not the volume of post the address recieves
and
b) Special postcodes may be allocated for reasons other than sheer volume
of mail.

Kind regards,

Adam

On 17 December 2017 at 12:42, Rainer  wrote:

> Hi all,
>
> recently I came across postal codes in POI addresses, which aren't the
> classic scheme addr:postcode & addr:city & addr:street & addr:housenumber.
> However it is a special postcode that is assigned to recipients that
> receive a big amount of post every day, typically big companies or
> authorities. This kind of postcode is used only together with addr:city and
> does not require street and housenumber. So to say the post company has a
> big sack for post to that special postcode, puts in all the letters that
> are addressed to it and delivers the sack to the recipient.
> After some discussion in the german user forum
> https://forum.openstreetmap.org/viewtopic.php?id=60421 I want to propose
> a tag for this kind of postcode and would like to discuss it here in the
> tagging mailing list.
>
> The proposal is:  addr:postcode_major_recipient
>
> It should be used on POIs, because it is an attribute of the company,
> authority or whatever, but not as an address of a building, because it is
> not assigned to such directly. Target is to have a separate tag for this
> kind of postcode to avoid a mix-up with the normal addr:postcode.
>
> As I am not a native British English speaker, I have asked one and
> consulted the english page of the Deutsche Post. Reference:
> https://www.postdirekt.de/plzserver/PlzSearchServlet?lang=en_GB -> goto
> More -> Find major recipient
>
> Probably similar kinds of postcodes exist also in other post companies in
> other countries, so inputs about that are welcome.
>
>
> Best regards,
> Rainer
>
> ___
> 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] New tag for major recipient postcodes

[Simon Poole]

Am 17.12.2017 um 21:22 schrieb Warin:
> As they are not related to a physical address then why use the address
> space?
The addr tag space is for postal addresses, that are not guaranteed to
be physical at all (for example addr:city is the postal city, which
might be completely un-surveyable).

That is not really a problem, the problem is more that we don't have a
scheme for non-postal addresses.

Simon

> Possibly the contact space? contact:mail:postcode=*
>
> -
> I believe 1800 numbers cannot be used internationally, so I don't use
> the ISD codes, that OSM requests, with these.
>
>
>
> On 18-Dec-17 12:36 AM, José G Moya Y. wrote:
>> Do you mean PO box? In some cities, massive PO boxes have a special
>> Zip code/ postal code. It could be a property of the PObox address.
>>
>> Maybe an attribute at the POI is right, as POI use to list email
>> addresses and web addresses, which are independent from actual
>> physical address (as PO boxes are), also.
>>
>> National-wide phone numbers treated (such as +1-800-x in USA,
>> cellphones, "vocal nomad" numbers (+34-51-xx in Spain, if I remember
>> well)  are unlinked to physical addresses too. Are they directions
>> about how to use it?
>>
>>
>>
>> El 17/12/2017 13:58, "Tom Pfeifer" > > escribió:
>>
>> As these postcodes are kind of a virtual address that is not tied
>> to a particular pysical location, my opinion would be _not to add
>> them to OSM_, which is a geo database and not primarily a post
>> code reference database.
>>
>> Typically for those companies in DE, there is an additional
>> physical address which has a different postcode for the street
>> address, which is regularly tagged on the physical location.
>>
>> tom
>>
>> On 17.12.2017 13:42, Rainer wrote:
>>
>> Hi all,
>>
>> recently I came across postal codes in POI addresses, which
>> aren't the classic scheme addr:postcode & addr:city &
>> addr:street & addr:housenumber. However it is a special
>> postcode that is assigned to recipients that receive a big
>> amount of post every day, typically big companies or
>> authorities. This kind of postcode is used only together with
>> addr:city and does not require street and housenumber. So to
>> say the post company has a big sack for post to that special
>> postcode, puts in all the letters that are addressed to it
>> and delivers the sack to the recipient.
>> After some discussion in the german user forum
>> https://forum.openstreetmap.org/viewtopic.php?id=60421
>>  I
>> want to propose a tag for this kind of postcode and would
>> like to discuss it here in the tagging mailing list.
>>
>> The proposal is:  addr:postcode_major_recipient
>>
>> It should be used on POIs, because it is an attribute of the
>> company, authority or whatever, but not as an address of a
>> building, because it is not assigned to such directly. Target
>> is to have a separate tag for this kind of postcode to avoid
>> a mix-up with the normal addr:postcode.
>>
>> As I am not a native British English speaker, I have asked
>> one and consulted the english page of the Deutsche Post.
>> Reference:
>> https://www.postdirekt.de/plzserver/PlzSearchServlet?lang=en_GB
>> 
>> -> goto More -> Find major recipient
>>
>> Probably similar kinds of postcodes exist also in other post
>> companies in other countries, so inputs about that are welcome.
>>
>>
>> Best regards,
>> Rainer
>>
>>
>> ___
>> 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



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

Re: [Tagging] New tag for major recipient postcodes

[marc marc]

Hello,

In stead of creating an additional tag and thus an additional country 
specific rule,
why not using addr:full (or in the contact namespace if some prefer) to 
put this special addr that doesn't follow the standard country rule ?

Regards,
Marc

Le 17. 12. 17 à 22:25, Rainer a écrit :
> They are used together with addr:city. The combination aoff 
> addr:postcode_major_recipient and addr:city acts as an alias for 
> addr:postcode & addr:city & addr:street & addr:housenumber.
> 
> 
> Am 17.12.2017 21:22, schrieb Warin:
>> As they are not related to a physical address then why use the address 
>> space?
>> Possibly the contact space? contact:mail:postcode=*
>>
>> -
>> I believe 1800 numbers cannot be used internationally, so I don't use 
>> the ISD codes, that OSM requests, with these.
>>
>>
>>
>> On 18-Dec-17 12:36 AM, José G Moya Y. wrote:
>>> Do you mean PO box? In some cities, massive PO boxes have a special 
>>> Zip code/ postal code. It could be a property of the PObox address.
>>>
>>> Maybe an attribute at the POI is right, as POI use to list email 
>>> addresses and web addresses, which are independent from actual 
>>> physical address (as PO boxes are), also.
>>>
>>> National-wide phone numbers treated (such as +1-800-x in USA, 
>>> cellphones, "vocal nomad" numbers (+34-51-xx in Spain, if I remember 
>>> well)  are unlinked to physical addresses too. Are they directions 
>>> about how to use it?
>>>
>>>
>>>
>>> El 17/12/2017 13:58, "Tom Pfeifer" >> > escribió:
>>>
>>> As these postcodes are kind of a virtual address that is not tied
>>> to a particular pysical location, my opinion would be _not to add
>>> them to OSM_, which is a geo database and not primarily a post
>>> code reference database.
>>>
>>> Typically for those companies in DE, there is an additional
>>> physical address which has a different postcode for the street
>>> address, which is regularly tagged on the physical location.
>>>
>>> tom
>>>
>>> On 17.12.2017 13:42, Rainer wrote:
>>>
>>> Hi all,
>>>
>>> recently I came across postal codes in POI addresses, which
>>> aren't the classic scheme addr:postcode & addr:city &
>>> addr:street & addr:housenumber. However it is a special
>>> postcode that is assigned to recipients that receive a big
>>> amount of post every day, typically big companies or
>>> authorities. This kind of postcode is used only together with
>>> addr:city and does not require street and housenumber. So to
>>> say the post company has a big sack for post to that special
>>> postcode, puts in all the letters that are addressed to it
>>> and delivers the sack to the recipient.
>>> After some discussion in the german user forum
>>> https://forum.openstreetmap.org/viewtopic.php?id=60421
>>>  I
>>> want to propose a tag for this kind of postcode and would
>>> like to discuss it here in the tagging mailing list.
>>>
>>> The proposal is:  addr:postcode_major_recipient
>>>
>>> It should be used on POIs, because it is an attribute of the
>>> company, authority or whatever, but not as an address of a
>>> building, because it is not assigned to such directly. Target
>>> is to have a separate tag for this kind of postcode to avoid
>>> a mix-up with the normal addr:postcode.
>>>
>>> As I am not a native British English speaker, I have asked
>>> one and consulted the english page of the Deutsche Post.
>>> Reference:
>>> https://www.postdirekt.de/plzserver/PlzSearchServlet?lang=en_GB
>>> 
>>> -> goto More -> Find major recipient
>>>
>>> Probably similar kinds of postcodes exist also in other post
>>> companies in other countries, so inputs about that are welcome.
>>>
>>>
>>> Best regards,
>>> Rainer
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag for major recipient postcodes

[Martin Koppenhoefer]

sent from a phone

> On 17. Dec 2017, at 21:26, José G Moya Y.  wrote:
> 
> Obviously, phone numbers and email addresses are not "on the ground", so they 
> are just as out of scope of OSM as PO boxes/special zips are.


I believe this is a very limiting view of both, the scope of OSM and the 
question of verifiability, and it is far from true: „On the ground“ you can ask 
a shop owner for her email address or phone number, so the verifiability is 
there. You can also often get this information from customer receipts, business 
cards, websites, advertising, a note in the window, etc.

I agree that these special postcodes are not about a physical address of the 
kind we have specific interest in, but I would not dismiss them as completely 
out of scope. They are in the same category as email addresses and similar, a 
way to contact the business.

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

Re: [Tagging] New tag for major recipient postcodes

[Rainer]

They are used together with addr:city. The combination aoff 
addr:postcode_major_recipient and addr:city acts as an alias for 
addr:postcode & addr:city & addr:street & addr:housenumber.



Am 17.12.2017 21:22, schrieb Warin:
As they are not related to a physical address then why use the address 
space?

Possibly the contact space? contact:mail:postcode=*

-
I believe 1800 numbers cannot be used internationally, so I don't use 
the ISD codes, that OSM requests, with these.




On 18-Dec-17 12:36 AM, José G Moya Y. wrote:
Do you mean PO box? In some cities, massive PO boxes have a special 
Zip code/ postal code. It could be a property of the PObox address.


Maybe an attribute at the POI is right, as POI use to list email 
addresses and web addresses, which are independent from actual 
physical address (as PO boxes are), also.


National-wide phone numbers treated (such as +1-800-x in USA, 
cellphones, "vocal nomad" numbers (+34-51-xx in Spain, if I remember 
well)  are unlinked to physical addresses too. Are they directions 
about how to use it?




El 17/12/2017 13:58, "Tom Pfeifer" > escribió:


As these postcodes are kind of a virtual address that is not tied
to a particular pysical location, my opinion would be _not to add
them to OSM_, which is a geo database and not primarily a post
code reference database.

Typically for those companies in DE, there is an additional
physical address which has a different postcode for the street
address, which is regularly tagged on the physical location.

tom

On 17.12.2017 13:42, Rainer wrote:

Hi all,

recently I came across postal codes in POI addresses, which
aren't the classic scheme addr:postcode & addr:city &
addr:street & addr:housenumber. However it is a special
postcode that is assigned to recipients that receive a big
amount of post every day, typically big companies or
authorities. This kind of postcode is used only together with
addr:city and does not require street and housenumber. So to
say the post company has a big sack for post to that special
postcode, puts in all the letters that are addressed to it
and delivers the sack to the recipient.
After some discussion in the german user forum
https://forum.openstreetmap.org/viewtopic.php?id=60421
 I
want to propose a tag for this kind of postcode and would
like to discuss it here in the tagging mailing list.

The proposal is:  addr:postcode_major_recipient

It should be used on POIs, because it is an attribute of the
company, authority or whatever, but not as an address of a
building, because it is not assigned to such directly. Target
is to have a separate tag for this kind of postcode to avoid
a mix-up with the normal addr:postcode.

As I am not a native British English speaker, I have asked
one and consulted the english page of the Deutsche Post.
Reference:
https://www.postdirekt.de/plzserver/PlzSearchServlet?lang=en_GB

-> goto More -> Find major recipient

Probably similar kinds of postcodes exist also in other post
companies in other countries, so inputs about that are welcome.


Best regards,
Rainer


___
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] New tag for major recipient postcodes

[José G Moya Y .]

El 17/12/2017 21:17, "Tom Pfeifer"  escribió:

On 17.12.2017 14:36, José G Moya Y. wrote:

>
> National-wide phone numbers treated (such as +1-800-x in USA, cellphones,
> "vocal nomad" numbers (+34-51-xx in Spain, if I remember well)  are
> unlinked to physical addresses too. Are they directions about how to use it?
>

Simlarly, OSM is not a phone directory, or a worldwide compendium of
everything. No benefit for OSM adding those.


If I tell about phone numbers and web addresses is just because ID suggest
adding phone numbers and web addresses to things like bank offices or
shops.
Obviously, phone numbers and email addresses are not "on the ground", so
they are just as out of scope of OSM as PO boxes/special zips are.

I think I agree with you about this.



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

Re: [Tagging] New tag for major recipient postcodes

[Warin]

As they are not related to a physical address then why use the address 
space?

Possibly the contact space? contact:mail:postcode=*

-
I believe 1800 numbers cannot be used internationally, so I don't use 
the ISD codes, that OSM requests, with these.




On 18-Dec-17 12:36 AM, José G Moya Y. wrote:
Do you mean PO box? In some cities, massive PO boxes have a special 
Zip code/ postal code. It could be a property of the PObox address.


Maybe an attribute at the POI is right, as POI use to list email 
addresses and web addresses, which are independent from actual 
physical address (as PO boxes are), also.


National-wide phone numbers treated (such as +1-800-x in USA, 
cellphones, "vocal nomad" numbers (+34-51-xx in Spain, if I remember 
well)  are unlinked to physical addresses too. Are they directions 
about how to use it?




El 17/12/2017 13:58, "Tom Pfeifer" > escribió:


As these postcodes are kind of a virtual address that is not tied
to a particular pysical location, my opinion would be _not to add
them to OSM_, which is a geo database and not primarily a post
code reference database.

Typically for those companies in DE, there is an additional
physical address which has a different postcode for the street
address, which is regularly tagged on the physical location.

tom

On 17.12.2017 13:42, Rainer wrote:

Hi all,

recently I came across postal codes in POI addresses, which
aren't the classic scheme addr:postcode & addr:city &
addr:street & addr:housenumber. However it is a special
postcode that is assigned to recipients that receive a big
amount of post every day, typically big companies or
authorities. This kind of postcode is used only together with
addr:city and does not require street and housenumber. So to
say the post company has a big sack for post to that special
postcode, puts in all the letters that are addressed to it and
delivers the sack to the recipient.
After some discussion in the german user forum
https://forum.openstreetmap.org/viewtopic.php?id=60421
 I
want to propose a tag for this kind of postcode and would like
to discuss it here in the tagging mailing list.

The proposal is:  addr:postcode_major_recipient

It should be used on POIs, because it is an attribute of the
company, authority or whatever, but not as an address of a
building, because it is not assigned to such directly. Target
is to have a separate tag for this kind of postcode to avoid a
mix-up with the normal addr:postcode.

As I am not a native British English speaker, I have asked one
and consulted the english page of the Deutsche Post.
Reference:
https://www.postdirekt.de/plzserver/PlzSearchServlet?lang=en_GB

-> goto More -> Find major recipient

Probably similar kinds of postcodes exist also in other post
companies in other countries, so inputs about that are welcome.


Best regards,
Rainer


___
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] New tag for major recipient postcodes

[Tom Pfeifer]

On 17.12.2017 14:36, José G Moya Y. wrote:
Do you mean PO box? In some cities, massive PO boxes have a special Zip code/ postal code. It could 
be a property of the PObox address.


It is kind of a postbox, but the mail might actually still be delivered by the carrier (and not 
picked from a box), and it might be even delivered to a subcontractor elsewhere who handles the 
incoming mail. Again I don't see a benefit for OSM from such entries.


Maybe an attribute at the POI is right, as POI use to list email addresses and web addresses, which 
are independent from actual physical address (as PO boxes are), also.


National-wide phone numbers treated (such as +1-800-x in USA, cellphones, "vocal nomad" numbers 
(+34-51-xx in Spain, if I remember well)  are unlinked to physical addresses too. Are they 
directions about how to use it?


Simlarly, OSM is not a phone directory, or a worldwide compendium of everything. No benefit for OSM 
adding those.


 
El 17/12/2017 13:58, "Tom Pfeifer" > escribió:


As these postcodes are kind of a virtual address that is not tied to a 
particular pysical
location, my opinion would be _not to add them to OSM_, which is a geo 
database and not
primarily a post code reference database.

Typically for those companies in DE, there is an additional physical 
address which has a
different postcode for the street address, which is regularly tagged on the 
physical location.

On 17.12.2017 13:42, Rainer wrote:

The proposal is:  addr:postcode_major_recipient


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

Re: [Tagging] New tag for major recipient postcodes

[José G Moya Y .]

Do you mean PO box? In some cities, massive PO boxes have a special Zip
code/ postal code. It could be a property of the PObox address.

Maybe an attribute at the POI is right, as POI use to list email addresses
and web addresses, which are independent from actual physical address (as
PO boxes are), also.

National-wide phone numbers treated (such as +1-800-x in USA, cellphones,
"vocal nomad" numbers (+34-51-xx in Spain, if I remember well)  are
unlinked to physical addresses too. Are they directions about how to use it?



El 17/12/2017 13:58, "Tom Pfeifer"  escribió:

> As these postcodes are kind of a virtual address that is not tied to a
> particular pysical location, my opinion would be _not to add them to OSM_,
> which is a geo database and not primarily a post code reference database.
>
> Typically for those companies in DE, there is an additional physical
> address which has a different postcode for the street address, which is
> regularly tagged on the physical location.
>
> tom
>
> On 17.12.2017 13:42, Rainer wrote:
>
>> Hi all,
>>
>> recently I came across postal codes in POI addresses, which aren't the
>> classic scheme addr:postcode & addr:city & addr:street & addr:housenumber.
>> However it is a special postcode that is assigned to recipients that
>> receive a big amount of post every day, typically big companies or
>> authorities. This kind of postcode is used only together with addr:city and
>> does not require street and housenumber. So to say the post company has a
>> big sack for post to that special postcode, puts in all the letters that
>> are addressed to it and delivers the sack to the recipient.
>> After some discussion in the german user forum
>> https://forum.openstreetmap.org/viewtopic.php?id=60421 I want to propose
>> a tag for this kind of postcode and would like to discuss it here in the
>> tagging mailing list.
>>
>> The proposal is:  addr:postcode_major_recipient
>>
>> It should be used on POIs, because it is an attribute of the company,
>> authority or whatever, but not as an address of a building, because it is
>> not assigned to such directly. Target is to have a separate tag for this
>> kind of postcode to avoid a mix-up with the normal addr:postcode.
>>
>> As I am not a native British English speaker, I have asked one and
>> consulted the english page of the Deutsche Post. Reference:
>> https://www.postdirekt.de/plzserver/PlzSearchServlet?lang=en_GB -> goto
>> More -> Find major recipient
>>
>> Probably similar kinds of postcodes exist also in other post companies in
>> other countries, so inputs about that are welcome.
>>
>>
>> Best regards,
>> Rainer
>>
>
> ___
> 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] New tag for major recipient postcodes

[Tom Pfeifer]

As these postcodes are kind of a virtual address that is not tied to a particular pysical location, 
my opinion would be _not to add them to OSM_, which is a geo database and not primarily a post code 
reference database.


Typically for those companies in DE, there is an additional physical address which has a different 
postcode for the street address, which is regularly tagged on the physical location.


tom

On 17.12.2017 13:42, Rainer wrote:

Hi all,

recently I came across postal codes in POI addresses, which aren't the classic scheme addr:postcode 
& addr:city & addr:street & addr:housenumber. However it is a special postcode that is assigned to 
recipients that receive a big amount of post every day, typically big companies or authorities. This 
kind of postcode is used only together with addr:city and does not require street and housenumber. 
So to say the post company has a big sack for post to that special postcode, puts in all the letters 
that are addressed to it and delivers the sack to the recipient.
After some discussion in the german user forum 
https://forum.openstreetmap.org/viewtopic.php?id=60421 I want to propose a tag for this kind of 
postcode and would like to discuss it here in the tagging mailing list.


The proposal is:  addr:postcode_major_recipient

It should be used on POIs, because it is an attribute of the company, authority or whatever, but not 
as an address of a building, because it is not assigned to such directly. Target is to have a 
separate tag for this kind of postcode to avoid a mix-up with the normal addr:postcode.


As I am not a native British English speaker, I have asked one and consulted the english page of the 
Deutsche Post. Reference: https://www.postdirekt.de/plzserver/PlzSearchServlet?lang=en_GB -> goto 
More -> Find major recipient


Probably similar kinds of postcodes exist also in other post companies in other countries, so inputs 
about that are welcome.



Best regards,
Rainer


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

[Tagging] New tag for major recipient postcodes

[Rainer]

Hi all,

recently I came across postal codes in POI addresses, which aren't the 
classic scheme addr:postcode & addr:city & addr:street & 
addr:housenumber. However it is a special postcode that is assigned to 
recipients that receive a big amount of post every day, typically big 
companies or authorities. This kind of postcode is used only together 
with addr:city and does not require street and housenumber. So to say 
the post company has a big sack for post to that special postcode, puts 
in all the letters that are addressed to it and delivers the sack to the 
recipient.
After some discussion in the german user forum 
https://forum.openstreetmap.org/viewtopic.php?id=60421 I want to propose 
a tag for this kind of postcode and would like to discuss it here in the 
tagging mailing list.


The proposal is:  addr:postcode_major_recipient

It should be used on POIs, because it is an attribute of the company, 
authority or whatever, but not as an address of a building, because it 
is not assigned to such directly. Target is to have a separate tag for 
this kind of postcode to avoid a mix-up with the normal addr:postcode.


As I am not a native British English speaker, I have asked one and 
consulted the english page of the Deutsche Post. Reference: 
https://www.postdirekt.de/plzserver/PlzSearchServlet?lang=en_GB -> goto 
More -> Find major recipient


Probably similar kinds of postcodes exist also in other post companies 
in other countries, so inputs about that are welcome.



Best regards,
Rainer

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

Re: [Tagging] New tag

[Paul Johnson]

On Wed, Jun 29, 2016 at 11:27 PM, Hans De Kryger 
wrote:

> How does everyone feel about (store_number=) for store numbers that
> companies assign their stores?
>

I generally use ref=* for the store number.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag

[Martin Koppenhoefer]

2016-06-30 10:23 GMT+02:00 Colin Smale :

> Are you suggesting that a shop object which is coterminous with a building
> outline should get its own polygon, sharing nodes between the two?



you could do it like this, but I'd rather use a multipolygon relation to
avoid overlapping ways. Some people use nodes inside the building polygon,
you can do this, but you loose the information of spatial extent.



> Instead of disambiguating the tags with a prefix/suffix like shop:ref and
> building:ref?



yes, rather than these "disambiguations" you can use standard tags if you
have everything structured well on a geometrical and logical level. The
need for these "disambiguations" already demonstrates there is something
wrong somewhere (IMHO). Similarly, we don't need bridge_name or bridge_ref
any more, since we started to have actual bridges (man_made=bridge) and not
just indirect bridges (by stating something is on a bridge).



> It is certainly an approach which has merit, but so do other approaches
> which are currently more widely used, such as tags with a prefix/suffix or
> mapping the "shop" to a node within the building polygon.



Yes, the node within the polygon is likely more used than (exactly)
overlapping polygons and multipolygon relations (have never counted this,
just a guess). I don't think that prefixes and suffixes are more frequently
used, but it is really difficult to tell precisely. Actually everything
could be expressed with prefixes and suffixes, so if you compare
"everything" to the cases with a suffix/prefix, they are clearly a small
minority ;-)

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

Re: [Tagging] New tag

[Hans De Kryger]

I apologize, i meant i would use (ref:shop=) just realized that. Read the
tag as (ref:shop=number)

But you guys have just won me over with your point of views. Will use
(ref=) in my project, thanks!

Regards,
Hans

Regards,
Hans

On Jun 30, 2016 12:59 AM, "Martin Koppenhoefer" 
wrote:

>
> 2016-06-30 9:51 GMT+02:00 Martin Koppenhoefer :
>
>> ref=* and shop=* -- 10567
>> ref:shop:num   -- 121
>> ref:shop   --2
>>
>
>
>
> and branch_ref   -- 7
> https://taginfo.openstreetmap.org/keys/branch_ref#overview
>
> 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] New tag

[Colin Smale]

On 2016-06-30 09:51, Martin Koppenhoefer wrote:

> If you put a ref on a shop it is clear that the ref refers to the shop. If it 
> isn't clear where the ref refers to (e.g. a building, another business or 
> amenity etc.) there is something wrong with the mapping and it combines 
> several objects from the real world into one osm object. You should then 
> separate these objects because also other tags might be ambiguous (e.g. name, 
> wikipedia. start_date).

Are you suggesting that a shop object which is coterminous with a
building outline should get its own polygon, sharing nodes between the
two? Instead of disambiguating the tags with a prefix/suffix like
shop:ref and building:ref? It is certainly an approach which has merit,
but so do other approaches which are currently more widely used, such as
tags with a prefix/suffix or mapping the "shop" to a node within the
building polygon. 

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

Re: [Tagging] New tag

[Martin Koppenhoefer]

2016-06-30 9:42 GMT+02:00 Andrew Errington :

> ref=* would be better, as it's already understood by a lot of other tools
> and renderers.



+1, also, ref is already referring to a number, so ref:store:num seems
unneccessarily complicated, so even if you should opt for a more structured
tag than "ref" you should likely use "ref:shop" and not "ref:shop:num".
(Another point: "num" sounds like "numeric", but maybe a shop ref goes
something like B45T, i.e. is alphanumeric).

I have looked at taginfo usage (worldwide). These are the current numbers:

ref=* and shop=* -- 10567
ref:shop:num   -- 121
ref:shop   --2

If you put a ref on a shop it is clear that the ref refers to the shop. If
it isn't clear where the ref refers to (e.g. a building, another business
or amenity etc.) there is something wrong with the mapping and it combines
several objects from the real world into one osm object. You should then
separate these objects because also other tags might be ambiguous (e.g.
name, wikipedia. start_date).

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

Re: [Tagging] New tag

[Andrew Errington]

ref=* would be better, as it's already understood by a lot of other tools
and renderers.

Andrew
On 30 Jun 2016 16:28, "Steve Doerr"  wrote:

> On 30/06/2016 05:27, Hans De Kryger wrote:
>
> How does everyone feel about (store_number=) for store numbers that
> companies assign their stores?
>
>
> Or perhaps branch_number?
>
> --
> Steve
>
>
> --
> [image: Avast logo] 
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com 
>
>
> ___
> 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] New tag

[Steve Doerr]

On 30/06/2016 05:27, Hans De Kryger wrote:

How does everyone feel about (store_number=) for store numbers that 
companies assign their stores?




Or perhaps branch_number?

--
Steve


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag

[Hans De Kryger]

(ref:shop:num) is what i plan on using. Just (ref=number) is not specific
enough to me

*Regards,*

*Hans*

On Wed, Jun 29, 2016 at 10:37 PM, Éric Gillet 
wrote:

> 2016-06-30 6:27 GMT+02:00 Hans De Kryger :
>
>> How does everyone feel about (store_number=) for store numbers that
>> companies assign their stores?
>>
>
> Why not use ref=* ?
>
> ___
> 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] New tag

[Éric Gillet]

2016-06-30 6:27 GMT+02:00 Hans De Kryger :

> How does everyone feel about (store_number=) for store numbers that
> companies assign their stores?
>

Why not use ref=* ?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] New tag

[Hans De Kryger]

Just found this https://wiki.openstreetmap.org/wiki/Key:ref:shop:num

had to search the wiki a second time

*Regards,*

*Hans*

On Wed, Jun 29, 2016 at 9:38 PM, Andrew Errington 
wrote:

> Use ref=*
>
> Would that work?
>
> Andrew
>
> On 30 June 2016 at 13:27, Hans De Kryger 
> wrote:
>
>> How does everyone feel about (store_number=) for store numbers that
>> companies assign their stores?
>>
>>
>> *Regards,*
>>
>> *Hans*
>>
>> ___
>> 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] New tag

[Andrew Errington]

Use ref=*

Would that work?

Andrew

On 30 June 2016 at 13:27, Hans De Kryger  wrote:

> How does everyone feel about (store_number=) for store numbers that
> companies assign their stores?
>
>
> *Regards,*
>
> *Hans*
>
> ___
> 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] New tag

[Hans De Kryger]

How does everyone feel about (store_number=) for store numbers that
companies assign their stores?


*Regards,*

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

[Tagging] New tag value in access? authorised [fork from: access in the wiki]

[althio forum]

/ DISCLAIMER /
Starting new thread for side topics from: [Tagging] access in the wiki


I would happily read more feedback from Martin and other contributors
on authorised because it would certainly help with some limited
traffic zone, bus lanes, residential streets...


 (2) proposing access=authorised

 Would another generic value like access=authorised allow a useful
 distinction from access=private?

Martin Koppenhoefer dieterdre...@gmail.com wrote:
 no, its the same

Quite a short answer and I am not convinced yet.

 private: Only with permission of the owner on an individual basis.
- Apply on a private road for residents, privately invited people,
very local delivery...;
it has some overlap with *=destination and *=delivery.
 authorised: Only with authorisation (from public authority) by regulations 
 (=collective basis) and special exemptions.
- Apply on a public road for special permits, emergency vehicles...;
it does often include emergency vehicles at least but it is not limited to them.
Anyway in most cases people wondering do I have access? simply do
not have access. If you have access you know it.

Did you look at some of the examples in the links [7,8,9,10]? I feel
private is not suitable there.
How are tagged today the real-world authorised vehicles exemptions
or signs with authorised vehicles only?
I don't think a bus lane with special exemptions for authorised
vehicles should be tagged motor_vehicle=private. Nor that private
can be used on any street or public road with no private 'owner'.

As I understand you consider that the 'public owner' (city or country
or whichever administrative level) can be viewed as the 'private owner
giving permission on an individual basis'. IMO that is quite a twisted
and misleading use of the words private/public.
So... did I miss something?


Martin Koppenhoefer dieterdre...@gmail.com wrote:
 this won't work (we should have vehicle specific tags, not general ones),
 and authorized as a value seems the same than private.

In the existing access scheme: tag-values can be applied to access=*
or to a specific transport mode tag-keys.
* [access=private] is valid
* [motorcar=private] is also valid
See also Tag:access=designated
 NOTE! The exact key/value combination access=designated should never appear 
 on an object. This page is here to describe the meaning of the 'designated' 
 access tag,

If I propose access=authorised I want to imply possibility of tagging
for [any_specific_mode]=authorised.
[access=authorised] or [motor_vehicle=authorised] could work.






[7] 
http://c8.alamy.com/comp/ABFKH9/red-white-bicycles-sign-blue-sticker-art-graffiti-excepte-vehicles-ABFKH9.jpg
[8] 
http://media-cache-ec0.pinimg.com/736x/e8/2d/45/e82d45efd50dad3fe23a9540fc52d09a.jpg
[9] 
https://www.sheffield.gov.uk/.imaging/stk/SCC-Home/standard-small/dms/scc/management/corporate-communications/images/roads-transport/roads-signs/signs/Bus-lane-cameras/document/Bus-lane-cameras-sign.jpg
[10] 
https://upload.wikimedia.org/wikipedia/commons/thumb/b/b4/Panneau_interdiction_sauf_v%C3%A9hicules_autoris%C3%A9s.JPG/337px-Panneau_interdiction_sauf_v%C3%A9hicules_autoris%C3%A9s.JPG

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

Re: [Tagging] New tag value in access? authorised [fork from: access in the wiki]

[Martin Koppenhoefer]

2014-12-05 9:57 GMT+01:00 althio forum althio.fo...@gmail.com:

 Did you look at some of the examples in the links [7,8,9,10]? I feel
 private is not suitable there.
 How are tagged today the real-world authorised vehicles exemptions
 or signs with authorised vehicles only?



they are tagged as access-mode=private

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

Re: [Tagging] New tag value in access? authorised [fork from: access in the wiki]

[althio forum]

On Fri, Dec 5, 2014 at 11:34 AM, Martin Koppenhoefer
dieterdre...@gmail.com wrote:


 2014-12-05 9:57 GMT+01:00 althio forum althio.fo...@gmail.com:

 Did you look at some of the examples in the links [7,8,9,10]? I feel
 private is not suitable there.
 How are tagged today the real-world authorised vehicles exemptions
 or signs with authorised vehicles only?

 they are tagged as access-mode=private

Thank you for the clarification.
Though my question was half-rhetorical.
My main point is then in the sentence right after:

 How are tagged today the real-world authorised vehicles exemptions
 or signs with authorised vehicles only?

 they are tagged as access-mode=private

 I don't think a bus lane with special exemptions for authorised
 vehicles should be tagged motor_vehicle=private. Nor that private
 can be used on any street or public road with no private 'owner'.

To sum up:
'private' is used, I find it inadequate.

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

[Tagging] New tag proposal Amenity=meditation centre

[dies38061]

(reply to message at 
http://lists.openstreetmap.org/pipermail/tagging/2012-September/011278.html )

I am wondering whether this tag might be used for something like Christian 
Science Reading Room locations.  Though not really a 'meditation center', such 
a location aims to provide an alternative to a formal church for people of a 
particular faith to gather. --ceyockey

Christian Science Reading Room on Wikipedia -- 
http://en.wikipedia.org/wiki/Christian_Science_Reading_Room 

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

Re: [Tagging] New tag proposal Amenity=meditation centre

[Serge Wroclawski]

Christian Science Reading rooms have very little, if anything to do
with medication centers.

- Serge

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

Re: [Tagging] New tag proposal Amenity=meditation centre

[Martin Vonwald]

Am 15.09.2012 um 15:56 schrieb Serge Wroclawski emac...@gmail.com:

 medication centers

MediCation center ? ;-)

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

Re: [Tagging] New tag proposal Amenity=meditation centre

[John F. Eldredge]

Serge Wroclawski emac...@gmail.com wrote:

 Christian Science Reading rooms have very little, if anything to do
 with medication centers.
 

We aren't discussing medication centers, but rather meditation centers (or 
centres, to use the British spelling).
-- 
John F. Eldredge --  j...@jfeldredge.com
Reserve your right to think, for even to think wrongly is better than not to 
think at all. -- Hypatia of Alexandria

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

Re: [Tagging] New tag proposal Amenity=meditation centre

[Johan Jönsson]

Michael P pancoma@... writes:

 
 
 
 I believe I created a new proposal discussion page 
at: http://wiki.openstreetmap.org/wiki/Meditation_centre_tag
 
 
 
A good initiative of you to create a tag for these places. It should be of 
interest for mappers to tag this feature.

To formalize this there is need for a definition and a tag, both of which 
there could be some discussion.

My guess is that there are other names for meditation centres and that there 
might be some confusion if it is only those explicitly named centres that 
should have this tag or if there is some kind of requirement of size or 
accessability.

Two alternative taggings to amenity=meditation_centre could be 
amenity=place_of_meditation (obviously copied from amenity=place_of_worship) 
or when we are at it maybe amenity=meditation.

There are probably many views on meditation, but without knowing much about it 
I guess the different forms and uses of meditation could be explained with 
further tagging of different attributes on the same feature. I can mention 
that there are a proposal on how to tag the healthcare-oriented meditation 
http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0

Good luck






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

Re: [Tagging] New tag proposal Amenity=meditation centre

[Martin Koppenhoefer]

2012/9/2 Michael P panc...@gmail.com:
 Apologies for the newcomer defects, Im still trying to get the hang of wikis
 and editing in opensteetmap. Any help would be appreciated if I can be shown
 the mistakes and/or suggestions to improve my participation.

 I believe I created a new proposal discussion page at:
 http://wiki.openstreetmap.org/wiki/Meditation_centre_tag


Thank you for creating a proposal. IMHO the proposed namespace
(amenity) could work well for your subject. I suggest you align your
syntax to the general tagging syntax (no capital letters, no spaces in
formal tags), so
Amenity=Meditation Centre
would become
amenity=meditation_centre (or place_of_meditation like Johan suggested).

it is also desirable to have proposals in the proposal namespace in
the wiki (an URL starting with
http://wiki.openstreetmap.org/wiki/Proposed_features/.. ), so it
gets instantly clear that it is a proposal.

You can find more information how a proposal should look like here:
http://wiki.openstreetmap.org/wiki/Proposed_features/
and here
http://wiki.openstreetmap.org/wiki/Creating_a_proposal

cheers,
Martin

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