Re: [Tagging] Emergency shelters

[Blake Girardot]

On Fri, Sep 8, 2017 at 10:33 PM, Nick Hocking  wrote:
> Eric wrote
>
> "  This is an open database and we all "garden" the data to make sure that
> the
> information is correct."
>
> I think that information critical to safety needs a higher level of
> verification than just peer review.
> So the argument comes down to what is critical information.
>
> I normal times, road geometry on maps should not be critical to drivers
> because we expect them to use eyes/brain ahead of navigation prompts.(and
> yes I know this doesn't always happen)
>
> In times of emergency, certain information just must be correct and can not
> be allowed to be tampered with.
>

As someone who works in times of emergency, I can tell you OSM is the
goto dataset for many formal and informal response groups around the
world.

It is consistently a good dataset, sometimes where no other datasets
can be located and is used very often.

The quality is a known average good and the #opendata nature is always
a plus. The crowd based nature makes it one of the best databases of
local amenities, schools, medical in many parts of the world.

OSM is used at every level of the disaster management cycle from the
UN and EC/EU organs to local groups with a van load of food.

OSM data gets automatically pushed to #HDX the main UN OCHA data
distribution point, it is that important and in demand.

Everyone on this list is making that dataset as good as it is. thank you.

Respectfully,
blake











openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 

Blake Girardot
OSM Wiki - https://wiki.openstreetmap.org/wiki/User:Bgirardot
HOTOSM Member - https://hotosm.org/users/blake_girardot
skype: jblakegirardot
Live OSM Mapper-Support channel - https://hotosm-slack.herokuapp.com/

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

Re: [Tagging] Emergency shelters

[Nick Hocking]

Eric wrote

"  This is an open database and we all "garden" the data to make sure that
the
information is correct."

I think that information critical to safety needs a higher level of
verification than just peer review.
So the argument comes down to what is critical information.

I normal times, road geometry on maps should not be critical to drivers
because we expect them to use eyes/brain ahead of navigation prompts.(and
yes I know this doesn't always happen)

In times of emergency, certain information just must be correct and can not
be allowed to be tampered with.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Emergency shelters

[Martin Koppenhoefer]

sent from a phone

> On 9. Sep 2017, at 01:15, Greg Troxel  wrote:
> 
> I see 1 as squarely what "social_facility=shelter" should mean.
> 
> 2 I think "emergency=shelter" is good, and it's really not at all the
> same thing as social_facility=shelter.
> 
> 3 I would call emergency=weather_shelter or something.
> 
> 4 I would call emergency=fallout_shelter
> 
> But my big point is that 1/2 are not actually that related and should
> not be combined.


+1

cheers,
Martin 

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

Re: [Tagging] Emergency shelters

[Greg Troxel]

Eric Christensen  writes:

> On 09/07/2017 11:24 AM, Martin Koppenhoefer wrote:
>> do you recall why emergency:social_facility=shelter was chosen as a tag,
>> rather than a simple "emergency=shelter"? Because social_facility
>> shelter in osm is used with a different meaning, so it seems quite odd.
>
> I thought it was an odd choice, as well, but once I thought about it, it
> sort of made sense.
>
> The definition of a social_facility is "a feature that provides a social
> service."[0]  If you go further down, a social_facility=shelter is
> defined as "[a] facility that provides temporary sleeping facilities or
> refuge from exposure to the environment."  Isn't that what an emergency
> shelter is doing?

To respond to another point: the fact that authorities publish updated
lists of planned shelters from time to time is not that important.  Lots
of things change, and when they do, we update the map.  We don't put
expiration dates on roads because the government has not made a formal
commitment to maintain the road next year.  We just take them out when
they go away.


I see four different things:

  1) a "homeless shelter" that is generally open, for people that do not
  have a home, especially when it is cold.   An example:
 http://www.pinestreetinn.org/

  2) a place that authorities have a plan (or past practice) to use to let
  people sleep, when the people normally have a home but it's flooded or
  has no power and hence no heat and/or running water, etc.  These are
  typically schools or other public buildings and you absolutely cannot
  randomly show up during normal times and try to sleep there.
  Decisions to open and close are too fast for OSM editing and data
  fetch cycles.

  For these, notions of pet=yes can apply, because there's a plan a
  rules for what would happen.  It would be normal for such a shelter to
  be open for a single 48h period every 5 years, at least around me,
  more or less.

  3) a place where you can go if there is a tornado, that is generally
  accessible without a formal activation (probably; not really around me
  but others have talked about this)

  4) a "fallout shelter", which is sort of like 2 but for nuclear war,
  and maybe without the official opening part.

