Re: [Tagging] man_made=snow_net vs man_made=snow_fence vs barrier=fence?

[Martin Koppenhoefer]

sent from a phone

> On 26. Jul 2019, at 15:38, Joseph Eisenberg  
> wrote:
> 
> Would you suggest removing both man_made=snow_net and man_made=snow_fence
>  from the curated list in Map Features?


there are almost 3000 man_made=snow_fence in the db, but only 150 snow nets. I 
would keep the former and require a proposal to change it, but I believe we 
could drop the snow net for now and convert it into a proposal.

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

Re: [Tagging] Feature man_made=offshore_platform?

[Mateusz Konieczny]

26 Jul 2019, 15:35 by joseph.eisenb...@gmail.com:

> The feature man_made=offshore_platform was created as a wiki page and
> then added to Map features, apparently without discussion, at some
> point in the past.
>
> It didn't have a very complete wiki page, but it looks like this is
> mainly meant for offshore oil and gas drilling/production platforms -
> I've just added a longer description.
>
> It's only been used 400 times.
>
> Should this tag be kept in Map features?
>
Is there any other tagging scheme with
comparable popularity for this feature?

If no - it certainly should stay listed.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature man_made=offshore_platform?

[Martin Koppenhoefer]

IMHO we should not question a tag just because it hasn't been discussed and
voted, 400 uses of an offshore platform tag doesn't seem few, in the world "the
number of oil platforms is expected to rise from 389 in 2010 to almost 500
in 2017". The sum of the region figures adds up to 1300 something for 2018,
https://www.statista.com/statistics/279100/number-of-offshore-rigs-worldwide-by-region/

man_made=offshore_platform seems ok to me, although the definition isn't
very mature yet.

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

Re: [Tagging] Tagging remain of extinct volcanoes

[Joseph Eisenberg]

It's fine that some training and knowledge is required to properly tag
features in OSM. For example, it takes some experience or wiki
research to learn the difference between natural=heath (dwarf shrubs)
and natural=scrub (shurbland), or wetland=bog and wetland=marsh.

However, a mapper who visits a particular place, and reads the OSM
wiki carefully, should be able to clearly distinguish between the two
types of vegetation. Similarly, the definition of natural=volcano
should be clear and practical enough to determine.

A mapper doesn't need to be a geologist to know that a mountain is a
volcano if it is active or dormant: climbing up to the crater may
reveal smoking or steaming fumaroles with nasty sulfur odor, and the
shape of the crater or volcanic vent is distinctive.

But even a geologist won't be able to distinguish a heavily-eroded,
extinct volcano by just visiting the area one time. Often this
requires digging into the ground and studying the buried layers of
rock in several locations.

If the only way to know that a certain peak was once formed by
volcanic activity is that you have to go to a library and read an
article in an old geology journal, then we are adding definitions to
tags that don't fit the OSM way of checking for real, current things.

Wikipedia is based on citations of other people's research, and
depends on trusting that the findings of experts in the field are
correct. Original research gets you a warning.

On the contrary OSM is based on real, current, local information that
can be confirmed to be true or false: it's primary research by
ordinary mappers.

Not everything that is published, not everything that can be cited in
Wikipedia, is suitable to be mapped and tagged in OSM.

Joseph

On 7/25/19, Martin Koppenhoefer  wrote:
>
>
> sent from a phone
>
>> On 25. Jul 2019, at 09:47, Paul Allen  wrote:
>>
>> If we limit ourselves to what a mapper without
>> much knowledge of geology can verify for him/herself then we limit the
>> mapping of
>> volcanoes to those with visible lava lakes.
>
>
> In all fields of information where we map you need to have knowledge to
> understand and describe what you are seeing.
>
> Sometimes more specific knowledge is required, sometimes we consider it
> general knowledge. If you don’t know traffic rules and signs you can’t
> verify many road tags or turn restrictions, etc., still we don’t require a
> driving license from mappers and we don’t bother as long as someone doesn’t
> change tagging in a field where he doesn’t have the required knowledge.
>
> 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] [Indoor] is indoor=level walled ?

[Joseph Eisenberg]

Well a parking garage may not really be "indoor", but it's certainly
"inside of a building" according to the database model, since the
garage will be mapped as a building=*

So what's important is how we may the lack of walls.

I agree with the earlier suggestion by Tobias to add wall=no for
clarity when using indoor=level, in this case.

Joseph

On 7/26/19, Martin Koppenhoefer  wrote:
> Am Fr., 26. Juli 2019 um 13:58 Uhr schrieb PanierAvide <
> panierav...@riseup.net>:
>
>> Thanks for this feedback. In these examples, I would say that there is
>> still a clear delimitation of what outside and what is inside, so can be
>> addressed with Simple 3D buildings modelling. My question is oriented in
>> a
>> particular case where you don't have a very precise delimitation of
>> inside/outside, like this parking lot :
>>
>> https://commons.wikimedia.org/wiki/File:Parking_Building_(41640900211).jpg
>>
>> As level 0 doesn't have wall, if you are near the building "limit" you
>> can
>> consider being outside, but at the center of this level you are clearly
>> inside (covered, maybe warmer). So how can we represent this lack of
>> walls,
>> but looking more like something inside ?
>>
>
>
> frankly I would not consider this parking on any level visible in the
> picture as "indoor". An indoor parking would be something like this:
> https://www.parkrideflyusa.com/facility-photos/33/indoor-parking.jpg
> Parking spaces are generally edge cases because of the ventilation
> requirements, but in the picture you showed there is hardly anything that
> can be considered "walls", I would call them "fences" or maybe "grates".
>
> Cheers,
> Martin
>

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

[Tagging] Feature man_made=offshore_platform?

[Joseph Eisenberg]

The feature man_made=offshore_platform was created as a wiki page and
then added to Map features, apparently without discussion, at some
point in the past.

It didn't have a very complete wiki page, but it looks like this is
mainly meant for offshore oil and gas drilling/production platforms -
I've just added a longer description.

It's only been used 400 times.

Should this tag be kept in Map features?

Pro: it seems like a fairly sensible tag, different than a man_made=pier

Con: Ideally it should have been proposed and discussed. The
definition is still weak, not used much, and perhaps
man_made=petroleum_well or =pumping_rig would be better in many cases?

Joseph

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

Re: [Tagging] man_made=snow_net vs man_made=snow_fence vs barrier=fence?

[Joseph Eisenberg]

Would you suggest removing both man_made=snow_net and
man_made=snow_fence from the curated list in Map Features?

Joseph

On Fri, Jul 26, 2019 at 9:39 PM Martin Koppenhoefer
 wrote:
>
> I agree that these are likely always barriers and would be more consistently 
> tagged under the "barrier" key. Also I concur these are types of fences. 
> While a specific tagging or subtagging seems desirable, I would not use the 
> established fence_type for it, as this describes structural and or material 
> properties, rather than the scope / purpose: 
> https://taginfo.openstreetmap.org/keys/fence_type#values
>
> maybe an additional qualifier like avalanche_protection=yes which could be 
> added to fences, walls, galleries etc.?
>
> 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] [Indoor] is indoor=level walled ?

[Martin Koppenhoefer]

Am Fr., 26. Juli 2019 um 13:58 Uhr schrieb PanierAvide <
panierav...@riseup.net>:

> Thanks for this feedback. In these examples, I would say that there is
> still a clear delimitation of what outside and what is inside, so can be
> addressed with Simple 3D buildings modelling. My question is oriented in a
> particular case where you don't have a very precise delimitation of
> inside/outside, like this parking lot :
>
> https://commons.wikimedia.org/wiki/File:Parking_Building_(41640900211).jpg
>
> As level 0 doesn't have wall, if you are near the building "limit" you can
> consider being outside, but at the center of this level you are clearly
> inside (covered, maybe warmer). So how can we represent this lack of walls,
> but looking more like something inside ?
>


frankly I would not consider this parking on any level visible in the
picture as "indoor". An indoor parking would be something like this:
https://www.parkrideflyusa.com/facility-photos/33/indoor-parking.jpg
Parking spaces are generally edge cases because of the ventilation
requirements, but in the picture you showed there is hardly anything that
can be considered "walls", I would call them "fences" or maybe "grates".

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

Re: [Tagging] man_made=snow_net vs man_made=snow_fence vs barrier=fence?

[Martin Koppenhoefer]

I agree that these are likely always barriers and would be more
consistently tagged under the "barrier" key. Also I concur these are types
of fences. While a specific tagging or subtagging seems desirable, I would
not use the established fence_type for it, as this describes structural and
or material properties, rather than the scope / purpose:
https://taginfo.openstreetmap.org/keys/fence_type#values

maybe an additional qualifier like avalanche_protection=yes which could be
added to fences, walls, galleries etc.?

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

[Tagging] man_made=snow_net vs man_made=snow_fence vs barrier=fence?

[Joseph Eisenberg]

Two tags were added to the Map Features page a while back, but don't
appear to have been discussed in a proposal.

man_made=snow_fence is used for fences that help prevent avalanches in
steep slopes with heavy snowfall. This tag has been used almost 3000
timeshttps://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsnow_fence

This seem enough usage to be in Map Features, though I'm not certain
that barrier=fence wouldn't be better. That tag, while less specific,
has been used millions of times and is widely supported. And isn't a
snow fence just a specialized type of fence?

An even rarer tag is man_made=snow_net - only use a little over 100
times. This is described as a snow fence made of cables - but isn't
this just a type of fence?
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dsnow_net

I plan to remove man_made=snow_net from map features. If a more
specific tag than barrier=fence is needed, then man_made=snow_fence is
sufficient; the material or manner of construction of the snow fence
could be tagged separately.

Should a note also be added to the wiki pages to suggest tagging
barrier=fence on the same way?

Joseph

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

Re: [Tagging] [Indoor] is indoor=level walled ?

[PanierAvide]

Thanks for this feedback. In these examples, I would say that there is 
still a clear delimitation of what outside and what is inside, so can be 
addressed with Simple 3D buildings modelling. My question is oriented in 
a particular case where you don't have a very precise delimitation of 
inside/outside, like this parking lot :


https://commons.wikimedia.org/wiki/File:Parking_Building_(41640900211).jpg

As level 0 doesn't have wall, if you are near the building "limit" you 
can consider being outside, but at the center of this level you are 
clearly inside (covered, maybe warmer). So how can we represent this 
lack of walls, but looking more like something inside ?


Best regards,

Adrien P.

Le 26/07/2019 à 13:39, Martin Koppenhoefer a écrit :
Am Fr., 26. Juli 2019 um 13:18 Uhr schrieb Martin Koppenhoefer 
mailto:dieterdre...@gmail.com>>:


no, I would put it like this: the ground floor is still part of
the building, but it is outside. Like a balcony for example. Would
you say a balcony is "inside"?



I guess this was too short, here's a more exhaustive take on the 
typical situations:


1. iconic building by le Corbu: 
https://upload.wikimedia.org/wikipedia/de/a/af/Villa_Savoye_2015.jpg 
This is a typical example for a raised modernist building.
the space where you can see chairs is IMHO clearly not "indoor", I 
would tend to accept it is part of the building (because it is 
"created"/delimited by the building and intended as usuable space), 
but you could also argue it is part of the garden, the architect even 
emphasizes this by using the same pavement as for the driveway (at 
least it looks like this on the picture).


These are typically cases where the building is raised above the 
ground in order to make use of a covered outdoor space, e.g. to use it 
as part of the garden, or to park a car, or as common space for the 
residents.



2. reconstruction of prehistoric raised buildings inside the Lake of 
Constance: 
https://upload.wikimedia.org/wikipedia/commons/2/2e/Pfahlbaumuseum_Unteruhldingen_Steinzeith%C3%A4user_Riedschachen_2010_04_10.jpg
I would tend to count the outdoor space below the "house" as not being 
part of the building (conceptually, the building is standing on legs, 
and while the legs are part of it, the area where they stand could be 
considered as not part of it). The area not being usable/accessible 
contributes to this judgement.
There are similar examples all over the world, e.g. here: 
http://bilder.net/bild-h%c3%bctte-urwald-orinoco-2335.jpg or here 
http://www.amliebstenreisen.at/bilder/2015/02/junglebay-2-660x330.jpg
These are generally cases where the building is raised above a 
"hostile" environment, e.g. to protect it from water, wild animals, 
enemies, or to create a level surface in an inclined surrounding. 
Typically the space below is not used in these cases. I would not 
consider the (unmodified / unaltered) ground below the building to be 
part of the building.



In all cases, I would not consider these indoor spaces, because they 
can not be heated or cooled, while you may be protected from the sun 
and precipitation you will still feel more outside than inside, typically.


I acknowledge there are many different situations and you will have to 
assess these individually, there will surely be a lot of edge cases. 
How you see them may also depend on the climate in the area in 
general, e.g. there are also lots of houses that are neither cooled 
nor heated, and some may have openings that cannot be closed rather 
than windows.


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] [Indoor] is indoor=level walled ?

[Martin Koppenhoefer]

Am Fr., 26. Juli 2019 um 13:18 Uhr schrieb Martin Koppenhoefer <
dieterdre...@gmail.com>:

> no, I would put it like this: the ground floor is still part of the
> building, but it is outside. Like a balcony for example. Would you say a
> balcony is "inside"?
>


I guess this was too short, here's a more exhaustive take on the typical
situations:

1. iconic building by le Corbu:
https://upload.wikimedia.org/wikipedia/de/a/af/Villa_Savoye_2015.jpg This
is a typical example for a raised modernist building.
the space where you can see chairs is IMHO clearly not "indoor", I would
tend to accept it is part of the building (because it is
"created"/delimited by the building and intended as usuable space), but you
could also argue it is part of the garden, the architect even emphasizes
this by using the same pavement as for the driveway (at least it looks like
this on the picture).

These are typically cases where the building is raised above the ground in
order to make use of a covered outdoor space, e.g. to use it as part of the
garden, or to park a car, or as common space for the residents.


2. reconstruction of prehistoric raised buildings inside the Lake of
Constance:
https://upload.wikimedia.org/wikipedia/commons/2/2e/Pfahlbaumuseum_Unteruhldingen_Steinzeith%C3%A4user_Riedschachen_2010_04_10.jpg
I would tend to count the outdoor space below the "house" as not being part
of the building (conceptually, the building is standing on legs, and while
the legs are part of it, the area where they stand could be considered as
not part of it). The area not being usable/accessible contributes to this
judgement.
There are similar examples all over the world, e.g. here:
http://bilder.net/bild-h%c3%bctte-urwald-orinoco-2335.jpg or here
http://www.amliebstenreisen.at/bilder/2015/02/junglebay-2-660x330.jpg
These are generally cases where the building is raised above a "hostile"
environment, e.g. to protect it from water, wild animals, enemies, or to
create a level surface in an inclined surrounding. Typically the space
below is not used in these cases. I would not consider the (unmodified /
unaltered) ground below the building to be part of the building.


In all cases, I would not consider these indoor spaces, because they can
not be heated or cooled, while you may be protected from the sun and
precipitation you will still feel more outside than inside, typically.

I acknowledge there are many different situations and you will have to
assess these individually, there will surely be a lot of edge cases. How
you see them may also depend on the climate in the area in general, e.g.
there are also lots of houses that are neither cooled nor heated, and some
may have openings that cannot be closed rather than windows.

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

Re: [Tagging] [Indoor] is indoor=level walled ?

[Martin Koppenhoefer]

Am Fr., 26. Juli 2019 um 13:13 Uhr schrieb PanierAvide <
panierav...@riseup.net>:

> Le 26/07/2019 à 13:02, Martin Koppenhoefer a écrit :
> > are they “indoor” if there is no wall? What makes them be inside rather
> than outside?
> >
> > Are covered open spaces inside or outside? I would tend to “outside”
> > as the climate will be similar to the climate around the structure,
> rather than comparable to the room climate of a completely enclosed space.
>
> They are still indoors (at least conceptually) because the building
> footprint is still there. Having ground floor unwalled doesn't mean that
> upper levels can't have wall.




sure, but if other levels have walls it doesn't make those levels without
walls "inside", does it?




> So, in that case, you suggest that
> building for example start at level 1 (with min_level=1) and everything
> on ground floor is outside ?



no, I would put it like this: the ground floor is still part of the
building, but it is outside. Like a balcony for example. Would you say a
balcony is "inside"?



> Then, how can I map for example a very
> small room on this area ? Still with indoor=room, even if technically
> not inside a building ?
>


is this a room with some kind of delimiting feature? I would not say it is
not part of the building, I would only say the space that is not enclosed
by walls (including windows, glass facades, etc.) is not "indoor".

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

Re: [Tagging] [Indoor] is indoor=level walled ?

[Warin]

On 26/07/19 21:02, Martin Koppenhoefer wrote:


sent from a phone


On 26. Jul 2019, at 12:14, Tobias Knerr  wrote:

Therefore, my suggestion would be to include a tag like wall=no on your
indoor=level polygon for these unwalled levels.


are they “indoor” if there is no wall? What makes them be inside rather than 
outside?

Are covered open spaces inside or outside? I would tend to “outside”
as the climate will be similar to the climate around the structure, rather than 
comparable to the room climate of a completely enclosed space.


I thinking of a building where the lower levels are used for parking vehicles 
while the upper levels have shops and/or residences. .
The parking levels usually have no walls to provide ventilation (and it is 
cheaper), they usually have a barrier to stop people and cars going over the 
edge but not a full heigh wall. So they are partially enclosed and partially 
open.

They provide economic shelter from the weather (rain/sun).

I would not describe them as being 'walled' nor 'outside'.


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

Re: [Tagging] [Indoor] is indoor=level walled ?

[PanierAvide]

Thanks for your two answers.

Le 26/07/2019 à 13:02, Martin Koppenhoefer a écrit :

are they “indoor” if there is no wall? What makes them be inside rather than 
outside?

Are covered open spaces inside or outside? I would tend to “outside”
as the climate will be similar to the climate around the structure, rather than 
comparable to the room climate of a completely enclosed space.


They are still indoors (at least conceptually) because the building 
footprint is still there. Having ground floor unwalled doesn't mean that 
upper levels can't have wall. So, in that case, you suggest that 
building for example start at level 1 (with min_level=1) and everything 
on ground floor is outside ? Then, how can I map for example a very 
small room on this area ? Still with indoor=room, even if technically 
not inside a building ?


I like the suggestion of Tobias to add wall=no on indoor=level, it seems 
to break less thing and make explicit the exception of one particular 
level being unwalled.


Best regards,

Adrien.


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

Re: [Tagging] [Indoor] is indoor=level walled ?

[Martin Koppenhoefer]

sent from a phone

> On 26. Jul 2019, at 12:14, Tobias Knerr  wrote:
> 
> Therefore, my suggestion would be to include a tag like wall=no on your
> indoor=level polygon for these unwalled levels.


are they “indoor” if there is no wall? What makes them be inside rather than 
outside?

Are covered open spaces inside or outside? I would tend to “outside”
as the climate will be similar to the climate around the structure, rather than 
comparable to the room climate of a completely enclosed space.

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

Re: [Tagging] Feature Proposal - RFC - health_amenity:type

[Martin Koppenhoefer]

Am Fr., 26. Juli 2019 um 12:26 Uhr schrieb Warin <61sundow...@gmail.com>:

> Sometimes the politicians promise it, tag that as
> proposed:healthcare:equipment=MRI, start_date 2132
>



just a note on this: the tag start_date refers to the described feature, if
this is a proposed feature, the start_date in my understanding would be the
date the proposal was first published, not when the feature will change to
an active feature.

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

Re: [Tagging] Feature Proposal - RFC - health_amenity:type

[Warin]

On 26/07/19 19:56, Martin Koppenhoefer wrote:
Am Fr., 26. Juli 2019 um 10:17 Uhr schrieb Simon Poole >:


PS: waiting for the first posts requiring that the absence of
equipment is taggable.




well spotted, there clearly is a gap, as we can tag the absence of 
professionals, e.g. capacity:doctors=0 (not in use, but would be a 
standard way) or staff_count:doctors=0 or doctors_num=0 (both keys 
have several hundred uses, and for doctors_num 0 and 00 are half of 
all used values, while for staff_count:doctors the values 0 and 0.0 
are even accounting for two thirds of all values (65%), so this 
actually IS of concern to mappers.




Usually with "health services" the problem is that their is an 
indication of something, where there is no usable presence.


Usually the equipment is either broken down or there is no trained 
operator .. so tag it disused:healthcare:equipment=MRI


Sometimes the politicians promise it, tag that as 
proposed:healthcare:equipment=MRI, start_date 2132


Similar tagging can be used for the hospitals themselves.


I know of one local hospital that I would refuse to go to, and the 
ambulances also try to go elsewhere for their patients safety!
Another more distant hospital where the registrar took a few hours on a 
plane flight to have his broken leg attended to at another hospital. Of 
course he did not tell the air crew, it was a normal commercial flight.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Indoor] is indoor=level walled ?

[Tobias Knerr]

On 23.07.19 13:42, PanierAvide wrote:
> So according to wiki, indoor=level doesn't involve having a implicit
> wall following the geometry. Is it something we agree on ?

indoor=level does not add an implicit wall.

However, building and building:part probably do have outer walls by
default, regardless of indoor=level or any other indoor mapping. There's
no solution for switching these walls off yet. We can't really assume
that the absence of an indoor=wall or indoor=room element means there's
no outer wall – fully indoor-mapped buildings are the exception, not the
rule.

Therefore, my suggestion would be to include a tag like wall=no on your
indoor=level polygon for these unwalled levels.

> According to wiki, indoor=wall can only be used on
> lines, so if I create a closed line, it should not render as an area
> (same behaviour as footways). Is it also something we agree on ?

Yes, a closed way with indoor=wall should be considered a line, not an area.

> Last question, if I want to create a wall as an area (imagine for
> example a wide pillar where no one can enter), should I just use
> indoor=wall + area=yes ?

Using area=yes makes sense here, yes.

Conceptually, I'm a bit uncomfortable with wall polygons because they
break the logic for doors and windows (which are nodes on the wall
ways). But for something completely solid like a pillar, this is
probably not going to cause problems.

Tobias

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

Re: [Tagging] Feature Proposal - RFC - health_amenity:type

[Martin Koppenhoefer]

Am Fr., 26. Juli 2019 um 10:17 Uhr schrieb Simon Poole :

> PS: waiting for the first posts requiring that the absence of equipment is
> taggable.
>



well spotted, there clearly is a gap, as we can tag the absence of
professionals, e.g. capacity:doctors=0 (not in use, but would be a standard
way) or staff_count:doctors=0 or doctors_num=0 (both keys have several
hundred uses, and for doctors_num 0 and 00 are half of all used values,
while for staff_count:doctors the values 0 and 0.0 are even accounting for
two thirds of all values (65%), so this actually IS of concern to mappers.

;-)

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

Re: [Tagging] Feature Proposal - RFC - health_amenity:type

[Simon Poole]

Am 26.07.2019 um 02:19 schrieb Joseph Eisenberg:
> There are still 2  problems with healthcare:equipment:
>
> 1) Healthcare:equipment is yet another new feature key for database
> users to support, if tagged on its own node at the location of the
> MRI. This requires Osm20gsql users like the main Openstreetmap-Carto
> style to reload the whole planet database before this key can be
> supported for rendering, routing or search applications. Using
> amenity=MRI or healthcare=MRI would be easier for current database
> users to support and it’s shorter for mappers to type.

That applies equally to health_amenity:type, in any case anybody wantig
nto support outlandish keys will be running with hstore enabled.


>
> 2) If you want to add this as a tag to an amenity=hospital, then you
> can’t add both an MRI and a CT scanner, for example, since a key can
> only have one value. 
>
Multi-value keys are in widespread use, and when they represent lists
totally unproblematic.

Simon

PS: waiting for the first posts requiring that the absence of equipment
is taggable.


> So in that case you still need MRI=yes as an addition key to tag on an
> existing facility. I suspect this tagging will be more common than
> mapping the MRI separately, and it certainly will be more common for
> ultrasounds, which are on wheels (casters) usually and can move around
> the hospital.
>
> Joseph
>
> On Fri, Jul 26, 2019 at 4:01 AM Mhairi O'Hara  > wrote:
>
> Hello everyone!
>
> I completely agree with Warin that the *health_amenity:type* tag
> is pretty confusing as to what its referring to. I was trying to
> stay in line with what was proposed previously, but in retrospect
> it would be better to move away from previous efforts and vote in
> a tag that is straight forward and easy to understand (says what
> it is).
>
> The main aim for the tag is to encapsulate that its related to
> health equipment, so how about *healthcare:equipment*?
>
> Kind regards,
>
> Mhairi
>
> On Sun, Jul 14, 2019 at 4:43 PM Warin <61sundow...@gmail.com
> > wrote:
>
> This is about the equipment available? 
>
> Using the principle of 'say what it is' ...
>
> medical_equipment=MRI ??? Assuming the tag is for equipment.
>
> Calling the key health_amenity:type "in use" is a stretch - 40
> uses .. and most of these are for first aid kits!
> The next most popular is "scales".
> Fist aid kits have the tag emergency=first_aid_kit ... which
> is more popular (170) despite it being a "draft".
>
> No, I don't think is is "in use" nor has it been used in a
> sensible way. Probably because "type" can mean anything.
>
> health_facility:type has the same problem, despite being more
> popular, uses are for
> dispensary
> office
> clinic
> hospital
> etc
>
>
> On 14/07/19 23:18, François Lacombe wrote:
>> Hi Mark,
>>
>> I agree with your choice to specifiy which service are
>> available in a given facility.
>> This doesn't require to add :type in the name of the key.
>> Such suffixe don't bring any information.
>> Your proposal would be way better if you use
>> health_amenit=MRI at least instead
>>
>> All the best
>>
>> François
>>
>> Le jeu. 11 juil. 2019 à 21:10, Mark Herringer
>> mailto:m...@healthsites.io>> a écrit :
>>
>> The intention of the tag is to specify physical equipment
>> (health_amenity:type=MRI) and should be used in
>> conjunction with amenity=clinic to show that the health
>> facility contains that specialised equipment. This will
>> enable mappers say that "this clinic contains an MRI"
>> ᐧ
>>
>> On Thu, 20 Jun 2019 at 08:15, Joseph Eisenberg
>> > > wrote:
>>
>> 4) health_amenity:type
>>
>> I think the key "healthcare" should be used instead
>> of the new key
>> health_amenity:type". If it's necessary to tag an MRI
>> facility
>> separately, then create a tag like "healthcare=mri".
>>
>>  However, it may be more useful to use a tag like
>> "mri=yes" on the
>> main amenity=hospital or the radiology department
>> within the medical
>> centre - this tag would let mappers say that "this
>> hospital contains
>> an MRI" without requiring mappers to precisely locate
>> the MRI
>> equipment within the building. This would also make
>> it easier for
>> database users: they can just check for
>> "amenity

Re: [Tagging] Feature Proposal - RFC - health_amenity:type

[Martin Koppenhoefer]

sent from a phone

> On 26. Jul 2019, at 02:19, Joseph Eisenberg  
> wrote:
> 
> 2) If you want to add this as a tag to an amenity=hospital, then you can’t 
> add both an MRI and a CT scanner, for example, since a key can only have one 
> value. 
> 
> So in that case you still need MRI=yes as an addition key to tag on an 
> existing facility.


you need this anyway if you want to be able to tag both and distinguish between 
them: the availability of these machines as a property of something else (e.g. 
a medical studio or hospital) and the machine as a stand-alone feature.

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