[Tagging] Changing amenity=bear_box to amenity=bear_cache

2023-06-19 Thread Eric H. Christensen via Tagging
Based on a discussion that was had on the discussion page[0] of 
tag:amenity=bear_box, I am proposing a change of this tag from amenity=bear_box 
to amenity=bear_cache with an additional tag of bear_cache:type=* to better 
clarify what type of bear cache is here.  The term "bear cache" seems to be a 
better definition of "bear box" and is defined in Wikipedia[1] to include both 
boxes, poles, and other structures that are designed to keep animals, 
specifically bears, out of your food while camping.

There are only sixty-seven (67) instances of tag:amenity=bear_box in the 
database as of 2023-06-19 so changing to the new tag won't be a huge lift.

Thoughts?

R,
Eric "Sparks"

[0] https://wiki.openstreetmap.org/wiki/Talk:Tag:amenity%3Dbear_box
[1] https://en.wikipedia.org/wiki/Bear_cache

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


Re: [Tagging] coastline v. water

2020-11-21 Thread Eric H. Christensen via Tagging
You cannot point to other area that may, in fact, be improperly mapped as an 
example when they are like that because locals have been shouted down for doing 
it correctly. The fact that this keeps coming back up literally means that 
there is not universal agreement that "marginal seas", whatever that means, are 
to be mapped with natural=coastline.

The Chesapeake Bay is an estuary that, by definition, opens to the sea. It 
can't be a sea and open to a sea at the same time. In this environment, it is 
different from the ocean in which it opens into and is also different from the 
tributaries that feed it. These are protected waters for ships. You won't find 
any high seas forecasts for the Bay unlike the ocean. The Bay is also brackish 
and not defined as salt water, unlike the ocean.

If the rendering engine isn't showing it correctly, fix that; *that's* what's 
broken.

Eric

‐‐‐ Original Message ‐‐‐
On Saturday, November 21, 2020 1:14 PM, Joseph Eisenberg 
 wrote:

> Eric,
> I don't think the previous discussion is quite as inconclusive as your 
> evaluation.
>
> While it is true that there is not widespread agreement on where the 
> natural=coatline ways should transect a river mouth or river estuary, there 
> is nearly universal agreement that marginal seas, including bays, are mapped 
> with the natural=coastline.
>
> Using the rendering at https://www.openstreetmap.de/karte.html - which 
> differentiates the marine water polygons outside of the coastline from lakes 
> and rivers, by using slightly different colors, we can see how bays are 
> mapped in other parts of North America and the world.
>
> For example, check out Delaware Bay, just up the coast from your area: 
> https://www.openstreetmap.de/karte.html?zoom=10=39.14649=-75.07302=B000
>  - it is mapped as a natural=bay with natural=coastline around it, not 
> natural=water
>
> Upper and Lower New York Bay are mapped as bays outside of the 
> natural=coastline - you can see the line where the waterway=riverbank area 
> starts just at the north end of Manhattan island (though this placement is 
> somewhat controversial) - 
> https://www.openstreetmap.de/karte.html?zoom=10=40.63628=-73.93525=B000
>
> Tampa Bay: 
> https://www.openstreetmap.de/karte.html?zoom=10=27.80801=-82.63368=B000
>  - outside of the natural=coastline
>
> Galveston Bay: 
> https://www.openstreetmap.de/karte.html?zoom=10=29.49869=-94.94249=B000TT
>  - outside of the natural=coastline
>
> San Francisco Bay and connected bays: 
> https://www.openstreetmap.de/karte.html?zoom=10=37.79939=-122.06911=B000TT
>  - outside of the coastline
>
> Puget Sound - while Lake Washington on the east side of Seattle is 
> natural=water, also most of the ship canal connecting them: 
> https://www.openstreetmap.de/karte.html?zoom=11=47.59544=-122.39252=B000
>
> I would like to request that the tidal channels and estuaries around 
> Chesapeake Bay be re-mapped with natural=coastline. If you wish to keep the 
> natural-water polygons for the estuaries that is not a problem.
>
> But it would be contrary to normal practice to map the main body of 
> Chesapeake Bay as natural=water because it is clearly part of the sea - there 
> is no barrier between it and the open ocean, since there is an open channel 
> through US 13 where the tunnel is. While it is an estuary by hydrological 
> definitions, so are the Baltic Sea and all fjords and Puget Sound and San 
> Francisco Bay - all of which are mapped as outside of the natural=coastline.
>
> Also please consider that the community here approved the proposal for 
> waterway=tidal_channel which said that the area of tidal channels (aka tidal 
> creeks) should be mapped with natural=coastline at their edges - see 
> https://wiki.openstreetmap.org/wiki/Tag:waterway%3Dtidal_channel#How_to_Map 
> and 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:waterway%3Dtidal_channel
>  - most of the "creek" features along the Bay are tidal channels.
>
> -- Joseph Eisenberg
>
> On Thu, Nov 19, 2020 at 6:46 AM Eric H. Christensen via Tagging 
>  wrote:
>
>> ‐‐‐ Original Message ‐‐‐
>>
>> On Wednesday, November 18th, 2020 at 11:34 PM, Brian M. Sperlongano 
>>  wrote:
>>
>>> This was fascinating reading. I do agree that we ought to have a definition 
>>> for what gets tagged natural=coastline, and I think it's fine if that 
>>> definition has some subjectivity.
>>>
>>> I would offer something as simple as:
>>>
>>> "The coastline should follow the mean high tide line. In some cases this 
>>> rule would result in the coastline extending an unreasonable distance along 
>>> the banks of tidal rivers. In those cases, mapper

Re: [Tagging] coastline v. water

2020-11-19 Thread Eric H. Christensen via Tagging
‐‐‐ Original Message ‐‐‐

On Wednesday, November 18th, 2020 at 11:34 PM, Brian M. Sperlongano 
 wrote:

> This was fascinating reading.  I do agree that we ought to have a definition 
> for what gets tagged natural=coastline, and I think it's fine if that 
> definition has some subjectivity.
>
> I would offer something as simple as:
>
> "The coastline should follow the mean high tide line.  In some cases this 
> rule would result in the coastline extending an unreasonable distance along 
> the banks of tidal rivers.  In those cases, mappers should identify a 
> reasonable choke point at which to terminate the inland extent of coastline 
> tagging."

I would just classify it as "where the ocean meets the land".  Any other water 
that isn't ocean should be mapped as water and tagged appropriately.  That 
makes the map more accurate and detailed.

R,
Eric

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


Re: [Tagging] coastline v. water

2020-11-19 Thread Eric H. Christensen via Tagging
‐‐‐ Original Message ‐‐‐

On Wednesday, November 18th, 2020 at 5:04 PM, Christoph Hormann 
 wrote:

> > Eric H. Christensen via Tagging tagging@openstreetmap.org hat am 18.11.2020 
> > 21:19 geschrieben:
>
> > [...]
>
> First: the matter has been discussed at length previously so i would advise 
> anyone who wants to form an opinion on the matter to read up on past 
> discussion where essentially everything relevant has been said already. Most 
> relevant links:
>
> https://lists.openstreetmap.org/pipermail/tagging/2020-July/054405.html
>
> and resulting discussion:
>
> https://lists.openstreetmap.org/pipermail/tagging/2020-August/thread.html#54434
>
> https://wiki.openstreetmap.org/wiki/Proposed_Features/Coastline-River_transit_placement

Whew, after reading all of those messages, my take-away is that it's mostly 
what the locals see the water as.

> Third:
>
> While this is ultimately not relevant because the delineation of tags in OSM 
> should be based on verifiable criteria obviously i have never seen any map 
> that displays ocean water and inland waterbodies in differentiated form that 
> shows the Chesapeake Bay as inland water.
>
> Classical examples with differentiated rendering are TPC/ONC (caution: links 
> go to large images):

Pilot maps don't usually have lines deliniating sections of water.  Marine 
charts do, however.

R,
Eric

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


Re: [Tagging] coastline v. water

2020-11-18 Thread Eric H. Christensen via Tagging
‐‐‐ Original Message ‐‐‐

On Wednesday, November 18th, 2020 at 3:31 PM, Joseph Eisenberg 
 wrote:

> Consider that the natural=coastline is defined as representing the mean high 
> water springs line, that is, the line of the highest tides. If the line on an 
> open ocean beach is at the high tide line, it makes sense that all tidal bays 
> and estuaries should also be included in the area outside of the coastline.

Then why the ability to mark natural=water as tidal and as salt?  Clearly the 
ability to use those attributes leads me to believe that just being tidal does 
not make it be coastline.

--Eric

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


[Tagging] coastline v. water

2020-11-18 Thread Eric H. Christensen via Tagging
After a few days of much work, a recent collaborative project to turn the 
Chesapeake Bay from a nothing space outlined by natural=coastline to what we 
considered to be a more accurate relation of natural=water, we've received some 
negative feedback.

The difference of opinion seems to lie in the definition of what we're mapping. 
 The use of coastline is for "seas"[0] while the use of water is for "inland 
areas of water"[1].  Even though the Chesapeake Bay is tidal, there is no 
question that it is an inland waterway (it is completely surrounded by land 
except for the mouth at its southeast side).  The idea of using coastlines for 
basically creating an edge between the land and the nothingness of the ocean 
makes sense when, as far as the eye can see it's only water.

Now, some of the feedback that has been presented[2] is that because it is 
tidal it is part of the sea.  I have pointed out that many rivers and streams 
(and ditches!) are tidal; does that make them part of the sea?  I would not 
think so.  In fact, there are named seas on this planet that are not even 
connected to other water formations (the tiniest, according to the National 
Geographic, is the Sea of Marmara which has an area just less than 12,950 sq 
km, larger than the Chesapeake Bay).

But, tagging the Chesapeake Bay, and its tributaries, as "water" brings several 
benefits to the map and the users.  First, it helps identify the sections of 
water that exist in these areas (this can't really be done with node points as 
there is no way to define start and end points of an area).  There are many 
defined bays, rivers, and streams that make up the greater Chesapeake Bay area. 
 What one may see as one large mass of water is actually many smaller defined 
segments each with their own history.  Second, we can speed up any updates 
(fixes) to outlines of the polygons that happen in these water areas without 
having to wait for the entire Earth's coastlines to be re-rendered.  I suspect 
having less coastline to render would also speed up the rendering of coastlines 
as well?

I would like for the tagging community to clarify the different between "water" 
and "coastline" and when to use each.  The definition on water seems to say to 
use it on inland water but there seems to be, at least, and open interpretation 
of the word "sea" for coastline that is dragging many inland waters into that 
category.

Thanks,
Eric "Sparks" Christensen

[0] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline
[1] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dwater
[2] https://www.openstreetmap.org/changeset/94093155#map=10/37.1620/-76.1581

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


Re: [Tagging] Feature Proposal - Voting - Evacuation Routes

2018-08-24 Thread Eric H. Christensen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

‐‐‐ Original Message ‐‐‐
On August 9, 2018 11:57 AM, Eric H. Christensen  wrote:

> I'm opening up my Evacuation Routes proposal[0] for voting. I think we've had 
> two good sessions of discussions for ironing out the bugs and it's time to 
> get this thing out the door!
>
> [0] https://wiki.openstreetmap.org/wiki/Proposed_features/Evacuation_routes

This has had its two-week marinating period and I've had all positive votes 
(along with two comments).  I'm claiming victory on this and will begin 
updating wiki pages later this afternoon.

I'm planning on sending a message out on the talk-us list to better announce 
this new feature.  Are there any other lists that may benefit from getting the 
word on this so we can go ahead and get these routes mapped?

Thanks,
Eric
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsFcBAEBCAAQBQJbgAssCRCAdqveAkuz0QAAryUQAImXRAzSr8InHDTWuY1s
aTsuXFBUouDC/RyFr+1qAyxaBx2GFf7aQ9S3SV0IbBnKhmBuomuFnfGAvtBZ
20Y2h6IgYoX2/PpEIQ0HfZ1UBdb4I66cXddYBgJ920ACwdmVQVuI7jx+3eaj
q/Ps1vqGgWEzr4lHKofv0eLSR0GWAH1olMsWl0qCpUC1iNSTzCjgYf3d+qtH
Tikl7GVbR7JGiMd24fnuSipj18OojgjWYjATDUJvdt07a/YHjZ9tbx+QYOrD
89ITfPgSw+qlDzNjahPouoRZBGOc9+kGwnXe02RwMfs8Fyp0lpeZ6vjzF410
i4j6jj1PO8B4ubX0ymLIqW5ztVaYc8BgV/qOqbuMpsWouRkaIMYQP3XLHdfn
8+XEQ7gfkr1nQT1G1bXc7zJZvT8SoQ59/Eny6NGO3Sejjcdg/OiAsjBt1Q6E
Y+98rfEGYakXCaBN5+7/R+JhqQBNcvzKOziqgbZ85Z7xQhTBqspPvPECkp9d
dL6yj7yX7bQAZap7BcTwu2h/zsKyWfxdtuaTcoNEJSpG+ZOARgiNzJrWifHv
RP2C7Q2SQl0+HrPAhMPKqDAvWxfB7Je0LGOZxZESBYfOdiOwLnDZuR7TP4JT
8tFBO0Xfo0cjkqArIf9eQP1p7n2sW/CMxFhSImzFgRITvRSMMwEm/ZwzxizA
6kZ6
=NeGb
-END PGP SIGNATURE-


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


[Tagging] Feature Proposal - Voting - Evacuation Routes

2018-08-09 Thread Eric H. Christensen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I'm opening up my Evacuation Routes proposal[0] for voting. I think we've had 
two good sessions of discussions for ironing out the bugs and it's time to get 
this thing out the door!

[0] https://wiki.openstreetmap.org/wiki/Proposed_features/Evacuation_routes

Thanks,
Eric


-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsFcBAEBCAAQBQJbbGRRCRCAdqveAkuz0QAAOIAP/Rd0/+Clv4wMesiWU4Lu
2476V4MTaKpF7wmuHuwnXlf2hti07mxu6H0dt8FzCQAQ1wF9O2+j4o06jWpy
i8qThaSGraU6eiazHrzJQ8cA9doEPFKRZ+piUAapRo7CS6rTOftEGva1jCIa
JfW8KJ3kX2urQ332DTtQ/mc42ifJ7aVfuOp9UcwJ3K9uYHH7bUPlqENB3/DN
vAbbnIl+YlAHtc6/Ye+ZmYKx1NgHgR/xV4iF2wyo2i021Q1C7ykAde8t7yOL
4HMY/O62gv9Ibtp1zE0m0Hr4gzLjMNeOH1047x8+hjNQa0csfucVw3t1pnhm
/TfMLkpLwv5obU4YqPPoiTnziFMeI4hiUtXaXPiIuo1bUJTpQq2pIc+JEceK
lWbsei//6HglwNYsFNYCqS/mgr7sYX9gJXHfrnZ7CPXeOCDRTh4Mrnp1K1AY
q0Uo/Ml/lii0YBj0kBHCNNLx7aTPd2f9HOz7RlQoxLZpDQzuEqo10xW3UpWP
ScjSj9aLZv1BgdyGD86YJEyFoJnhdbzQPF1+vfc/kLB5Q+ndI5oAUdEFHJkL
pWxebiLoTgOZ1tWELdt7gnVG1/8v4tO1BmLY+OhFgOGryJJsRqMcAG+f97HE
6diB7HhvpJfqtLom9VDoyTdY4ol0ET/DPg+JCbwNQ9m8Y2YRF8NZwk7CwoAC
0WdT
=rSoA
-END PGP SIGNATURE-


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


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

2018-08-07 Thread Eric H. Christensen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

-‐‐ Original Message ‐‐‐
On August 7, 2018 11:27 AM, Martin Koppenhoefer  wrote:
> > On 6. Aug 2018, at 06:30, Warin 61sundow...@gmail.com wrote:
> > And it might be better to place it directly in the emergency key?
> > Say emergency=evacuation_route??? Humm emergency says it is not for 
> > relations. Arr well.
>
> I think there shouldn’t be “relations” at all as category for objects to 
> which a tag can apply. Nodes, ways (linear), areas (ways) would seem 
> sufficient for that. Relations can be set to unknown for everything ;-)
>
> The relation category is misleading anyway because it doesn’t include 
> multipolygon relations, and nobody knows what kind of relation will be 
> invented or is already used that creates all kind of geometric thing where a 
> tag could apply to or not.

I'm not certain of all the categories.  I'm envisioning this being more like an 
overlay route like what is used for bicycle routes and bus routes and the like. 
 What are those?

Eric
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsFcBAEBCAAQBQJbabwpCRCAdqveAkuz0QAAQhoP/jILBF94dPUshbEMOWy4
P/A+GOUNUW7IvEZSTjngPiT1xillNb2s529fBQQKB7mgj730r1qhLlJeNAQr
jMI5ffqX2K1DehBrhCd6AJD3bizYqiywHVhqmHPtJ0Zg0eQ26YV5HBLmUPcf
yol64IhWm27zhgdR//ZwGHv40d48O4672KEXYKJK6kZblvQWmV1t0uZaWy2/
wdnTJngLqkgnXxOxl7t45k3N7o4RppxjwemKwf5vAxDsmUO2S3Ap8eWj7orF
+qIGiU8N+WIcr5p700xDy/DygFNXReMUKuKLTjnfRYzQEOvzaSGd98SdZ6PC
u8FarWX5n90To2539D4RruuPgEzWjrAYt6JK5gUQdTJuIeGIDHmXqDwKnGFe
5hfnqV5kFXvOZoqgdxURLFKgwR4jFiPagwzCtEwt+1DG6MsLTOkXqOUEMwBg
Lj8bj7PFVxlAPrWyMCPjeHr/OU0v252yqo3/knk3C1QjPakF+UFxEpbAUpJ2
IZBE0EzPVuo4jDna/ifEY/VDgQe5JHXAtso8tHZTRsaGL+rff9uDOxOrlsjA
dTpq630s19Jwn2cwZNdPz/sTAUMaBlZ6gv30PIZmpssMvmtq9JSKcrWYhX72
Q82uILVn/oohQ77hIFi9wdPhfg9kWwCS4Eq3IDYAnY08wxJXrCrCCIQDQbYa
e5sr
=+kwJ
-END PGP SIGNATURE-


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


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

2018-08-06 Thread Eric H. Christensen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

‐‐‐ Original Message ‐‐‐
On August 6, 2018 2:02 AM, Warin <61sundow...@gmail.com> wrote:

> On 06/08/18 15:27, Eric H. Christensen wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > ‐‐‐ Original Message ‐‐‐
> > On August 6, 2018 12:30 AM, Warin 61sundow...@gmail.com wrote:
> >
> > > I'd think this should be a relation - not a way.
> > > At the moment the proposals says it is only a way.
> > > And it might be better to place it directly in the emergency key?
> > > Say emergency=evacuation_route??? Humm emergency says it is not for 
> > > relations. Arr well.
> > > We went down this path, I think, last summer. The expectation is that 
> > > these route made up of roads. I'm not sure why one would include a node 
> > > in this. This is likely going to be part of the emergency project but 
> > > probably not the emergency key which isn't really for routes.
>
> I have not mentioned 'nodes'.
> On the proposal page - in edit mode there is:
> {{Proposal_Page
> |name = Evacuation Route
> |user = Sparks
> |key = evacuation_route
> |value = *
> |type = {{IconWay}}
>
> The type should be {{IconRelation}} not {{IconWay}}.
> As it is with {{IconWay}} there will need to be new ways created for the 
> evacuation route
> rather than use the existing ways that are roads/paths etc as members in a 
> relation.
>
> And I would think there need to be rules for the relation, for example;
> start at one end and have each member/way in sequence to the finish, the 
> finish might be required to be in/near the 'safe place'.
> This would save the forwards backwards thing, just like in Public transport 
> v2.

Ahh, yes, sorry, I see what you're talking about now.


> > > Rendering... yes .. a rendering for emergency use would be good.
> > > Possibly this can be done for small areas rather than the world.
> > > Emergency evacuation centres, routes etc.
> > > I'm not sure I understand this. I suspect these types of routes are 
> > > preplanned in many different countries.
>
> Yes. But I'm thinking of the rendering. I think that would be done for local 
> areas, not the entire world.

Yeah, this would definitely be more smaller areas (towns, regions, states, 
islands).
>
> > > Evacuation routes may also be made for other things .. e.g. fire .. so 
> > > I'd add a '/*' at the end to accommodate things we have not though about.
> > > Even if you create a route for a fire, and I'm assuming you're talking 
> > > about a building fire, you'd be showing routes inside of a building which 
> > > would require ways. I don't think the existing proposal would prevent 
> > > someone from expanding to such things but I'm trying to tackle the 
> > > problem of evacuation routes along roads that have been preplanned for 
> > > emergencies and disasters.
>
> Wrong kind of fire .. though those too might one day be mapped.
> But I mean forest fires/wild fires/bushfires depending on what part of the 
> world your from.
> But I would tag them as 'fire' rather than do all the different ways that 
> people refer to them.
> I'd still add the '/*' to it. Just in case.

Oh sure.

--Eric
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsFcBAEBCAAQBQJbaFNDCRCAdqveAkuz0QAAH0kQAJW09vrmW4ZGwdbO88P9
lUb2f/0AlgOMaRezh91SZqoqhoDfOhMr8qB63IGU2xbvvde9Scsj1U06Clob
zr+OOvyWZIhAa/ayKPlxhkHtjAlj3VxNCaLg1T/1kUJN2avYFgMD43ahdwGP
Cn2bmUcQijcfEZXOW5r5JeF0Xy+DeNOg2ST2T3e4EGSUIWZpC2FWnGdpQ5nA
G1pNfGX6GbMafYjZMQ245VlpfzOe5qeU76nAAQ3Ek9Rk5L3eFa/HegeV2Pwm
QhPBR6jz5rGA51a15gvOpDUQXiVcbmqyg0eNx6yQi8IdXo51RVvb8oT+nZCQ
monRbHeR5BX149hTqFQTaUJC/F2qmzgGg2ZsmlCXeyDfkEzYTj7WttePD/QU
/r8rLs5po0mSVli4OzYrhzkdfb0jPHhJwu+XDQ6zHqD8onWZDEMBbL70lWfZ
5n/H1qJZJBLxD2coR4uujESA/DTkzlY9aAteME/I7yb4JQr5+NEgNk7pYH2Y
vcTkpTZ5TwpE9YpMIwDc+eHKSHtW84oETiJ+o8lHpjO3ormZpspYisPz7l07
teQYrJPHYwYcMvZ45EV20PMURKOCkxErgIa6uOft9jBqDE2B3klc7ovDsp4l
RZIvMbQji/keed3cHEN56fX1sRjc52C0SPCZprkmHFcp2padKbRpv1oVgxub
KTBa
=N+HH
-END PGP SIGNATURE-


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


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

2018-08-05 Thread Eric H. Christensen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

‐‐‐ Original Message ‐‐‐
On August 6, 2018 12:30 AM, Warin <61sundow...@gmail.com> wrote:

> I'd think this should be a relation - not a way.
> At the moment the proposals says it is only a way.
>
> And it might be better to place it directly in the emergency key?
> Say emergency=evacuation_route??? Humm emergency says it is not for 
> relations. Arr well.

We went down this path, I think, last summer.  The expectation is that these 
route made up of roads.  I'm not sure why one would include a node in this.  
This is likely going to be part of the emergency project but probably not the 
emergency key which isn't really for routes.

> Rendering... yes .. a rendering for emergency use would be good.
> Possibly this can be done for small areas rather than the world.
> Emergency evacuation centres, routes etc.

I'm not sure I understand this.  I suspect these types of routes are preplanned 
in many different countries.

> Evacuation routes may also be made for other things .. e.g. fire .. so I'd 
> add a '/*' at the end to accommodate things we have not though about.

Even if you create a route for a fire, and I'm assuming you're talking about a 
building fire, you'd be showing routes inside of a building which would require 
ways.  I don't think the existing proposal would prevent someone from expanding 
to such things *but* I'm trying to tackle the problem of evacuation routes 
along roads that have been preplanned for emergencies and disasters.

Eric
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsFcBAEBCAAQBQJbZ9xPCRCAdqveAkuz0QAAWZIP/3+0RLerwgB5ODpYHu45
JBZQmuaccYarcF9vWP20nN9lxhm0RCNQfXodBnPQgF9Ms1w+LW/lobLYyViV
cRy8Rbvgt68OzZi+Ll5KovsJbiAAD+03SZmZfVnW4W+kZ5A9TDk7MQjucpMh
dDnI6K/lxEC/jEuGj5R5nflVn24PZdcDseiK1SEvNg+qlLG/tatbpQB0p0nu
C+T/eAJA+uRWQiRlevoQ6notgOnxTDp/1k74O8tnD/P85+Pystf7UbUWJcCV
bXf8uG9TtKN9ccY3tXC1VD5TbAf+NQeSPoTvuMomBUXWBPI66+EyjS+gdUd7
eZJitOYChN3TWM6ydovwKc1PBj0u7jjz8w+CIQhDVtmPGRR+8WHiyCbIWxn+
PuwSJ4Lq88QcVPL4/qQ0+9dYilF4sF5dmC5byrxIVnAqyH2tccoLiIJTBwyE
pPQOjPOtxp3FAPj3DSHBPJfWfsCrDHS9a0fYus6p6OwepjElX5T1Nx2O7+b4
xw6iBmGopsh9RkI1XuH8SCXr1hxrGAnTcCFNi17Ch18c6wXd67n4qRb10OGk
fzqoPlsLGeTxhCg+j53fu1T2rurIOWqKqqHID9OdZ67pXVPjyH94KUCMU8BG
budfddKeR03CGxTt7oejpP2kDHfp9pyJv/tC9viDQVHVQMo1kvDw9mh+dYcU
JaVs
=XRZZ
-END PGP SIGNATURE-


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


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

2018-08-05 Thread Eric H. Christensen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Last year I made a feature proposal[0] last year regarding evacuation routes.  
There were a couple of recommended changes to the RFC[1] and while I agreed 
with them I 1) failed to make them and 2) got side tracked on a couple of other 
initiatives.  Now that it's hurricane season, again, here in the Eastern U.S. 
I've come back to this and am hoping to get this completed this time.

I've changed this from being a key to being a route, which makes better sense.  
Does anyone see any other changes that need to be made or can we go ahead with 
a vote?

Thanks,
Eric

[0] https://lists.openstreetmap.org/pipermail/tagging/2017-September/033340.html
[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Evacuation_routes
-BEGIN PGP SIGNATURE-
Version: ProtonMail
Comment: https://protonmail.com

wsFcBAEBCAAQBQJbZ7GNCRCAdqveAkuz0QAAglIQAID9i9veNNDUZiFVvNyl
J4GA3cEsCxfYZCDvE2d/SPcZoGWN322FKgsvtW8VUaGB5ZsYFBs0nE70VDHY
WLxmURjOPb3l+w5w0r32TAuMzWxpz9rMHephgTfbmOWsvV3JNt3cTkXcgY47
2cxZu/CcFn2yemJsgPVx7ENeWdUTjwzdvOe6lWlqCt6yK6A+1VjZEDOK54CW
fGaWlEQe7HRq+oVyTSAgNUEKjjViyLjx2BDuH7Sx1GVW98AocJqrYmDl3vEq
LTl8pbBJ39iSXjBB6B5alN9JYWegtaF40TSBPT8m1ey3Fy0YF9hbZbL8qXTu
kMQIvfDcw+vabO+ZeJkhozsMi/0IQvBZzHsJrYOJW2hbiSZHg1508pbiugJv
juMqaYJvzie7cPNBmW/fI3d06/4GeenzBBKgF6TwANbEKyfgjZrROVjug1A9
p+RHXchjYIxLrrHKCmLQzD+LjmMcBvjxrGBnAEnpdzizz2fkuwM0P2tpaAO8
bkNIBcXUJW0d+Ev8pnOzf28gCDJNvdP3FHfTvDOcDnTCmFBKtLOf7O4pNuE4
lNBnwLa4xes25pOgZId5Pn+B/qJ5TH9s9EVUJwYFW33n/IU2yScDTTYGsa+V
4YEFvyU2G5Ch4N5zCLKtgP4ItYYFGg3MpiXV5Jm3M6quuhmwGCTllRYODY9a
xxkH
=BWIM
-END PGP SIGNATURE-


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


Re: [Tagging] Fire hydrants vs suction_point

2017-08-17 Thread Eric H. Christensen
On August 17, 2017 11:38:10 AM EDT, Richard Welty  
wrote:
>On 8/17/17 10:25 AM, Eric Christensen wrote:
>>
>> That's not really what's being discussed here.  A non-pressurized
>> hydrant wouldn't be attached to a tank at all.  It would require a
>fire
>> engine to suck the water out.  It does not look like a traditional
>fire
>> hydrant at all.
>there are always exceptions. not far from me, there's a traditional
>hydrant of the type normally used with pressurized systems, but
>it's sourced from a pond. the reason is that the pond is elevated, some
>distance from the road, and they need to keep the barrel empty
>when it's not in use for the usual reasons.
>
>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

Then that is a pressurized system and doesn't require drafting (there is 
gravity at work if the pond is elevated above the connection point).

The whole point of a dry hydrant is to make drafting easier. Drafting is the 
pulling of water up by use of a pump.  If the water is coming down then you 
don't need to pull the water and can do damage  to many water systems if you do.

Eric 

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