Re: [Tagging] New tag for major recipient postcodes

2017-12-22 Thread 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] Feature Proposal - RFC - (Fire Hydrant Extensions (part 3))

2017-12-22 Thread Moritz 

Hi François,
Am 2017-12-20 19:00, schrieb François Lacombe:

2017-12-20 12:21 GMT+01:00 Moritz :



I disagree, that would make the proposal useless. Then only wrench and
check_date would be left.



That wasn't my point.
pump=yes can stay in the proposal


I misunderstood that.


But pumps tagging is far more complex than values you propose.
Facts are it's difficult to change established values and I'm not so 
keen

on voting them without further thinking.


I agree. But adding the tags like Viking proposed

pump=yes|powered
pump:driven_by=electricity|water.

would not change the any established tags, only add some additional 
keys.


I don't want to open a new proposal process for pumps just for having 
better hydrants tags.

If we would change establiched values it would make sense.

But for now it would only add overhead.

Moritz



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

Re: [Tagging] Feature Proposal - RFC - (Fire Hydrant Extensions (part 3))

2017-12-22 Thread Moritz 

Hi Viking,



Am 2017-12-21 10:20, schrieb Viking:

Hi all.
First of all I invite to put comments also on discussion page [0],
because it remains a trace useful for voting decisions.
We don't need a detailed description for pumps, we need to know only
if there is a pump connected (or inside) the water reserve and if it
is electrical or water driven.

+1

All other pump details can be developed in a separate proposal by
someone else if he/she has reasons to do that.

+1

Key pump already exists for water wells: [1], [2]
Values for our use can be pump=yes or pump=powered.
Also pump:type already exists, but if you think it is too generic, we
can introduce pump:driven_by=electricity/water.


Could be.

or
pump:powered_by=electricity|water


pump:power_medium sounds less clear to me: what do you think?


Yes, not the best option.

Moritz
 [0]
 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Fire_Hydrant_Extensions_(part_3)

 [1] https://wiki.openstreetmap.org/wiki/Key:pump
 [2] https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_well

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