I see 1 as squarely what "social_facility=shelter" should mean.

2 I think "emergency=shelter" is good, and it's really not at all the
same thing as social_facility=shelter.

3 I would call emergency=weather_shelter or something.

4 I would call emergency=fallout_shelter

But my big point is that 1/2 are not actually that related and should
not be combined.


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

Re: [Tagging] Elevation in Feet as part of Peak Names

[Richard Welty]

On 9/8/17 9:34 AM, Richard Welty wrote:
> On 9/8/17 7:08 AM, ael wrote:
>> On Thu, Sep 07, 2017 at 03:31:37PM -0600, Mike Thompson wrote:
>>> User Raymo853 and I are having a friendly discussion on changeset
>>> 50470413[1]. He has been adding the elevation of mountain peaks (in feet)
>>> to the name tag. For example, he changed "Crown Point" to "Crown Point
>>> 11,463 ft."[2] While the wiki doesn't specifically address the issue of
>>> elevation as part of a peak name, it does say "Name is the name only"[3].
>>>
>>> Could we get feedback from the wider community on this?
>> +10 for elevation only in the ele tag.
>>
>> As surveying improves or plate tectonics changes, it would be ridiculous
>> to change the name rather than just the elevation.
> adding the elevation to the name tag makes life far more difficult for data
> consumers. don't do it.
to amplify my point, there is a universe of extant and potential data
consumers;
some consumers are humans looking at the map on the website, but other
consumers
are generating GPS maps or other automated things with software. adding
elevation
to the name is a symptom of tagging for the website.
we need to watch continuously for folks who are tagging in this manner, and
get across to them why it shouldn't be done this way.

richard
-- 

rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


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

Re: [Tagging] Elevation in Feet as part of Peak Names

[Kevin Kenny]

On Fri, Sep 8, 2017 at 4:54 AM, Colin Smale  wrote:
> Does anyone have any idea whether the elevations, be they in feet or metres,
> are all respecting the wiki definition of being the height above MSL
> according to EGM96 (not sure what that would mean in landlocked areas) and
> NOT WGS84 or (strictly speaking) relative to local MSL?
>
> The wiki page for ele[1] says this:
>
> Elevation (height above sea level) of a point in metres. This is mainly
> intended for mountain peaks but could also be used for elevation of airport
> runways and many other objects. For OpenStreetMap, this value should be in
> meters above above mean sea level as defined by the EGM96 geoid model. This
> elevation is usually very close to national "above sea level" systems with
> differences < 1m. This is not the height above the WGS84 ellipsoid (see
> Geoid) which is shown as raw elevation by some satellite navigation devices
> and which can differ from geoid elevation by up to 100m.
>
> If we can't even rely on the reference point for these elevations,
> discussions about feet vs. metres (assuming the unit is indicated properly)
> are close to "bikeshedding".

Note that in that definition it refers to the WGS84 ellipsoid, not the
WGS84 geoid. If WGS84 is implemented correctly, the ellipsoid is used
for horizontal control only and the geoid is used for vertical
control. Many widely available libraries, such as
https://geographiclib.sourceforge.io/, give reference implementations.
I would presume that modern GPS equipment - not bare receivers, but
the firmware and software surrounding them - gets it right. I
certainly haven't noticed, when using my smartphone, the 30 m
elevation difference that I'd see if it were relative to the reference
ellipsoid.

When I have tagged elevations, it's generally of places I've been.
Because I'm in North America, I've generally committed the small sin
of using NAVD88 or possibly a published elevation relative to NGVD29.
I tend to go with USGS surveyed elevations where they exist and my
altimeter doesn't show an egregious error - I presume that the
trigonometric elevations are more accurate than an altimeter. I don't
bother with orthometric reduction because in my area, the three
reference surfaces (NGVD29, NAVD88,  EGM96) concur to better than my
altimeter's resolution, to say nothing of its repeatability.
NAVD88-NGVD29 around here is typically less than a metre. I reset my
altimeter at either a benchmark or a tabulated spot elevation several
times a day if I'm doing elevations, particularly if the weather is
varying. Even my smartphone has a barometer, but ordinarily I carry a
separate altimeter.

Not perfect, but to do better in the field I'd need better instruments
than I carry, or even own. I don't do that sort of work unless you pay
me to do it, and if you offer to pay me, I'll happily give you the
business card of a licensed surveyor.

I tag measurements in SI units because that's the only thing that I
know all the tools can handle.

(Memo to self - still need to repair those misplaced Catskill peaks.
Too much to do, too little time...)

I think the only takeaway from all this is "don't use the reference
ellipsoid for vertical control." But my understanding is  that most of
us will get it right without realizing it, because our software does
it for us. Even more important is "don't use a GPS-only reference for
elevation unless you understand dilution of position." GPS-derived
elevations are pretty wonky. (But see above: even my smartphone has a
barometer.)

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

Re: [Tagging] Elevation in Feet as part of Peak Names

[John F. Eldredge]

Also, I doubt anyone in ordinary life refers to a mountain as "Mount 
So-and-So 2000 meters", rather than simply "Mount So-and-So".



On September 8, 2017 8:36:52 AM Richard Welty  wrote:


On 9/8/17 7:08 AM, ael wrote:

On Thu, Sep 07, 2017 at 03:31:37PM -0600, Mike Thompson wrote:

User Raymo853 and I are having a friendly discussion on changeset
50470413[1]. He has been adding the elevation of mountain peaks (in feet)
to the name tag. For example, he changed "Crown Point" to "Crown Point
11,463 ft."[2] While the wiki doesn't specifically address the issue of
elevation as part of a peak name, it does say "Name is the name only"[3].

Could we get feedback from the wider community on this?

+10 for elevation only in the ele tag.

As surveying improves or plate tectonics changes, it would be ridiculous
to change the name rather than just the elevation.

adding the elevation to the name tag makes life far more difficult for data
consumers. don't do it.

richard

--
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


___
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] Elevation in Feet as part of Peak Names

[Richard Welty]

On 9/8/17 7:08 AM, ael wrote:
> On Thu, Sep 07, 2017 at 03:31:37PM -0600, Mike Thompson wrote:
>> User Raymo853 and I are having a friendly discussion on changeset
>> 50470413[1]. He has been adding the elevation of mountain peaks (in feet)
>> to the name tag. For example, he changed "Crown Point" to "Crown Point
>> 11,463 ft."[2] While the wiki doesn't specifically address the issue of
>> elevation as part of a peak name, it does say "Name is the name only"[3].
>>
>> Could we get feedback from the wider community on this?
> +10 for elevation only in the ele tag.
>
> As surveying improves or plate tectonics changes, it would be ridiculous
> to change the name rather than just the elevation.
adding the elevation to the name tag makes life far more difficult for data
consumers. don't do it.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


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

Re: [Tagging] Feature Proposal - RFC - Evacuation Route

[Eric Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/07/2017 10:53 PM, Nick Hocking wrote:
> Will this proposal contain alternate evacuation routes, and an
> indication by whom and when they would be activated?

If the state/local authorities have designated a route as an evacuation
route then I don't see why the route wouldn't be put into OSM.

Generally speaking, an evacuation route isn't the *only* way out of a
location but, rather, is the recommended way out that avoids hazards
(flooding, etc) and is usually a large thoroughfare, so it's not
imperative that there be a "when" assigned to a route.

With respect to Google, I think they are using their traffic load
monitoring to try to divert traffic from one route to the other to help
balance the load.  This is one feature I wish our tools (maps.me,
OSMAND, etc) had.

- --Eric
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEERiNfHJ4f0jHRHow5g9FPLsqcWWwFAlmykmsACgkQg9FPLsqc
WWzrEAf/cXcGC3ti0VA9dg8oOHPEqtlysFoEzRi8YSjuyMsK5OJDo/ynZ+fIyvTj
Ewqs5vbpxR2woqAHf5RXXQwPU7wL5sgIkRpDKvcr88xAk8q48XE1cmlqi9zi/rBg
1SOn7BATM32+QdysYm59U5G23n+StgTthYJYH0b6A6QWf7DjlhIur2ImVoWdhXU5
5HHA7vZMHUinFpGpuTUFj5FJbyx+q4M9omuhM/nbebUZBnmJJh3oYPUrdFR03xIa
e9v59zv4bmVVJ2mwlL1XyrwbzNqC6/0YkiJh+ImREcYzc1L4OrDGap8Ppw0ym443
QtZCgv8SIu4ZIe064XxgF3j3xNH7+Q==
=wxiZ
-END PGP SIGNATURE-

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

Re: [Tagging] Feature Proposal - RFC - Evacuation Route

[Eric Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/08/2017 05:05 AM, Lukas Sommer wrote:
> As key:evacuation_route is currently almost exclusively used on
> relations anyway, it might make more sense to deprecate this tag and
> instead define a new value for route=* on type=route relations (and
> than add all the refinements that you propose)…

Dang, yes.  Sorry, what you just said reminded me of what I had thought
many months ago.  With a route you can make them directional which is
important.  I'll make those changes today.

- --Eric
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEERiNfHJ4f0jHRHow5g9FPLsqcWWwFAlmyi+kACgkQg9FPLsqc
WWzaywf/bdJUSXbLeBuU44N+HcRquhQj/LxV9Vg5ISUh4YzULOCvhL7w1Toq8ESo
Gw6Y+pqrsFkyor5td2vjHokwDm9raV3ozMo3KG8DQGgk0DBuHhwFP5NUmlen394t
VQl7t+ICIxkjH0H3fh+rN1YNrddwC5c8vmTiwiLSgcEHy0+hzhX42prRSY/kK6yW
SPvTrTDis2rBAi2E1Xm20CWE86GkQbJL8t72h83yUmGNko4z4crC4oP1A04gHNi7
2/mXd0Jr6HmJF7x1McCEuV57NAvDQbyPTCL8ATqS0HzVZFujyx4+qfCImmAXJqFj
fLnFMpJ9m4tEKmFE9mo0hF/xoA7iYg==
=D5si
-END PGP SIGNATURE-

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

Re: [Tagging] Emergency shelters

[Eric Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/07/2017 11:24 AM, Martin Koppenhoefer wrote:
> do you recall why emergency:social_facility=shelter was chosen as a tag,
> rather than a simple "emergency=shelter"? Because social_facility
> shelter in osm is used with a different meaning, so it seems quite odd.

I thought it was an odd choice, as well, but once I thought about it, it
sort of made sense.

The definition of a social_facility is "a feature that provides a social
service."[0]  If you go further down, a social_facility=shelter is
defined as "[a] facility that provides temporary sleeping facilities or
refuge from exposure to the environment."  Isn't that what an emergency
shelter is doing?

- --Eric

[0] https://wiki.openstreetmap.org/wiki/Key:social_facility
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEERiNfHJ4f0jHRHow5g9FPLsqcWWwFAlmyijQACgkQg9FPLsqc
WWzEFAf9HwFyDb1DSjG8H5scptcqJbdImqJRep/nq5mNefLK1qNDSQlzfz4SWnP8
Ph5Khh4DB9jogriPFDy+KvUI/owdQk10o5TFGZn1bIMuMREjQ11pytqc1jIFFIUJ
9NvSKQICxYzTF2jnFYxaiS4DbBNrjXf2NoC65pEAGasvO8TqquRVwHx28Q+cXd9r
hxb7OXlAC+1BtBps/3eU7XDRtTXiEaAckfL7k/WBLAEzfB6yAid4d/5GJaV8WHuJ
yzw1a6FRsums1TNcgxl4BDk4J9b8REeY+Vy3d8umXYTImhmGYiR6VdNeMcEe8YUe
NvswvATd92WyervXq/yRwmBwEjo38w==
=SAEj
-END PGP SIGNATURE-

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

Re: [Tagging] Emergency shelters

[Eric Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/07/2017 11:12 PM, Nick Hocking wrote:
> Eric wrote   "Why would you delete data that is still valid and
> useful?"
> 
> 
> My concern is that if these are permanent features, then people
> will say "ooh - they'll be the same as last time" and of course
> they probably won't be the same as last time and we may route
> people to a wrong place, with possible tragic results.

I would say that shelters probably would be the same as last year.
It's very difficult to find structures that meet the criteria for
being shelters in the first place so thinking that you're going to
play a shell game with them really isn't going to happen.  The
shelters that I used to deal with are still shelters today some
fifteen years later and they were shelters for at least a decade when
I came into the job.

> I agree that this information should be left in place, but marked
> , unusable, until specifically activated by authorities, which I
> agree should be well ahead of time, so long as people know that
> they will not be usable until a state of emergency is declared.

I believe that's a given being that it's an emergency shelter.  That
said, I think we can use the 'note' key to make some sort of
declaration to that extent as I suspect there are some public tornado
shelters in the Midwest (US) that are available 24/7 whereas out here
on the east coast many hurricane shelters are stood up on an as-needed
basis.

> I also think that this information should NOT be edited, in any way
> by anyone other than the authorities. This brings back the old
> arguments about read only data in OSM.

One could make the same argument about roads or any other data.  This
is an open database and we all "garden" the data to make sure that the
information is correct.  Google has a closed database and it's a pain
for an "authoritative source" to get their one-off information into
it.  To go down the route of creating authoritative sources would
require way too much work to establish relationships with a lot of
agencies that likely do not wish to participate in the first place.
Further, we'd have to establish a trust relationship with them to be
able to authenticate them as the authenticated source.  Who is to say
that they would even maintain the data?  To me, the crowd is a much
better source and so far we've been doing pretty well.

- --Eric
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEERiNfHJ4f0jHRHow5g9FPLsqcWWwFAlmyiKwACgkQg9FPLsqc
WWzFrAf/WO1itSXeACgYb/0V9yQ99FSTS9CCPO8juxScNNCKkDnYuSmZFKMG1WIV
tsIf9Ap6vHX9yrpeOwbPsc16+DyhLkDwylQQKtuQH2zsEC42E1PwVtcNTO65GU8k
XwpDXcDNeX8m2hzDghjmENd/c2G4fCfSdlZhtA0cfEIDdbjYUF1OwdChGvaBiS2T
64TmUOy4O8snRQMkt+9ZYIrOMoL83UXapHMknLRezRADitbjs0LOJiAbgw7lN6ya
nfrxmkp8u7m2Z9RwL1enfAIxj02Ys6i162qMNitrdPjqgjQK9N9MIuCwUvE8eVtQ
xukBHCmgS5lcEh1rWx0tYdRU5L7lRA==
=3qCe
-END PGP SIGNATURE-

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

Re: [Tagging] Emergency shelters

[Martin Koppenhoefer]

2017-09-08 0:26 GMT+02:00 tomoya muramoto :

>
>>
>> (1) "emergency=shelter" is not defined in wiki
>
> (2) wiki says social_facility=shelter can be applied to "Emergency Shelter"
> https://wiki.openstreetmap.org/wiki/Tag:social_facility%3Dshelter
> We wanted to show the shelter is only available when disaster happened, so
> we added "emergency:" prefix.
>
>

You are right. Thank you for the link, social_facility=shelter is indeed
defined for emergency shelters, excuse me for recalling this wrong. Still
it could be interesting to differentiate these from other kind of social
facility shelters with a subtag.

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

Re: [Tagging] Emergency shelters

[Andrew Hain]

Is there a case for a general mapping scheme for information that ceases to be 
valid on a date and could be automatically removed afterwards?

--
Andrew

From: Nick Hocking 
Sent: 08 September 2017 04:12:35
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Emergency shelters

Eric wrote   "Why would you delete data that is still valid and useful?"


My concern is that if these are permanent features, then people will say "ooh - 
they'll be the same as last time" and of course they probably won't be the same 
as last time and we may route people to a wrong place, with possible tragic 
results.

I agree that this information should be left in place, but marked , unusable, 
until specifically activated by authorities, which I agree should be well ahead 
of time, so long as people know that they will not be usable until a state of 
emergency is declared.

Activation should be on a center by centre basis so that authorities will be 
more likely to ensure the list of centers is accurate and up-to-date.

I also think that this information should NOT be edited, in any way by anyone 
other than the authorities. This brings back the old arguments about read only 
data in OSM.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Elevation in Feet as part of Peak Names

[ael]

On Thu, Sep 07, 2017 at 03:31:37PM -0600, Mike Thompson wrote:
> User Raymo853 and I are having a friendly discussion on changeset
> 50470413[1]. He has been adding the elevation of mountain peaks (in feet)
> to the name tag. For example, he changed "Crown Point" to "Crown Point
> 11,463 ft."[2] While the wiki doesn't specifically address the issue of
> elevation as part of a peak name, it does say "Name is the name only"[3].
> 
> Could we get feedback from the wider community on this?

+10 for elevation only in the ele tag.

As surveying improves or plate tectonics changes, it would be ridiculous
to change the name rather than just the elevation.

ael


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

Re: [Tagging] Elevation in Feet as part of Peak Names

[marc marc]

Le 08. 09. 17 à 11:14, Janko Mihelić a écrit :
> 20155.9894568543 ft

your unreasonable example has nothing to do with elevation.
in any tag, nothing prevents a tool from being rational
in the values it saves or displays. I do not know what is
the best possible accuracy but an altitude measurement
rounded to 0.1 meter or 0.5 feet seems IMHO reasonable.
I have never seen a sign with more precise information.

you can even put a measure 10 times more accurate,
this will remain very far from your example but still
allowing to find a round number after conversion.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Elevation in Feet as part of Peak Names

[Janko Mihelić]

Elevation doesn't go in "name" tag, that's quite obvious. But I think
elevations in feet shouldn't be discouraged. Maybe sometimes you have
iconic elevations of mountains in feet everybody knows and learns in
school, and they want to see that number exactly on a map, and not some
fraction after converting from meters, like, Denali is 20155.9894568543 ft
high.

Janko

pet, 8. ruj 2017. u 10:57 Lukas Sommer  napisao je:

> The wiki page for https://wiki.openstreetmap.org/wiki/Key:ele says it
> has to be in meters, not in feets.
>
> --
> Lukas Sommer
>
> ___
> 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] Elevation in Feet as part of Peak Names

[Andy Townsend]

On 08/09/2017 09:54, Colin Smale wrote:


Does anyone have any idea whether the elevations, be they in feet or 
metres, are all respecting the wiki definition of being the height 
above MSL according to EGM96 (not sure what that would mean in 
landlocked areas) and NOT WGS84 or (strictly speaking) relative to 
local MSL?


Not without checking the provenance of the data in OSM, no.  At least in 
the UK, peak ele values will have come from a variety of sources:


o "Well known values" that "the height of mountain X is Y"

o Some value copied from some other (hopefully out of copyright) map

o A value read from a GPS or phone.  With a bit of luck that person 
might have calibrated the barometer in that device recently, but there's 
no guarantee.  A non-barometric GPS-only derived elevation is likely to 
be even worse.


In the UK where I am, there are a significant number of peaks added by 
one mapper based on spot heights from old OS maps - many of these are 
not actually peaks at all, and many aren't in the correct place.


Best Regards,
Andy


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

Re: [Tagging] Feature Proposal - RFC - Evacuation Route

[Lukas Sommer]

As key:evacuation_route is currently almost exclusively used on
relations anyway, it might make more sense to deprecate this tag and
instead define a new value for route=* on type=route relations (and
than add all the refinements that you propose)…

-- 
Lukas Sommer

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

Re: [Tagging] Elevation in Feet as part of Peak Names

[Lukas Sommer]

The wiki page for https://wiki.openstreetmap.org/wiki/Key:ele says it
has to be in meters, not in feets.

-- 
Lukas Sommer

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

Re: [Tagging] Elevation in Feet as part of Peak Names

[Colin Smale]

Does anyone have any idea whether the elevations, be they in feet or
metres, are all respecting the wiki definition of being the height above
MSL according to EGM96 (not sure what that would mean in landlocked
areas) and NOT WGS84 or (strictly speaking) relative to local MSL? 

The wiki page for ele[1] says this: 

ELEVATION (HEIGHT ABOVE SEA LEVEL) OF A POINT IN METRES. This is mainly
intended for mountain peaks [2] but could also be used for elevation of
airport runways and many other objects. For OpenStreetMap, this value
should be in meters above above mean sea level as defined by the EGM96
[3] geoid model. This elevation is usually very close to national "above
sea level" systems with differences < 1m. This is not the height above
the WGS84 ellipsoid (see Geoid [4]) which is shown as raw elevation by
some satellite navigation devices and which can differ from geoid
elevation by up to 100m. 

If we can't even rely on the reference point for these elevations,
discussions about feet vs. metres (assuming the unit is indicated
properly) are close to "bikeshedding". 

//colin 

[1] http://wiki.openstreetmap.org/wiki/Key:ele

On 2017-09-08 10:39, Andrew Hain wrote:

> Or, indeed, you could put a conversion in the editor between the mapper 
> typing a figure in and the elevation being saved to the database.
> 
> --
> Andrew
> -
> 
> FROM: Warin <61sundow...@gmail.com>
> SENT: 08 September 2017 02:59:39
> TO: tagging@openstreetmap.org
> SUBJECT: Re: [Tagging] Elevation in Feet as part of Peak Names 
> 
> On 08-Sep-17 09:10 AM, Dave Swarthout wrote: 
> 
>> Adding numeric values to the name of a peak is not okay. As for using feet 
>> in the "ele" tag instead of meters, JOSM discourages this practice and I 
>> think we should too. It's long past the time when Americans and other 
>> countries still using archaic and cumbersome measurement systems based on 
>> the length of the king's foot or thumb should embrace the metric system. The 
>> down side is that very peak I add involves an extra step.
> 
> Aviation still uses feet? 
> Asking a mapper who may not be familiar with conversion into meters leads to 
> errors. I'd rather have the render do the conversion as is done for other 
> dimensions. 
> 
> Cheers, 
> 
> Dave 
> 
> On Fri, Sep 8, 2017 at 5:57 AM, Jo  wrote:
> 
> ele can of course be in feett or lightyears for that matter, but it's a lot 
> easier to work with if they are all in the same unit. 
> 
> 2017-09-08 0:22 GMT+02:00 Warin <61sundow...@gmail.com>:
> On 08-Sep-17 07:39 AM, Shawn K. Quinn wrote:
> On 09/07/2017 04:31 PM, Mike Thompson wrote:
> User Raymo853 and I are having a friendly discussion on changeset
> 50470413[1]. He has been adding the elevation of mountain peaks (in
> feet) to the name tag. For example, he changed "Crown Point" to "Crown
> Point 11,463 ft."[2] While the wiki doesn't specifically address the
> issue of elevation as part of a peak name, it does say "Name is the name
> only"[3].
> 
> Could we get feedback from the wider community on this? That's what this is 
> for: https://wiki.openstreetmap.org/wiki/Key:ele [1]
> 
> The only catch is that it has to be in meters, so you would tag
> ele=3493.9 in your example.

+1 to name tag is name only.

--

ele tag should be used for this information.

And I would think that the ele value can be in feet just like other
dimensional units of width, height etc.

Should this be put as a new proposal? 

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

  -- 

Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com [6] 

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

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

Links:
--
[1] https://wiki.openstreetmap.org/wiki/Key:ele
[2] http://wiki.openstreetmap.org/wiki/Tag:natural%3Dpeak
[3] http://en.wikipedia.org/wiki/EGM96
[4] http://en.wikipedia.org/wiki/Geoid
[5] https://lists.openstreetmap.org/listinfo/tagging
[6] http://dswarthout.blogspot.com___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Elevation in Feet as part of Peak Names

[Andrew Hain]

Or, indeed, you could put a conversion in the editor between the mapper typing 
a figure in and the elevation being saved to the database.

--
Andrew

From: Warin <61sundow...@gmail.com>
Sent: 08 September 2017 02:59:39
To: tagging@openstreetmap.org
Subject: Re: [Tagging] Elevation in Feet as part of Peak Names

On 08-Sep-17 09:10 AM, Dave Swarthout wrote:
Adding numeric values to the name of a peak is not okay. As for using feet in 
the "ele" tag instead of meters, JOSM discourages this practice and I think we 
should too. It's long past the time when Americans and other countries still 
using archaic and cumbersome measurement systems based on the length of the 
king's foot or thumb should embrace the metric system. The down side is that 
very peak I add involves an extra step.

Aviation still uses feet?
Asking a mapper who may not be familiar with conversion into meters leads to 
errors. I'd rather have the render do the conversion as is done for other 
dimensions.

Cheers,

Dave

On Fri, Sep 8, 2017 at 5:57 AM, Jo 
> wrote:
ele can of course be in feett or lightyears for that matter, but it's a lot 
easier to work with if they are all in the same unit.

2017-09-08 0:22 GMT+02:00 Warin 
<61sundow...@gmail.com>:
On 08-Sep-17 07:39 AM, Shawn K. Quinn wrote:
On 09/07/2017 04:31 PM, Mike Thompson wrote:
User Raymo853 and I are having a friendly discussion on changeset
50470413[1]. He has been adding the elevation of mountain peaks (in
feet) to the name tag. For example, he changed "Crown Point" to "Crown
Point 11,463 ft."[2] While the wiki doesn't specifically address the
issue of elevation as part of a peak name, it does say "Name is the name
only"[3].

Could we get feedback from the wider community on this?
That's what this is for: https://wiki.openstreetmap.org/wiki/Key:ele

The only catch is that it has to be in meters, so you would tag
ele=3493.9 in your example.


+1 to name tag is name only.


--

ele tag should be used for this information.

And I would think that the ele value can be in feet just like other dimensional 
units of width, height etc.

Should this be put as a new proposal?



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


___
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


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

Re: [Tagging] Any tag for tiny, pittoresque, tool store houses?

[marc marc]

Le 08. 09. 17 à 08:30, José G Moya Y. a écrit :
> In some parts of Spain, there are tiny igloo-like houses, smaller 
> than a person, traditionally used to store tools near the fields.

building=shed
building:architecture=whatyouthink :)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Elevation in Feet as part of Peak Names

[marc marc]

Le 07. 09. 17 à 23:31, Mike Thompson a écrit :
> he changed "Crown Point" to "Crown Point 11,463 ft.
> it does say "Name is the name only"[3].

as the wiki says: the name is only the name.
"Crown Point 11,463 ft" is not a name.
Elevation goes in the "ele" tag.
in meters if it's only a number.
add ft if you want in feet
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Any tag for tiny, pittoresque, tool store houses?

[José G Moya Y .]

Hi!
In some parts of Spain, there are tiny igloo-like houses, smaller than a
person, traditionally used to store tools near the fields. They are called
"guardaviñas" ("vineyard guards") and resemble, by shape and purpose, the
italian "trulli" of Puglia, but they are smaller.
I was wondering if there is a tag for these pittoresque buildings.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging