Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema

[Frederik Ramm]

Hi,

On 05/22/2015 06:12 AM, Blake Girardot wrote:
> OSM is about mapping what is important to people

AND on the ground. Important alone doesn't suffice.

> and believe me, if the 
> only bridge for 50km is out that is important to me and others.

Yes, of course. If there is no bridge left at all then we'd simply
delete - or refrain from mapping - the bridge (rather than create an
object saying there was a bridge but it's gone now).

Incidentally this means that OSM is not suitable for use cases like
"let's plot all the damage done by disaster " because if the damage
is obliteration then there will be nothing in OSM that we can plot.

I can see how drawing maps that detail the damage done by a certain
disaster event is an interesting use case but I don't see this within
the realm of OSM.

If a broken bridge remains, then we can map a broken bridge. If a civil
engineer looks at the bridge and is able to further specify the state
the bridge is in - for example to allow others to estimate how big the
repair effort might be - that's also an observable fact that could be
mapped.

Whether the bridge was broken by a hurricane or an earthquake or in a
war, will often not be easy to discern on the ground. Therefore I view a
tag that details the event which broke the bridge, and when that event
happened, as problematic.

This doesn't mean this is not important to people, for example if the
bridge was damaged by a disaster then relief funds might be allocated
for repair, whereas if the bridge just crumbled on its own accord then
no funds might be available.

But this already shows that if we deviate from our usual course of "map
what's on the ground", we risk getting involved in politics. "This
bridge was broken even before the quake!" "No it wasnt!" "Yes it was,
you know full well that lorries always had to take the detour" - Surely
it is not for OSM to (help) decide whether relief funds are used to
repair a certain bridge...

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema

[Martin Koppenhoefer]

> Am 22.05.2015 um 09:04 schrieb Frederik Ramm :
> 
> Yes, of course. If there is no bridge left at all then we'd simply
> delete - or refrain from mapping - the bridge (rather than create an
> object saying there was a bridge but it's gone now).
> 
> Incidentally this means that OSM is not suitable for use cases like
> "let's plot all the damage done by disaster " because if the damage
> is obliteration then there will be nothing in OSM that we can plot.


it depends on the structure of the bridge but if it is/was a stone bridge or 
steel or concrete (i.e. a big serious bridge) it will typically not completely 
vanish, even if heavily damaged and temporarily unusable the situation will 
still be very different to no bridge at all (repairing will often be possible 
and done, and be much less work compared to starting from scratch, eg 
foundations)

Few here will remember WW II ;-) but we all know the pictures.
In 1945, Germany, after the war, reconstruction was less work than starting 
from scratch because even if it looked like total destruction, the streets 
impassable and blocked by rubble, but the sewage system, underground 
infrastructure, overground city layout, were still mostly sane, and allowed for 
much faster reconstruction than new development of a settlement would have 
been. Actually more buildings and structure has break destroyed in the time 
after the war (50ies/60ies) with the will of modernization than had been 
destroyed in the war.

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

Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema

[Warin]

On 22/05/2015 5:32 PM, Martin Koppenhoefer wrote:





Am 22.05.2015 um 09:04 schrieb Frederik Ramm :

Yes, of course. If there is no bridge left at all then we'd simply
delete - or refrain from mapping - the bridge (rather than create an
object saying there was a bridge but it's gone now).

Incidentally this means that OSM is not suitable for use cases like
"let's plot all the damage done by disaster " because if the damage
is obliteration then there will be nothing in OSM that we can plot.


The undamaged sections can be plotted in OSM .. the missing sections can be 
added when they are repaired/replaced.
If a bridge is damaged .. then the road remains and can be plotted.



it depends on the structure of the bridge but if it is/was a stone bridge or 
steel or concrete (i.e. a big serious bridge) it will typically not completely 
vanish, even if heavily damaged and temporarily unusable the situation will 
still be very different to no bridge at all (repairing will often be possible 
and done, and be much less work compared to starting from scratch, eg 
foundations)

Few here will remember WW II ;-) but we all know the pictures.
In 1945, Germany, after the war, reconstruction was less work than starting 
from scratch because even if it looked like total destruction, the streets 
impassable and blocked by rubble, but the sewage system, underground 
infrastructure, overground city layout, were still mostly sane, and allowed for 
much faster reconstruction than new development of a settlement would have 
been. Actually more buildings and structure has break destroyed in the time 
after the war (50ies/60ies) with the will of modernization than had been 
destroyed in the war.



For much the same reason .. things damaged will be repaired/replaced.
The reasons why those things were there are the reasons why they will reappear 
in the same place. Possibly better built.

Some years ago there was a bushfire near me. It burnt out quite a few old 
wooden bridges.
Those roads were closed for quite some time. But the bridges were replaced.. 
this time with concrete ones .. new foundations included.
The bridges are in the same locations, they may have moved 1 metre .. and might 
be a bit wider, guard rails further apart, but in general the same.
Much quicker and cheaper to repair/replace sections that are damaged than place 
a new road + bridges elsewhere.

Under those conditions .. marking something damaged maybe best practice.
When the repair/replacement is completed OSM can remove the tagging of damaged.




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

Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema

[Martin Koppenhoefer]

2015-05-22 12:14 GMT+02:00 Warin <61sundow...@gmail.com>:

> Much quicker and cheaper to repair/replace sections that are damaged than
> place a new road + bridges elsewhere.




yes, also because typically there has been a reason why a certain spot has
been chosen for the bridge (topography, river width etc.) so even if
literally nothing would have remained there is still high probability that
a new bridge would be built at the same location (also because of the
street), unless the spot had originally been chosen badly and this would
now be corrected.

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

Re: [Tagging] Water featuers

[Andy Mabbett]

On 15 May 2015 at 12:25, pmailkeey .  wrote:

> 'Pond' seems to fit the bill:

No, it does not.

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

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

Re: [Tagging] Water featuers

[Andy Mabbett]

On 15 May 2015 at 16:40, Janko Mihelić  wrote:

> Wiki suggests natural=water + water=reflecting_pool:

Cascades, by their very nature, are not suitable for reflecting as the
water is agitated. There may also be no horizontal surface to speak
of.

> Maybe water=cascade could be the right fit.

Probably, but I'd like more opinions; and other options - cascades are
just one example.

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

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

Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema

[Richard Z.]

On Thu, May 21, 2015 at 09:52:06PM -0700, Bryce Nesbitt wrote:
> Note that just because you can collect some data, does not make it a good
> idea to put in OSM.  Maintenance is harder than collection: and who's going
> to go back three years after the HOT event and clean up?

same is even worse with other data like phone=*


Richard

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

Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema

[Richard Z.]

On Thu, May 21, 2015 at 09:36:10PM +0200, Andreas Goss wrote:
> As you linked to this on the HOT list a few things noticed...
> 
> 
> What about the typhoon:, earthquake: or tsunami: tags? Replaced with
> damage:event?
> 
> What about e.g. damage:building? This could still be used even if you have
> building= and damage=
> 
> What about the status= and impassable= keys and tags?

some of the lifycecle prefixes would fit this situation and are already
documented and in use.
http://wiki.openstreetmap.org/wiki/Lifecycle_prefix

Richard

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

Re: [Tagging] Water featuers

[Martin Koppenhoefer]

> Am 22.05.2015 um 12:28 schrieb Andy Mabbett :
> 
> Cascades, by their very nature, are not suitable for reflecting as the
> water is agitated.


maybe this is a language issue, I would have thought they would reflect anyway 
but you wouldn't see a clear picture (I agree that reflection_pool is not the 
right term nonetheless, nor does the wiki suggest so)


> 
>> Maybe water=cascade could be the right fit.
> 
> Probably, but I'd like more opinions; and other options - cascades are
> just one example.


what are the other examples? We cannot propose tags if you don't say what you 
want to tag ;-)


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

Re: [Tagging] Water featuers

[Andy Mabbett]

On 22 May 2015 at 12:03, Martin Koppenhoefer  wrote:

> what are the other examples? We cannot propose tags if you don't say what you 
> want to tag ;-)

"man-made, ornamental water features, which are not fountains"

These might be cascades, rills, reflecting-pools, rain-chains, moats, etc.

We might, for example, have:

   natural=water
   water=cascde

etc. - but not:

   water=fountain

as we already have

   amenity=fountain

or we could have:

   amenity=cascade



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

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

Re: [Tagging] Water featuers

[Martin Koppenhoefer]

> Am 22.05.2015 um 13:35 schrieb Andy Mabbett :
> 
> These might be cascades, rills, reflecting-pools, rain-chains, moats, etc.
> 
> We might, for example, have:
> 
>   natural=water
>   water=cascde
> 
> etc. - but not:
> 
>   water=fountain
> 
> as we already have
> 
>   amenity=fountain
> 
> or we could have:
> 
>   amenity=cascade


where's the problem then? add natural =water to all water areas and specify 
further with water=* (cascade, rill, rain-chain, ...)
As we have seen, the current wiki docu doesn't detail these kind of features so 
feel free to propose an addition

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

Re: [Tagging] Damage Assessment Tags - Would like feedback on a schema

[Blake Girardot]

These replies are all very helpful, thank you very much.

On 5/22/2015 9:04 AM, Frederik Ramm wrote:


Whether the bridge was broken by a hurricane or an earthquake or in a
war, will often not be easy to discern on the ground. Therefore I view a
tag that details the event which broke the bridge, and when that event
happened, as problematic.


The intention of the damage:event=* or maybe disaster:event=*  tag 
doesn't have much to do with assigning causation, and has more to do 
with tag maintenance. We want to be able to run projects that get 
objects that were tagged with an event related tag to review, revise or 
remove them.


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

Re: [Tagging] Water featuers

[Richard Z.]

On Fri, May 22, 2015 at 02:00:30PM +0200, Martin Koppenhoefer wrote:
> 
> 
> 
> 
> > Am 22.05.2015 um 13:35 schrieb Andy Mabbett :
> > 
> > These might be cascades, rills, reflecting-pools, rain-chains, moats, etc.
> > 
> > We might, for example, have:
> > 
> >   natural=water
> >   water=cascde
> > 
> > etc. - but not:
> > 
> >   water=fountain
> > 
> > as we already have
> > 
> >   amenity=fountain
> > 
> > or we could have:
> > 
> >   amenity=cascade

I am uncomfortable with "cascade" - in several languages it
means "waterfall" so there is considerable potential for 
confusion.

Richard

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

Re: [Tagging] Water featuers

[John F. Eldredge]

The water feature we are talking about here is an artificial waterfall, 
usually pump-driven.




On May 22, 2015 9:19:44 AM "Richard Z."  wrote:


On Fri, May 22, 2015 at 02:00:30PM +0200, Martin Koppenhoefer wrote:
>
>
>
>
> > Am 22.05.2015 um 13:35 schrieb Andy Mabbett :
> >
> > These might be cascades, rills, reflecting-pools, rain-chains, moats, etc.
> >
> > We might, for example, have:
> >
> >   natural=water
> >   water=cascde
> >
> > etc. - but not:
> >
> >   water=fountain
> >
> > as we already have
> >
> >   amenity=fountain
> >
> > or we could have:
> >
> >   amenity=cascade

I am uncomfortable with "cascade" - in several languages it
means "waterfall" so there is considerable potential for
confusion.

Richard

___
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] Water featuers

[Dave Swarthout]

I am uncomfortable with "cascade" - in several languages it
means "waterfall" so there is considerable potential for
confusion.

I agree. A cascade is a waterfall in American English.

On Fri, May 22, 2015 at 7:18 AM, Richard Z.  wrote:

> On Fri, May 22, 2015 at 02:00:30PM +0200, Martin Koppenhoefer wrote:
> >
> >
> >
> >
> > > Am 22.05.2015 um 13:35 schrieb Andy Mabbett  >:
> > >
> > > These might be cascades, rills, reflecting-pools, rain-chains, moats,
> etc.
> > >
> > > We might, for example, have:
> > >
> > >   natural=water
> > >   water=cascde
> > >
> > > etc. - but not:
> > >
> > >   water=fountain
> > >
> > > as we already have
> > >
> > >   amenity=fountain
> > >
> > > or we could have:
> > >
> > >   amenity=cascade
>
> I am uncomfortable with "cascade" - in several languages it
> means "waterfall" so there is considerable potential for
> confusion.
>
> Richard
>
> ___
> 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] Water featuers

[Richard Z.]

On Fri, May 22, 2015 at 09:26:34AM -0500, John F. Eldredge wrote:
> The water feature we are talking about here is an artificial waterfall,
> usually pump-driven.

in that case it might be better to either use normal waterfall tagging 
   node with waterway=waterfall+ way waterway=weir, 
   possibly also waterway=dam and man_made=yes
or a distinct tag which is not so easy to confuse as synonymous.

Richard

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

Re: [Tagging] Water featuers

[Andy Mabbett]

On 22 May 2015 at 15:29, Dave Swarthout  wrote:
> I am uncomfortable with "cascade" - in several languages it
> means "waterfall" so there is considerable potential for
> confusion.
>
> I agree. A cascade is a waterfall in American English.

How, then would you describe:


https://commons.wikimedia.org/wiki/File:Water_Feature_in_Cabot_Place,_Canary_Wharf_%282%29_-_geograph.org.uk_-_1472986.jpg
?

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

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

Re: [Tagging] Water featuers

[Andy Mabbett]

On 22 May 2015 at 15:54, Andy Mabbett  wrote:

> How, then would you describe:

Or these:

   
https://commons.wikimedia.org/wiki/File:Site_of_Priory_Mill_-_geograph.org.uk_-_288573.jpg

   
https://commons.wikimedia.org/wiki/File:Luxury_apartments,_Dickens_Heath_Village,_Solihull_-_geograph.org.uk_-_1720292.jpg

   
https://commons.wikimedia.org/wiki/File:CASCADING_FOUNTAIN,_FROM_FRONT,_CLOSER_-_Harold_Lloyd_Estate,_Beverly_Hills,_Los_Angeles_County,_CA_HABS_CAL,19-BEVHI,2-18.tif

   https://commons.wikimedia.org/wiki/File:20070616_Crown_Fountain_%287%29.JPG


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

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

[Tagging] shop=supplements => shop=dietary_supplements

[Andreas Goss]

Just found the proposal for shop=supplements.

http://wiki.openstreetmap.org/wiki/Proposed_features/supplements

On the talk page already a lot of people suggested using 
shop=nutrition_supplements instead.


But looking at Wikipedia and google it seems like 
shop=dietary_supplements would be even more fitting.


What do you think?
__
openstreetmap.org/user/AndiG88
wiki.openstreetmap.org/wiki/User:AndiG88‎


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

Re: [Tagging] Water featuers

[Dave Swarthout]

How about fountain_cascade or waterfall_artificial?

It's a tricky proposition.

On Friday, May 22, 2015, Andy Mabbett  wrote:

> On 22 May 2015 at 15:54, Andy Mabbett  > wrote:
>
> > How, then would you describe:
>
> Or these:
>
>
> https://commons.wikimedia.org/wiki/File:Site_of_Priory_Mill_-_geograph.org.uk_-_288573.jpg
>
>
> https://commons.wikimedia.org/wiki/File:Luxury_apartments,_Dickens_Heath_Village,_Solihull_-_geograph.org.uk_-_1720292.jpg
>
>
> https://commons.wikimedia.org/wiki/File:CASCADING_FOUNTAIN,_FROM_FRONT,_CLOSER_-_Harold_Lloyd_Estate,_Beverly_Hills,_Los_Angeles_County,_CA_HABS_CAL,19-BEVHI,2-18.tif
>
>
> https://commons.wikimedia.org/wiki/File:20070616_Crown_Fountain_%287%29.JPG
>
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> 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] Damage Assessment Tags - Would like feedback on a schema

[Warin]

On 22/05/2015 8:54 PM, Richard Z. wrote:

On Thu, May 21, 2015 at 09:52:06PM -0700, Bryce Nesbitt wrote:

Note that just because you can collect some data, does not make it a good
idea to put in OSM.  Maintenance is harder than collection: and who's going
to go back three years after the HOT event and clean up?

same is even worse with other data like phone=*




I think the data should be entered.
It reflects what is on the ground now.
While HOT is going on (and that may be some months) corrections and updating 
will take place.

In the longer term OSM users will correct/maintain data .. the time period of 
corrections/maintance simply reflects the rate of use in that area.


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

[Tagging] Airport power and USB stations

[Dave Swarthout]

I'm sitting in the Seattle airport trying to figure out how to tag areas
that offer a power outlet and USB outlets for charging or powering
computers and other devices. There are many of them here at SEA and they
are important places for travelers to know about. I tagged a few of them
with amenity=charging_station until I realized that those charging_stations
are for vehicles.

Ideas? Prexisting tags?

Dave (Sleepless in Seattle)
-- 
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] Airport power and USB stations

[pmailkeey .]

On 23 May 2015 at 00:19, Dave Swarthout  wrote:

>
> I'm sitting in the Seattle airport trying to figure out how to tag areas
> that offer a power outlet and USB outlets for charging or powering
> computers and other devices. There are many of them here at SEA and they
> are important places for travelers to know about. I tagged a few of them
> with amenity=charging_station until I realized that those charging_stations
> are for vehicles.
>
> Ideas? Prexisting tags?
>
> Dave (Sleepless in Seattle)
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
>
A charging station is a place for charging something. With recent
discussions on amenity, Why not use

charging_station=USB
charging_station=EV
charging_station=110VAC
charging_station=240VAC

etc.
-- 
Mike.
@millomweb  -
For all your info on Millom and South Copeland
via *the area's premier website - *

*currently unavailable due to ongoing harassment of me, my family, property
& pets*

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

Re: [Tagging] shop=supplements => shop=dietary_supplements

[pmailkeey .]

On 22 May 2015 at 16:05, Andreas Goss  wrote:

> Just found the proposal for shop=supplements.
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/supplements
>
> On the talk page already a lot of people suggested using
> shop=nutrition_supplements instead.
>
> But looking at Wikipedia and google it seems like shop=dietary_supplements
> would be even more fitting.
>
> What do you think?
> __
> openstreetmap.org/user/AndiG88
> wiki.openstreetmap.org/wiki/User:AndiG88‎
>
>
>
Is this the sort of thing 'health food' shops sell ?

Mike.
@millomweb  -
For all your info on Millom and South Copeland
via *the area's premier website - *

*currently unavailable due to ongoing harassment of me, my family, property
& pets*

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

Re: [Tagging] housenumber on node and area

[pmailkeey .]

On 22 May 2015 at 07:35, Martin Koppenhoefer  wrote:

>
>
>
>
> > Am 21.05.2015 um 23:53 schrieb pmailkeey . :
> >
> > Tag the building with street address and add an ent/exit node to mark
> the entrance.
>
>
> have a look at these housenumbers, they're 5 and 7 for this side of the
> building (one big hotel), but the main address is from the main street
> (front of the buikding) and is different.
>
> https://lists.openstreetmap.org/pipermail/talk-it/attachments/20150520/465c45fc/attachment-0001.jpg
>
>
> I'm not even sure whether both of these are doors or just one
>
>
>
need more info - Google streetview link?

Here in uk doors may not have a 'letterbox' aka "point of delivery" and as
such, Royal Mail would not assign those as addresses. '5' and '7' may not
be house numbers but key numbers or internal ref numbers - or 'private'
access doors to 'facility rooms' allowing hirers independent access without
using the main entrance. I suggest you leave them untagged until you know
what they are to avoid putting erroneous info on the map.

-- 
Mike.
@millomweb  -
For all your info on Millom and South Copeland
via *the area's premier website - *

*currently unavailable due to ongoing harassment of me, my family, property
& pets*

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

Re: [Tagging] Airport power and USB stations

[Bryce Nesbitt]

Duck tagging it's not.  One could consider the horrors of tagging:



*amenity=charging_stationvoltage=5socket:usb=4*


>From http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcharging_station
But I think that's just as bad an idea as amenity=fuel;vehicle=no.



Better:

*amenity=device_charging_station*

*socket:nema_5_15=2*
*socket:USB=4*


I don't care that amenity is "overloaded".  This is an amenity.



And even better:


*amenity=device_charging_station*
*socket:ac=2*
*socket:usb=4 *  (there are two types Android and Apple, but I gloss over
that)
*socket:apple_30_pin=4*


And someone who cares can invent subtypes for "ac" like "sev_1011",
or worse set something for multi standard sockets:
http://fam-oud.nl/~plugsocket/MultiSockets.html

And subtypes for USB, as there are at least three types of charging port,
and a a dozen types overall.

These days world voltage adapters are all one can buy: the 110V vs. 220V
debate is over.  So no voltage tag needed.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] housenumber on node and area

[Ross]

On 21/05/15 20:16, pmailkeey . wrote:



On 21 May 2015 at 02:08, Ross > wrote:




On 21/05/15 09:51, pmailkeey . wrote:



On 20 May 2015 at 14:10, André Pirard mailto:a.pirard.pa...@gmail.com>> wrote:

Hi,

We know that addr:housenumber
=* can be tagged
on nodes

and that it's very convenient.


But wrong.


Why?  It's all very well that this may be you opinion but the wiki
and accepted practice says otherwise.



Address = building = area, not node. It's 'accepted' as a second best 
option for where a building hasn't been drawn. I find quite a lot of 
them and remove them by transferring the data to the buildings - 
sometimes there's a building and a loose node containing the same 
data! In those cases, a simple node deletion is required.




Where is it accepted?

Australian addresses refer to the property only and a property may have 
several buildings.


I can show you plenty of locations where there is no building but it 
still has an address, or the property is so large that the access from 
the street/road is 50km from the only building on the property and if 
you were routing to the address you'd never get there if the address was 
on the building.


As someone else also pointed out, accepted practice in different 
countries varies.


Open address data in Australia is point (node) data and specifies what 
type of address it is, eg "Driveway frontage", "Building Centroid", 
"Property Centroid", "Property Access Point", to name a few.


The most significant of these is the "Property Access Point" it tends to 
occur where a property has an address in one street but because of 
different reasons (cliff, drainage, etc) the actual access is from 
another street, usually via a right of way.


IMO addresses should be on nodes only and should show were you access 
the property (type "Driveway frontage", "Property Access Point", 
"Building Access Point") without anything else on the node. This way 
when you use a router it takes you to where you access the property.  
This also covers the accessibility issues for disabled access.


Cheers
Ross

--
Mike.
@millomweb 
 - For all 
your info on Millom and South Copeland

via *the area's premier website - *
*
*
*currently unavailable due to ongoing harassment of me, my family, 
property & pets*

*
*
T&Cs 


___
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] Airport power and USB stations

[Warin]

On 23/05/2015 9:56 AM, Bryce Nesbitt wrote:

Duck tagging it's not.  One could consider the horrors of tagging:

*amenity=charging_station
voltage=5
socket:usb=4*


From http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcharging_station
But I think that's just as bad an idea as amenity=fuel;vehicle=no.



Better:

*amenity=device_charging_station*
*socket:nema_5_15=2
*
*socket:USB=4*


I don't care that amenity is "overloaded".  This is an amenity.



And even better:


*amenity=device_charging_station*
*socket:ac=2*
*socket:usb=4 *  (there are two types Android and Apple, but I
gloss over that)
*socket:apple_30_pin=4*


And someone who cares can invent subtypes for "ac" like "sev_1011",
or worse set something for multi standard sockets: 
http://fam-oud.nl/~plugsocket/MultiSockets.html 






And there is this ...

http://wiki.openstreetmap.org/wiki/Key:power_supply

power_supply=nema_5_15 for usa...

There is no USB one there (yet) ..usb_typea, usb_typeb etc... ?

it is not a proposal as yet .. but does not identify it self as vehicle related.
Charging points are avlible in some libraries too ..

Might be time to move thetag power_supply= to a proposal.

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

Re: [Tagging] Airport power and USB stations

[Dave Swarthout]

Thanks for the great suggestions.  I'm typing on an iPhone so will respond
fully after I reach my final destination.

amenity=charging_station with subtags for clarification seems to fill the
bill.

On Friday, May 22, 2015, Warin <61sundow...@gmail.com> wrote:

>  On 23/05/2015 9:56 AM, Bryce Nesbitt wrote:
>
>  Duck tagging it's not.  One could consider the horrors of tagging:
>
>
>
> *amenity=charging_station voltage=5 socket:usb=4*
>
>
> From http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dcharging_station
> But I think that's just as bad an idea as amenity=fuel;vehicle=no.
>
>
> 
>
>  Better:
>
>  *amenity=device_charging_station*
>
> *socket:nema_5_15=2 *
> *socket:USB=4*
>
>
>  I don't care that amenity is "overloaded".  This is an amenity.
>
>
>
>  And even better:
>
>
>   *amenity=device_charging_station*
>  *socket:ac=2*
>  *socket:usb=4 *  (there are two types Android and Apple, but I gloss
> over that)
>  *socket:apple_30_pin=4*
>
>
>  And someone who cares can invent subtypes for "ac" like "sev_1011",
> or worse set something for multi standard sockets:
> http://fam-oud.nl/~plugsocket/MultiSockets.html
>
>
>
> And there is this ...
>
> http://wiki.openstreetmap.org/wiki/Key:power_supply
>
> power_supply=nema_5_15 for usa...
>
> There is no USB one there (yet) ..usb_typea, usb_typeb etc... ?
>
> it is not a proposal as yet .. but does not identify it self as vehicle 
> related.
> Charging points are avlible in some libraries too ..
>
> Might be time to move the tag power_supply= to a proposal.
>
>

-- 
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] Airport power and USB stations

[Bryce Nesbitt]

On Fri, May 22, 2015 at 9:34 PM, Dave Swarthout 
wrote:

> Thanks for the great suggestions.  I'm typing on an iPhone so will respond
> fully after I reach my final destination.
>
> amenity=charging_station with subtags for clarification seems to fill the
> bill.
>
>
I think that's a choice with high long term costs to rendering and
processing engines.

What will happen is that you're asking rendering and processing software to
keep up with a blizzard of subtags.
"charging_station" presently is understood to mean a vehicle charging
station,
not a generic charging station.  Suddenly icons designed for vehicle
charging will start appearing inside airports.

Similarly:

power_supply=cee_17_red
power_supply=cee_7_4
power_supply=usb


forces rendering to understand a long series of values.  For an AC wall
plug that means understanding
that  nema_5_15 sev_1011 and cei_23_16 are all types of AC wall plugs, but
that USB is something different.
It's asking too much from the maintainers of rendering software.



If you're mapping a duck, call it a duck  not a
creature=thing_with_feathers legs=2 quacking=yes.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging