[Tagging] Changing amenity=bear_box to amenity=bear_cache

[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

[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&lat=39.14649&lon=-75.07302&layers=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&lat=40.63628&lon=-73.93525&layers=B000
>
> Tampa Bay: 
> https://www.openstreetmap.de/karte.html?zoom=10&lat=27.80801&lon=-82.63368&layers=B000
>  - outside of the natural=coastline
>
> Galveston Bay: 
> https://www.openstreetmap.de/karte.html?zoom=10&lat=29.49869&lon=-94.94249&layers=B000TT
>  - outside of the natural=coastline
>
> San Francisco Bay and connected bays: 
> https://www.openstreetmap.de/karte.html?zoom=10&lat=37.79939&lon=-122.06911&layers=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&lat=47.59544&lon=-122.39252&layers=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

Re: [Tagging] coastline v. water

[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

[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

[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

[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 - RFC - Givebox

[Eric Theise]

People's Park in Berkeley was known for, among other things, its "free box".
https://www.peoplespark.org/wp/free-clothing-box/

Might be a less encumbered term than "givebox" given the trademark issue
Paul raises.

Eric


On Mon, Jan 6, 2020 at 3:38 PM Jmapb via Tagging 
wrote:

> On 1/6/2020 5:41 PM, Markus Peloso wrote:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Givebox
>
>
>
> A facility where people drop off and pick up various types of goods in the
> sense of free sharing.
>
>
>
> Hi
>
>
>
> Based on the https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse
> and the  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase
> tag I describe a tag for facilities similar to public bookcases but with
> all kinds of (none food) goods.
>
>
>
>
>
> Hi Markus, why not just "reuse" amenity=reuse? It already has some small
> measure of adoption. (Taginfo shows 68 uses.)
>
> J
> ___
> 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] wiki template help

[Eric Theise]

Created a table of recommended values manually and ditched the idea of
multiple pages created using ValueDescription.


On Tue, Dec 17, 2019 at 5:54 PM Eric Theise  wrote:

> Hi everyone,
>
> I'm writing up the documentation for mimics. It was clear from comments
> that people desired a stronger statement of the recommended values for the
> key.
>
> I was under the impression that by using a KeyDescription template at
> https://wiki.openstreetmap.org/wiki/Key:mimics and ValueDescription
> templates at URLs such as
> https://wiki.openstreetmap.org/wiki/Tag:mimics%3Dtree I would be able to
> include a collection of the latter into the former with a single directive.
>
> Should I be able to do this? What would the directive be? Is there an
> example of best current practices somewhere?
>
> Appreciate the help, Eric
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] wiki template help

[Eric Theise]

Hi everyone,

I'm writing up the documentation for mimics. It was clear from comments
that people desired a stronger statement of the recommended values for the
key.

I was under the impression that by using a KeyDescription template at
https://wiki.openstreetmap.org/wiki/Key:mimics and ValueDescription
templates at URLs such as
https://wiki.openstreetmap.org/wiki/Tag:mimics%3Dtree I would be able to
include a collection of the latter into the former with a single directive.

Should I be able to do this? What would the directive be? Is there an
example of best current practices somewhere?

Appreciate the help, Eric
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Feature Proposal - Voting Result - Mimics

[Eric Theise]

Voting was open from 29 Nov 2019 through 13 Dec 2019. The final tally was
21 yes votes, 0 no votes, and 3 abstentions.

Thanks to everyone who voted and/or participated in the discussion.

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

[Tagging] Feature Proposal - Voting - Mimics

[Eric Theise]

Hi everyone,

The two week discussion period about this feature has elapsed and I am
calling for a vote at
https://wiki.openstreetmap.org/wiki/Proposed_features/Mimics

You may remember that the proposed feature applies to cellphone masts and
towers that are disguised, to varying degrees of success, as trees, cacti,
or other features of the natural or built environment. Initial discussion
was productive in uncovering that the practice of tagging these structures
"Tower:construction=concealed" was counterproductive.
While communications equipment contained in these structures may be
concealed the masts and towers themselves often stick out like a sore thumb.

Discussion is archived in the threads "disguised communication towers" and
"Feature Proposal - RFC - mimics" at

https://lists.openstreetmap.org/pipermail/tagging/2019-November/thread.html

Thanks in advance for participating in the vote and best wishes for a happy
Thanksgiving weekend to US-based mappers.

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

Re: [Tagging] Feature Proposal - RFC - mimics

[Eric Theise]

Hi Graeme,

Thanks for your input. The guidelines suggest keeping tag names as short as
possible and underscored compound words add complexity.

If this fell under the camouflage principle of "crypsis" I'd definitely use
something like "blends_with" but I think "mimics" is well-understood and
precise so I'm going to leave that in the proposal.

Thanks, Eric

P.S. https://en.wikipedia.org/wiki/Camouflage


On Fri, Nov 15, 2019 at 4:06 PM Graeme Fitzpatrick 
wrote:

>
>
>
> On Sat, 16 Nov 2019 at 08:40, Eric Theise  wrote:
>
>>
>> The first keys I came up with included "_as" – "disguised_as",
>> "camouflaged_as" – which was worse. Mimesis is an agreed-upon name for one
>> principle of camouflage so I believe "mimics" to be a rather good key.
>>
>
> I quite like "disguised_as" :-)
>
> "looks_like" maybe?
>
>   Thanks
>
> Graeme
> ___
> 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] Feature Proposal - RFC - mimics

[Eric Theise]

I've updated the proposal to incorporate Paul Allen's suggestion that the
practice of using tower:construction=concealed be deprecated when a mast or
tower is tagged with mimics=*.


On Fri, Nov 15, 2019 at 2:39 PM Eric Theise  wrote:

> Hi Paul,
>
> Thanks for the quick feedback.
>
> On Fri, Nov 15, 2019 at 2:20 PM Paul Allen  wrote:
>
>> On Fri, 15 Nov 2019 at 20:54, Eric Theise  wrote:
>>
>>>
>>> I propose to introduce the key mimics to remedy this.
>>>
>>
>> I'm not sure "mimics" is a good key, but I can't think of a better one.
>> However...
>>
>
> The first keys I came up with included "_as" – "disguised_as",
> "camouflaged_as" – which was worse. Mimesis is an agreed-upon name for one
> principle of camouflage so I believe "mimics" to be a rather good key.
>
>
>> Here is an example where what the tower mimics is included in the note
>>> field.
>>> {
>>>  "type": "node",
>>>  "id": 567065909,
>>>  "lat": 33.7925108,
>>>  "lon": -84.3533616,
>>>  "tags": {
>>>"man_made": "tower",
>>>"note": "pine tree",
>>>"tower:construction": "concealed",
>>>"tower:type": "communication"
>>>  }
>>> }
>>>
>>> In this case note would be simply be replaced with mimics="pine".
>>>
>>
>> As others have said, tower:construction is a bit of a mess.  I'd suggest
>> that if there is a
>> mimics=* (or whatever key is settled on) it is unnecessary to state that
>> it's concealed.
>>
>
> Great point, thanks. I'll re-word the proposal to that effect and post
> back here once I've done so.
>
> Eric
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - mimics

[Eric Theise]

Hi Paul,

Thanks for the quick feedback.

On Fri, Nov 15, 2019 at 2:20 PM Paul Allen  wrote:

> On Fri, 15 Nov 2019 at 20:54, Eric Theise  wrote:
>
>>
>> I propose to introduce the key mimics to remedy this.
>>
>
> I'm not sure "mimics" is a good key, but I can't think of a better one.
> However...
>

The first keys I came up with included "_as" – "disguised_as",
"camouflaged_as" – which was worse. Mimesis is an agreed-upon name for one
principle of camouflage so I believe "mimics" to be a rather good key.


> Here is an example where what the tower mimics is included in the note
>> field.
>> {
>>  "type": "node",
>>  "id": 567065909,
>>  "lat": 33.7925108,
>>  "lon": -84.3533616,
>>  "tags": {
>>"man_made": "tower",
>>"note": "pine tree",
>>"tower:construction": "concealed",
>>"tower:type": "communication"
>>  }
>> }
>>
>> In this case note would be simply be replaced with mimics="pine".
>>
>
> As others have said, tower:construction is a bit of a mess.  I'd suggest
> that if there is a
> mimics=* (or whatever key is settled on) it is unnecessary to state that
> it's concealed.
>

Great point, thanks. I'll re-word the proposal to that effect and post back
here once I've done so.

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

Re: [Tagging] disguised communication towers

[Eric Theise]

I've emailed the list with a Request For Comments on a key for
communication masts and towers: mimics.

Thanks, Eric


On Thu, Nov 14, 2019 at 1:57 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 14. Nov 2019, at 22:04, Warin <61sundow...@gmail.com> wrote:
>
> I don not understand what a "a dome covered guyed lattice tower" is
>
>
>
> was thinking about something like this with guy wires:
> https://images.freeimages.com/images/large-previews/9f3/radome-1522847.jpg
>
> 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

[Tagging] Feature Proposal - RFC - mimics

[Eric Theise]

Since 1992 cellphone masts and towers have been disguised as trees, cacti,
and other features of the natural and built world. The suggested practice
for tagging this infrastructure is to use man_made=tower or man_made=mast
with tower:type=communication in combination with
tower:construction=concealed. Unfortunately this does not provide a
mechanism for recording what the mast or tower is disguised as.

I propose to introduce the key mimics to remedy this.

Here is an example where what the tower mimics is included in the note
field.
{
 "type": "node",
 "id": 567065909,
 "lat": 33.7925108,
 "lon": -84.3533616,
 "tags": {
   "man_made": "tower",
   "note": "pine tree",
   "tower:construction": "concealed",
   "tower:type": "communication"
 }
}

In this case note would be simply be replaced with mimics="pine".

I have no connection with Cell Trees, Inc., but a list of suggested values
might use their product offerings as a jumping off point – broadleaves,
eucalyptus, saguaro, palm, pine, "water tower" – with the more generic
values cactus and tree allowed, all to be extended as other real world
examples surface.

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

Re: [Tagging] disguised communication towers

[Eric Theise]

On Wed, Nov 13, 2019 at 1:17 PM ael  wrote:

> On Wed, Nov 13, 2019 at 01:00:29PM -0800, Eric Theise wrote:
> >   tower:type=communication
> >   tower:construction=concealed
> >
> > and either man_made=mast or man_made=tower should cough up cellphone
> towers
> > masquerading as cacti, palms, pines, flagpoles, and such. But apart from
> a
> > note="pine tree" that jumped out at me I'm not finding much. I have to
> > assume I'm barking up the wrong tree (sorry).
> >
> > Could any of you suggest a better search strategy?
>
> Not really. I mapped such a tower a few years ago, but would not have
> thought of adding  tower:construction=concealed  . I suspect that
> scheme did not exist back then. Perhaps I might add it sometime and use
> it in future now that I am aware of it.
>

I bumped into it at https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dtower.
It isn't even on the mast page.

Do you recall how you tagged the camouflage of the tower you did map?

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

[Tagging] disguised communication towers

[Eric Theise]

Hi everyone,

>From my morning reading it seems that entities tagged with

  tower:type=communication
  tower:construction=concealed

and either man_made=mast or man_made=tower should cough up cellphone towers
masquerading as cacti, palms, pines, flagpoles, and such. But apart from a
note="pine tree" that jumped out at me I'm not finding much. I have to
assume I'm barking up the wrong tree (sorry).

Could any of you suggest a better search strategy?

Thanks in advance.

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

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

[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

[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

[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

[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

[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

[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] Let's get (quite) rid of units and their multiples in OSM values

[Eric Gillet]

I agree with François and Marc.

Le ven. 27 juil. 2018 à 13:28, Warin <61sundow...@gmail.com> a écrit :

> Unfortunately not everyone uses the same units... heights are in meters,
> feet .. depending on where you come from or what activity you follow.
>

You're right, but as OSM is an international database, standardizing data
(meaning units too) is a must. Just like phone numbers where although local
residents usually don't use ITU prefixes (+XX), phones numbers should be
entered with those prefixes to ensure valid usage for consumers.

Le ven. 27 juil. 2018 à 21:21, Paul Allen  a écrit :

> If you're navigating somewhere unfamiliar to you and GPS isn't giving you
> an
> accurate signal, what you're interested in is what signs actually *say.*
> Because
> when you're in confusing territory a speed sign, or a bridge clearance, or
> whatever
> may be a significant clue.  Knowing that the speed limit is 40.2336 km/h
> doesn't tell
> you to look for a sign saying 25 mph.
>

Most GPS/routing applications (including OSMAnd, Google maps) already
convert maxspeeds to user's prefered unit. I do not remember ever seeing a
fractional legal speed, so by rounding the value you can obtain the sign
value with good confidence.
Another thought : Even if maxspeed=* on highway=* could be in kph,
traffic_signs could still be mapped with local, explicit or implicit units.
That would solve both problem.

Le ven. 27 juil. 2018 à 22:22, Tobias Knerr  a écrit :

> I currently prefer explicit units in the database because they document
> the mapper's intent and avoid ambiguity.
>
> Defaults aren't always obvious. For example, people mapping pipelines
> have documented millimetres as the default for diameter=*, but it seems
> tree mappers haven't gotten the memo and (reasonably) assume it's
> defaulting to metres like height=*, width=* or circumference=*.
>

An unit selector can be implemented in editors quite easily. StreetComplete
already does work with different units for example.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] landuse=basin

[eric]

Hi Warin, 

I think landuse=basin is correct, because water=basin implies, for me at least, 
that there is normally water in it. While there are many basins that are 
normally dry. Here are several basins that are only filled during extreme rain 
events: 
https://www.openstreetmap.org/search?query=Parsberg#map=17/49.15540/11.70908

 

Eric

 

Von: Warin <61sundow...@gmail.com> 
Gesendet: Mittwoch, 18. Juli 2018 09:42
An: Tag discussion, strategy and related tools 
Betreff: [Tagging] landuse=basin

 

Hi,

The present OSM meaning of landuse=basin is "An area of land artificially 
graded to hold water."
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dbasin
This does not distinguish it from water=reservoir
OSM defined as "A reservoir or artificial lake used to store water."
https://wiki.openstreetmap.org/wiki/Tag:water%3Dreservoir


I think it should have the word "temporarily" add to read 


"An area of land artificially graded to temporarily hold water."


I see it as similar to the bathroom basin - it holds water, but not all the 
time. 

Thoughts? 

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

Re: [Tagging] esperanto=yes

[eric]

Hi, 

 

language information could be an interesting tag for tourist places, schools, 
etc. 

 

but I think that this method is not the best one. 

 

I’d expect something like: 
language=eo 

 

Or with multiple languages

language=en;de;fr;es;eo

 

language:signs=en;de;fr

language:spoken=de;en

language:menu=cn;en

 

Eric

 

Von: Michał Brzozowski  
Gesendet: Donnerstag, 28. Juni 2018 12:22
An: Tag discussion, strategy and related tools 
Betreff: [Tagging] esperanto=yes

 

Hi,

 

Today user przem started to add esperanto=yes to two kinds of objects

- streets named after Zamenhof (creator of it)

- schools which presumably use or teach it

 

For the first case it would be correct to tag name:etymology:wikidata=Q11758

 

But how about the second case?

esperanto=yes seems too vague to be useful, and is a precedent (I didn't see 
english=yes etc. being used). It seems to be a catch-all for everything related 
to esperanto, not unlike your typical hashtags in social media.

 

Michał

___
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

[Eric Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/07/2017 04:08 AM, Nick Hocking wrote:
> The list of emergency centers would be very much dependent on where
> the threat is and what the nature of the threat is.

As a former emergency management planner I'll go on the record as
saying... kinda.  Generally speaking, most emergency plans (and, by
extension, emergency resources) are considered all-hazards in nature.

> Therefore I see these as being loaded (by the relevant authorities)
> only when a state of emergency is declared and only for the areas
> affected.

Emergency managers generally make this information publicly available
well in advance of any emergency so people can make proper plans to
get to their shelter or to obtain emergency resources.  There really
isn't time to start making declarations, uploading data, and hoping
people will be able to get rendered data when a tsunami or tornado is
on the way.

> These locations would therefore be available (on OSM) online, 
> immediately, and available for download shortly after. Since the
> areas are relatively small the downloads would not be a big issue.

Define "small".  Right now you have Hurricane Irma taking aim at the
states of Florida, Georgia, South Carolina, and North Carolina.  This
is not including the surrounding states that would also be taking in
evacuees.  This storm, larger than the state of Ohio, is going to do
some damage on a very large swath of land (and already has to quite a
few islands!).

> Once the state of emergency is rescinded, the data could be
> deleted.

Why would you delete data that is still valid and useful?  Shelters
take months to identify, work up agreements with building owners and
who will actually manage the shelter, determine how to supply the
shelter with supplies, how to staff the shelter, and many other
things.  One doesn't just show up to a building and declare it a
shelter nor does one just remove a shelter from a list after a
disaster (unless it's been shown to have been ineffective).  These are
well thought out, planned for, and exercised resources.

> Since these tags would only be used by the authorities, I believe
> that they should be unique to them.

I don't even understand this statement.

I'm a proponent of putting emergency information onto the map so
people have this information with them at all times.  No matter where
in the world you are you should be able to obtain information about
finding shelter, evacuation routes, water, supplies, and information.
 Some of this information will be dynamic but much of this information
is permanent.  The dynamic resources will be made available via
permanent information resources so documenting those will help fill
the gaps.

- --Eric
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEERiNfHJ4f0jHRHow5g9FPLsqcWWwFAlmxsBAACgkQg9FPLsqc
WWzg4wf+IpcJ2JgxfZtMZMRggdYFj11q4JbYl5mPxyU96JJBGn9qjG7gvGX0JCV4
uYByJv5RUwiKrURdlxXOUw7lf/cJQGnljFVOaSZ+eVDy8WqRnMwcTVnoxZlMpVIF
1H1XhkW2Qe/4+AYNr0a1mIQPHmqNx+kCn/nBw2ZklzuWW/tpsZma4GJqtTlw/yE0
3YF7IbUn5odhRy7O7ptrFqmU8EU9k0e6ufntWehIt6jCgkVcYItgCWuRGbyuwxJj
uEhBuLyI8vhn8khSZ+UEQEaoJJcwYZCS33IGU8vgkV7pkWJsoivnA2uXgu1Sdz8p
V7S6BZc0fcDeDawEoQqSFvN5nvBzOg==
=tLiF
-END PGP SIGNATURE-

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

[Tagging] Feature Proposal - RFC - Evacuation Route

[Eric Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

https://wiki.openstreetmap.org/wiki/Proposed_features/Evacuation_routes

Emergency evacuation routes, with direction, for various types of
emergencies.

Thanks,
Eric "Sparks"
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEERiNfHJ4f0jHRHow5g9FPLsqcWWwFAlmxXAQACgkQg9FPLsqc
WWxKnggAgJyp03FRt4xl7Q8TOVyiI+pS9w02plPCzVIIvyjgTAfLPs7VGpvJEaDD
61KhI+2JbRj2hLstoFGCDDFzbkUkB/fUNrDSma3UcV+9zfv6Y9dcROQafdHL64DE
jWSPY9CNEhPhEXhzLHifA4BQf2xOX+DjkqdUm0PJatbUXckwgwlq7jCOfQdjmrIw
w3RC0HarbRV3qC/nv77QzrfjK2QcIbr9IuY690I1EKQC7p6CjOki3IVkh7SPmrNx
DCm5/KAMsklUhqwlGQjp6MpcRcsj4DQYa99kkZp3xie9FWWMdUpIlUL0QjRW8OW3
MAmfzT584H8uKsLB9Cr1UqapTk21lw==
=Lwpi
-END PGP SIGNATURE-

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

Re: [Tagging] Fire hydrants vs suction_point

[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

Re: [Tagging] Fire hydrants vs suction_point

[Eric Christensen]

On 08/17/2017 10:47 AM, Viking wrote:
> In the case of commercial/industrial local water networks fed by pumps, we 
> all agree to use emergency=fire_hydrant. Because externally (at least here in 
> Italy) they are not distinguishable from hydrants fed by public mains and 
> they have the same usage.

+1

> For the tag emergency=dry_hydrant, at this point I wouldn't introduce it, 
> because we already have emergency=suction_point that covers a wider range of 
> cases, as Moritz says.

+1

> Productivity can become flow_capacity, as it is for fire_hydrants.

+1


--Eric

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

Re: [Tagging] Fire hydrants vs suction_point

[Eric Christensen]

On 08/17/2017 10:12 AM, marc marc wrote:
> Hello,
> 
> Le 17. 08. 17 à 14:50, Moritz a écrit :
>> the hydrant (by the meaning of the word) is something connected
>> to the water main ;)
> If I read the previous wikipedia link, there are pressurized hydrant and 
> not-pressurized hydrant.
> If wikipedia use the word hydrant for both, maybe the "by the meaning of 
> the world" is that.
> A common tag for both + a subtag for pressurized or not isn't enough ?
> Or you like 2 tag for render and/or to avoid the need to check subtag ?
> 
> When I'm walking on a street and find "something that give water to be 
> used against fire" and I read "2 bars" on it, I have no way if it's 
> connected to a pressurized network or if it's a tank with a pump in it.
> I didn't even know it existed before reading it in this discussion.

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.

Many of the ones I'm used to look like this:

http://www.dof.virginia.gov/fire/dryhydrant/index.htm

There is no confusing this with a pressurized hydrant.

--Eric

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

Re: [Tagging] Fire hydrants vs suction_point

[Eric Christensen]

On 08/17/2017 08:50 AM, Moritz wrote:
> But "dry" hydrants are always connected to other water sources like
> ponds, wells, water_tanks.
> They are not isolated things on the field. So you have the "dry" hydrant
> which is next to a pond/lake/etc. and
> connected to it.

A dry hydrant is just a convenient drafting point for getting water in
rural areas.  Where I used to work as a firefighter we had designated
water sources that we could use to supply tankers in the event of a
fire.  Many times it would be dangerous to get too close to the edge of
a pond with the fire engine or would require more suction hose to reach
to water than we would usually carry on the engine.  In those areas we
would install these dry hydrants.  Hook up to them with a short piece of
hard suction hose, pull a draft, and flow water.

I would suggest marking designated water sources as that: water sources.
 If they have a dry hydrant then all the better and that should be
mapped to make it easier to locate (especially at night).  But dry
hydrant or not, a pond, lake, canal, etc, that is suitable for fire
water source operations should be mapped as such.

Of course such ponds, lakes, canals, should be designated by the local
authority.

--Eric

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

Re: [Tagging] source tag on object <> changeset

[Eric Gillet]

On Sun, Jul 23, 2017 at 12:09 AM, marc marc 
wrote:

>  > On Sat, Jul 22, 2017 at 08:51:16PM +0200, Simon Poole wrote:
>  >> a) good practice to tag source on the changeset.
>  > I always include a fairly comprehensive list
>  > of sources on changesets, but *need* individual source tags
>  > on objects. Otherwise, subsequent mappers come along with
>  > far inferior information and wipe out my many hours/days/years of
>  > careful work on the ground.
> This problem exists for any tag. Where does the localization for a
> crossing come from? Gps / aerial? What is the date of this ?
> I don't imagine that we triple all the tag to have source+date just in
> case someone doesn't read changesets when he thinks that an object needs
> improvement.
> If he doesn't read changesets, will he pay attention to your source tag?
> In my edit, I delete often previous source tag.
> Because if I modify an object after survey, a previous source=bing for
> example on an object no longer say anything usefull.
> I don't add source tag on object for the same reason.
> What would be useful is to have a link beside each tag indicating the
> last changeset that touched it.
> Or maybe a josm plugin can parse the history of the object
>

I recently had the same discussion regarding a Mapillary blog post
,
and completely agree on the points you (Marc) raised.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] fire hydrants

[Eric H. Christensen]

On June 10, 2017 12:23:22 PM EDT, Richard Welty  wrote:
>On 6/9/17 5:18 PM, Marc Gemis wrote:
>> o, I forgot to include the link to the picture.
>> BTW for fire hydrants of the pillar type, it can in indicated on them
>> as well, see [2] There is a BH100 on it, so the diameter of the
>> underground pipe is 100 in this case
>in the US some localities paint their hydrants to reflect the diameter
>of the main. this is not standard so you need to check with the local
>districts.
>
>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

Well, there is an NFPA color standard, IIRC, based on the flow rate of the 
largest diameter fitting on the hydrant. This is slightly different than the 
size of the main it is hooked to as a five-inch connection is going to flow 
more than a three-inch connection on the same sized main.

 I've seen this used in larger municipalities; wish it was done more.

Eric

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

[Tagging] Evacuation Routes

[Eric Christensen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Greetings from Maryland (USA),

Here in the USA we're getting prepared for our Hurricane Season[0].  I
worked for ten years in the disaster preparedness world and did a lot
to help people prepare for the inevitable.  With that said, I'd like
to make a recommended change to the 'evacuation_route' key[1] in hopes
of making it more useful without, hopefully, making it too complicated
for the cartographers out there.

The current tagging system is likely not being rendered by any
software out there and seems to be a one-off.  To me this *should* be
a type of route which would show direction and, perhaps, the type of
emergency when this route would be active.

This type of tagging shouldn't be specific to the USA and should be
generic enough to be globally used.

On the rendering side of things, I could see a switch being toggled
that would gray out everything but emergency routes, emergency
resources (shelters, food, water, etc), and other resources that could
be turned on individually.  One could even store evacuation points and
meeting locations on these maps making it much easier for someone to
navigate during an emergency.

Currently there are less then 5,000 implementation globally.

Thoughts?

Thanks,
Eric "Sparks"


[0]
https://travel.state.gov/content/passports/en/emergencies/natural-disast
ers/HurricaneSeason.html
[1] https://wiki.openstreetmap.org/wiki/Key:evacuation_route
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCgAGBQJZEUB0AAoJEIPRTy7KnFlsNjAH/1tdw4P27VDD7EcWomPBXfPc
2vXaJhEb+/dv2T3WK2BwuO/145Br6ZA7bF5qN2sN1UZTbnHZ3US1xeW33Kd3Lxz4
iOrIL87/aAlFCSxILC2pTstydjr53F7heYliGCQSY76K8kOQvtiprYN7n/+VEQa3
rGFmLkvIQMeXdzvYbx7vnucNtGDiUc5c6YP76mbHM7JqZp2H/hU0bQng1HlnZSa5
vF7EyMDcGTQAYpHlNk+oqHBR38olfEAH6DEfnNueNQnkhR+GcZ60MBzNxCZxG8gX
i4yKUHvDHButdrtPA/G3dhRd7Ucs0Bn6MakRhJ5pvjg12uCq7+SLzRc/9s1gQgQ=
=eTET
-END PGP SIGNATURE-

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

Re: [Tagging] Disputed area

[Eric SIBERT]

Le 26/07/2015 03:20, Arch Arch a écrit :

The main server is not for testing. Please use
http://wiki.openstreetmap.org/wiki/Sandbox_for_editing instead


<<database. If you are developing editing clients and automated edit 
scripts, this is very useful ...>>>


I did not do a complex thing.


I've removed Tromelin from Mauritius relation


Better practice is to ask the contributor to remove it itself.


as this causes rendering issues: http://i.imgur.com/TZTYlHt.png


Tagging for render?

Eric

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

Re: [Tagging] Disputed area

[Eric SIBERT]

I did some try.

* Mont-Blanc area claimed by France and Italy but occupied by nobody.
I have split the boundary into two branches (an awful job considering 
the number of administrative relations involved).


I defined an area with:
disputed_area=yes
dispute:claim:FR=yes (area claim by France)
dispute:claim:IT=yes (area claim by l'Italie)
dispute:recognized:FR=yes (dispute is recognized as such by French 
authorities)
dispute:recognized:IT=yes (dispute is recognized as such by Italian 
authorities)

dispute:wikipedia:fr=Histoire_de_la_frontière_sur_le_mont_Blanc

I added the area both to relations France and Italia (admin_level=2) 
with role dispute:recognized (each government recognize that there is an 
area within his border that is subject to dispute).



* Juan de Nova island. French island. Claim by Madagascar. French 
government don't really recognize that there is a conflict (I think this 
is the most common case of disputed area).


I added to the island perimeter which is already the French boundary:
disputed_area=yes
dispute:claim:MG=yes
dispute:recognized:FR=no
dispute:recognized:MG=yes

Added to Madagascar relation with dispute:claim role.
Not added to France relation because French government don't acknowledge 
the dispute.


* Tromelin Island. French island. Claimed by Mauritius. French 
government accepted to share fishing right with Mauritius that I 
consider as an acknowledgment of the dispute.


I added to the island perimeter which is already the French boundary:
disputed_area=yes
dispute:claim:MU=yes
dispute:recognized:FR=yes
dispute:recognized:MU=yes

Added to Mauritius relation with dispute:claim role.
Added to France relation with dispute:recognized role.


I see several drawbacks.
- looking at the disputed territories proposal 
(http://wiki.openstreetmap.org/wiki/Proposed_features/DisputedTerritories), 
I would say that my use of recognized is not well suited. Recognized 
would be better fits for foreign governments or international 
organizations (like UN) that recognized the 'de facto' situation. May be 
dispute:acknowledge:CC=* would be best suited to indicate that a 
government recognize that there is a dispute.

- there are several redundancies.
If country AA claims an area out of his 'de facto' boundaries, it is 
both marked as dispute:recognized:AA=yes and added to AA relation with 
dispute:claim role.
If country BB recognize that there is a disputed area within his 'de 
facto' boundaries it is both marked as dispute:recognized:BB=yes and 
added to BB relation with dispute:recognized role.


Indeed, all roles dispute:claim are supposed outside the country 
boundaries and all roles dispute:recognized are supposed inside the 
country boundaries. May be one role should be enough for both.


Or no role/inclusion in relation at all.

What are all the disputed areas within CC and recognized as such by CC 
government? Request all disputed_area=yes within CC relation and with 
dispute:recognized:CC=yes.


Last question : how to indicate that an area want its independence?

Eric

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

Re: [Tagging] Disputed area

[Eric Sibert]

I think a good test case for testing if this can handle ongoing and complex
conflicts would be Kashmir, as it's currently five-ways disputed between
Pakistan, India, China, a Kashmir separatist/freedom/independence movement,
and recently displaced-from-Afghanistan irregular Islamic fundamentalist
forces.


I would be cautious about not stabilized conflicts and therefore  
exclude the last group and just focus on the first four claimers. In  
the same idea, I would not try to describe the situation in East  
Ukraine.


First question : can you draw current de facto borders? The northern  
part of India/Pakistan border?


Second question : can you draw areas with uniform claims and de facto  
situation inside?


Eric



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

Re: [Tagging] Disputed area

[Eric Sibert]

Overlapping should be the first step to mapping a dispute. Then if you want
to add dispute attributes, you could create a new multipolygon with areas
in question, and add dispute specific tags, wikidata tags, and similar.


In my previous message, I proposed to create a relation for the  
disputed area but a single polygon may be enough in most cases. A  
multipolygon may be used if the same dispute deals with several areas  
(like one country claiming several islands of another country at the  
same time).


Eric




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

Re: [Tagging] bridge AND embankment

[Eric Sibert]

@Eric: I looked at more examples, and I have to admit that you are right
with your statistical (0.1%) argument. Most cases I looked at, are obvious
accidental tagging errors.


I checked for Madagascar. I found one case and I'm the author :-p
I first added embankment and later cute a small part of the road to  
add a bridge.


Eric



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

Re: [Tagging] Disputed area

[Eric Sibert]

Yes, some disputed areas are more stable and, in osm, one may focuses  
first on it.


In a lot of cases, there is "de facto" one country administrating the  
area. We should use the "de facto" aspect to draw a closed  
boundary=administrative.


Then we may add to the relation disputed areas with different roles  
whenever they are inside or outside the "de facto" boundaries.


The disputed area may be itself defined by a relation including the  
area, the boundaries claimed by each government and may be some tags  
to indicate if the disputed area is recognized as such by each  
government and/or attributed to one specific government by some  
international organization (for "de jure" aspect?).


For my initial case (Mont-Blanc between fr and it), there is no "de  
facto" occupying country. I would split the boundary into two branches  
corresponding to each government claim. Define a disputed_area  
relation with:

- each branch
- the area
- claimed by France
- claimed by Italy
- dispute acknowledged by France
- dispute acknowledged by Italy
- dispute acknowledged by European Union
Put each branch in the corresponding country relations. Add to each  
country relation a disputed_area_inside with the disputed relation.
The main drawback is that there is an overlap between France and Italy  
that may stress some tools.


Gibraltar : there is a "de facto" occupying country. I would not split  
the boundary into two branches. Define a disputed_area relation with:

- the UK branch surrounding Gibraltar
- the earth border between UK and Spain
- the area
- claimed by Spain
- dispute acknowledged by Spain
- dispute acknowledged by Uk
Maintain the earth border in the corresponding country relations.
Add to UK relation a disputed_area_inside with the disputed relation.
Add to Spain relation a disputed_area_outside with the disputed relation.

Area claimed by nobody between Egypt and Sudan?
Split the boundary into two branches according to each government.
Define a disputed_area relation with:
- the Sudan branch
- the Egypt branch
- the area
(no claim, no dispute acknowledgement).

Is such a schema suitable for the Indian/China case? Does is allow to  
draw a map like the one presented?


Eric




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

Re: [Tagging] bridge AND embankment

[Eric SIBERT]

Although I agree that such combination is suspicious...


> 250 in France

A rough evaluation for France give me 200k ways with bridge=yes. So 
about 1 error each 1000 bridges. Not such a big issue.


My 0,02 €.

Eric

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

Re: [Tagging] Disputed area

[Eric Sibert]

One thing that perhaps might want to be captured in other disputes is
what happens when one country actually occupies and controls the
disputed territory.  There, there's a de facto border and a claim.


Yes, I started with the easy case where not country is occupying the  
disputed area and both countries agree on the limits of the disputed  
area. There should be a similar case between USA and Canada for  
islands near Vancouver.


Although not so completely pacific is the case of Perejil/Tourah  
island between Spain and Morocco with status quo and no one occupying  
it.


In opposite there are a lot of claims that seems mostly theoretical  
like Spain other Gibraltar, Morocco other Ceuta and Melilla,  
Madagascar other Juan de Nova and Europa islands (both inhabited but  
controlled/administrated by France)...
Tromelin island controlled by France but with fishing rights share  
with Maurice republic that is claiming the island.


So I don't know were to put the limit on which territories should be  
tagged as disputed in OSM. May be we can start with areas recognized  
as such by booth governments and not occupies by any one :-p


There is also the case of sea/water disputes like the one recently  
solved by international tribunal between Chile and Peru.


Eric




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

[Tagging] Disputed area

[Eric SIBERT]

Hi folks,

The are many disputed areas in the world but I want to talk about a 
specific one : the Mont-Blanc area.


- Near the Mont-Blanc submit, there is a disputed area between France 
and Italia.

- Both governments agree that there is a dispute
- Both governments also decided not to solve the issue
- none of the country is really occupying the area. There is no police 
nor military forces, no building, no weather station, no flag. Rescue 
operations are operated jointly by the two countries on an area larger 
than the disputed one.

- the idea is that both countries will share sovereignty.
- so the disputed area will remain as such for a long term, not saying 
ad vitam æternam.


We would like to put this fact in OSM, as it is the view shared by both 
governments.


But we can also try to find a solution for more general cases, with 
non-pacific disputes, with one occupying country, territories wanting 
their independence...


Any suggestion?

Eric

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

Re: [Tagging] Maxspeed

[Eric Sibert]

In Italy we've been using something like

maxspeed=50; source:maxspeed=IT:urban
maxspeed=90; source:maxspeed=IT:rural


+1 in France:

maxspeed=50; source:maxspeed=FR:urban
maxspeed=90; source:maxspeed=FR:rural
maxspeed=130; source:maxspeed=FR:motorway
maxspeed=30; source:maxspeed=FR:zone30
maxspeed=20; source:maxspeed=FR:living_street

Although for the last two, speed limit is included in the  
corresponding traffic sign design.



http://wiki.openstreetmap.org/wiki/Key:source:maxspeed

Eric



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

Re: [Tagging] [Bug] calculated shortest route wrong

[Eric SIBERT]

Paul,

USENET and Mailing List posting netiquette:

4. Do not cross-post:

http://linux.sgms-centre.com/misc/netiquette.php#xpost

People on [tagging] may not be aware of the beginning of the discussion 
and other people on [osmand] may only receive a fraction of answers.


Thanks

Éric

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

Re: [Tagging] Current status of the key smoothness=*

[Eric Sibert]

(I think of the roads we drove in Kenya), so any input is welcome even if it
isn't perfect. We ran into some nasty surprises during our trip because the
road quality wasn't tagged at all.


+1.

I also widely use smoothness=* in Madagascar. Indeed, I use it to  
describe practicability of roads or tracks for 4 wheels motor  
vehicles, in somehow to answer the question: what kind of vehicle do I  
need to use this road?


Despite using it often, I still have to check the wiki time to time to  
be sure about values definition. I even more dislike tracktype=gradeN  
that is using numerical values.


Maybe, it is time to define a new key/values. We already have  
mtb:scale and sac_scale.


For instance, practicability for cars:

practicability=*

practicability=no (damaged road)
practicability=tractor_only
practicability=fourwheeldrive_only (and not 4WD_only to avoid abbreviation)
practicability=highclearance_only
practicability=normal (default value)
practicability=lowclearance

Subjectivity still remains. One may consider a road as usable with a  
high clearance car because it is used by 404 taxi-brousse when another  
one may not want to use his Porche Cayenne SUV on it.


It doesn't really describe smoothness. A road usable with normal  
vehicles may be driven at 100 km/h or 20 km/h, depending on smoothness.


One may define some side scales like:

practicability:bicycle=mountainbike_only/trekkingbike_only/citybike/all(defaut)
practicability:motorcycle=*


My 0,02 €.

Eric



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

Re: [Tagging] tagging very wide steps - highway=steps on an area?

[Eric Sibert]

I had assumed for years that the direction pointing upwards was a commonly
agreed on standard, being myself an architect I hadn't expected this to be
questionable, but as I got so much flak from people insisting on the other
way round,


Like me :-p (although not insisting).

Indeed, as a poor lonely mapper, I assumed that steps were pointing  
down like waterways.



I now am adding the tag incline=up to all steps.


+1 with incline=down but up to now, I didn't corrected my  
contributions backward.




Eric



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

Re: [Tagging] Ethnic shops

[Eric SIBERT]

I started modifying the wiki following our recent discussion.

For cuisine=*, I added:
"May also apply to other services that deliver food, like convenience."

For shop=convenience, I added (in Tags used in combination):
"Stores selling specific type of food or with ethnic origin may use 
{{tag|cuisine}} to indicate it."



And latter go on with culture=* for nonfood services?

Eric

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

Re: [Tagging] length=

[Eric SIBERT]

Le 27/01/2015 16:34, Martin Vonwald a écrit :

Ok - understood. Although I doubt, that there is real usage for that
example. But I had a quick look in overpass: besides aeroways it is
quite often used on bridges and tunnels, where the actual (official)
length can be observed. Makes sense.


Indeed, for tunnels, I just put the length indicated at the entrance in 
note=*...

... and some other contributors transfered it to length=*.

Eric


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

Re: [Tagging] Ford and other river crossing : (was : waterway=wadi problem)

[Eric SIBERT]

I wonder if there are enough of them to warrant their own bridge=*, as there 
are so many kinds of bridges. I bet we can put a ford tag on the bridge - it 
might be a simple solution.


I agree with your suggestion of using boot bridge=yes and ford=yes as it 
is usually a bridge but sometime behaves like a ford. I would avoid 
flood_prone=yes as it is made to be used when reasonably submerged. 
Adding depth=0 (or -0.5 ?) to indicate that the ford aspect is usually 
dry. (depth is not really used with bridge=* : 14 over 240).


Eric


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

[Tagging] Ford and other river crossing : (was : waterway=wadi problem)

[Eric Sibert]

My apologize for switching the discussion (so I change the title  
accordingly) and also for slowly answering.


First, I was not aware of depth=* use recommendation with ford=yes  
although it is in the wiki for years.


Let me back to Madagascar. We have:

- unpaved road crossing permanent river without specific equipment
ford=yes
surface=unpaved
depth>0

- unpaved road crossing permanent river with specific equipment  
(usually made of concrete, "radier" in French, not sure on the correct  
term in English: raft???)

ford=yes
surface=paved/concrete
depth>0

- unpaved road crossing intermittent river without specific equipment
ford=yes
surface=unpaved
depth=0
May we use intermittent=yes/seasonal/flood/winter... to indicate  
period/frequency submersion?


- unpaved road crossing intermittent river with specific equipment
ford=yes
surface=paved/concrete
depth=0
intermittent?

- paved road crossing permanent river (of course with specific equipment)
ford=yes
surface=paved/concrete
depth>0

- paved road crossing intermittent river
ford=yes
surface=paved/concrete
depth=0
intermittent?

Do we have also to use flood_prone=yes or (ford=yes / depth=0) already  
imply that it is subject to flooding?


I don't like the wiki page on flood_prone. It is telling that the main  
difference between ford and flood_prone is the danger aspect. Indeed,  
looking at illustrations, especially at the third one, I just see a  
regular ford with depth scale and so on.


I have one last case: some low profile bridge (without parapet) may be  
submerged after heavy rain but may be still usable if water depth  
above the bridge in not too high. How to tag this?




Eric



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

Re: [Tagging] Ethnic shops

[Eric SIBERT]

Le 19/01/2015 18:42, althio althio a écrit :


John Willis mailto:jo...@mac.com>> wrote:
 > I think there should be ethnic=*, Nationality=* , or culture=*tag
that can be used [...]

I find culture=* the best so far.

I find it specialised enough (compared to _type=*, origin=*, category=*,
group=* ...)
I find it accurate enough.
I find it generic enough (compared to more restrictive nationality=* and
even ethnicity=*) so that it enables tagging for ethnic group but also
other types of social group and subcultures.


like:
amenity=hairdresser
name=Scalp
culture=punk
?

but culture=* is already used. 84 uses:

kleinkunst
museum
music
roman
celtic
youth_club
theatre
art_gallery
arts_centre
...

ethnic=* is mostly used in Colombia (x1000) from an OCHA import (that I 
didn't know was compatible with OSM license) associated with 
place=hamlet, ethnic=yes and ethnic_group=*.


ethnicity=* is used with values
indian
chinese
italian
mexican
Italian
yes
asian
polish
thai
czech

Some uses are strange like restaurants in USA with cuisine=national, 
ethnicity=*.


Based on the current uses and the fact that culture may have several 
meanings, ethnicity=* seams to me the best choice with values as similar 
as possible to cuisine=*.



--
Éric

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

Re: [Tagging] waterway=wadi problem

[Eric Sibert]

althio althio  a ?crit :


On 19 January 2015 at 13:42, Eric SIBERT  wrote:

One may also not that road are also subject to intermittent (un)usability.
Some unpaved one are closed during rainy season.



something with conditional?
access:conditional  = no @ (Jan-Apr)


This is what I'm using up to now with approximative or average  
closing/opening dates. I also use it for mountain roads that are  
closed in winter due to snow. I also add seasonal=yes to indicate that  
it is weather dependent.




Some part of road have
concrete parts that are flood_prone during cyclone.

How can we (or not) extend it to roads?



access:conditional  = no @ flood


I'm using flood_prone=yes. With surface=concrete.

But I was looking for some method to unify intermittent aspects of  
rivers and roads that are related when roads are crossing river or  
vice versa.


Eric



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

Re: [Tagging] waterway=wadi problem

[Eric SIBERT]

I'm following this thread since the beginning. I'm interested in 
intermittent river for Madagascar 
(http://osm.org/go/lrsj4--?relation=447325).  There is mostly a dry 
season and a wet/rainy season from December to April. There is also 
around 3 cyclones a year.


Some rivers (or part of river) or lakes are permanent.

Some rivers are seasonal and only filled during rainy.

Some rivers, especially in the semi-arid South, are only active after 
cyclone or heavy storm.


One may also not that road are also subject to intermittent 
(un)usability. Some unpaved one are closed during rainy season. Some 
part of road have concrete parts that are flood_prone during cyclone.



> Less work if intermittent is simply used without the frequency extension

.. thus:

intermittent=yes/no/winter/spring/summer/autum/seasonal/ephemeral (default assumption of 
"no")


I like this proposal. One may extend it to lakes. How can we (or not) 
extend it to roads?


Indeed, winter/spring/summer/autum/ does not apply to Madagascar. One 
may define cold/fresh season (May-August), hot season (September, 
December) and wet/rainy season (January-April). Or on the East Cost, 
only two seasons: the wet one and the rainy one ;-)



--
Éric

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

[Tagging] Ethnic shops

[Eric Sibert]

Hi all,

I'm wandering on how to tag shops that are offering services with  
specific ethnic orientation. For instance:

- convenience specialized for Italian, Portuguese, Chinese products...
- clothes typical from one country/area
- hairdresser for African people although non African may also want to  
find it for braids

...

cuisine=* is used for restaurant and may be suitable for convenience  
but not really for clothes or hairdresser.


Any suggestion is welcome.

Eric



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

Re: [Tagging] natural=bay as nodes are evil

[Eric Kidd]

When working near the coast of Maine in the US, I  see lots of bays. In
most cases, the ultimate source data for the bay names seems to be various
government maps and databases: GNIS, ancient nautical charts, or whatever.
There's a high degree of agreement between sources: If an island has 4
unnamed coves and 1 named cove in GNIS, then I'll usually find the exact
same data on the nautical charts.

But the key point here is that none of these official sources represent
bays as polygons. GNIS uses a pointssomewhere in the bay. The nautical
charts print the name somewhere in the middle of the bay. Effectively, the
official data really is a point, plus whatever guesswork a human reader
supplies.

The rendering on openstreetmap.org is pretty good: it just prints the bay
name at the marked point, and shows it across a reasonable range of scales.
There are some weird cases with nested bays, but those are weird on the
nautical charts, too.

Merging all of these thousands of official "bay" points into the
surrounding coastal polygons sounds like an editing nightmare. And the data
wouldn't be better—the underlying official sources are all points, anyway.

2014-10-27 16:04 GMT-04:00 Ilpo Järvinen :

> On Mon, 27 Oct 2014, Martin Koppenhoefer wrote:
>
> >
> > 2014-10-27 17:37 GMT+01:00 Christoph Hormann :
> >
> >   But this is exactly what does not work with a hand mapped
> >   polygon either
> >   since the edge of the bay is not well defined.
> >
> >
> >
> > it will work in most cases, and only give questionable information when
> you
> > are close to the fuzzy end towards the open sea (or another bay). In
> these
> > cases there won't be a correct answer from a human either, because it
> simply
> > isn't clear where that border is.
>
> IMHO, the most controversial thing in this all is that the approach
> Christoph is proposing would require us to not map natural=bay but
> "natural=bay_entry" instead, and that is obviously exactly where the fuzzy
> part is. That is, a mapper would be forced to place bay nodes into the
> place where nobody can say for sure if it's in the bay or not.
>
> Otherwise his algorithm would obviously end up failing because of arbitary
> picked threshold that makes lots of assumptions about the shape of the
> bay. The main assumptions are about width of the bay and depth at the
> nearest coastline that is not in the either extreme of the bay. Consider
> e.g. a very wide bay which has two pockets but at the middle you have some
> penisula extending towards the bay entry and thus also towards the bay
> node. But it would certainly work in many cases just fine like most of
> the algorithms tend to do (of course, assuming we'd map bay_entry instead
> of bay).
>
> --
>  i.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Public lands with designated parking lots

[Eric Kidd]

I enjoy mapping nature reserves, large parks and trail systems. These
typically share a number of features:

   - They're physically adjacent to several roads, but they're only
   accessible from one or two.
   - They typically have one or more official parking areas, with
   information kiosks and trailheads.
   - They almost never have official street numbers.
   - They're often surrounded by poorly-surveyed, poorly-marked roads which
   make manual navigation hazardous.

For several illustrated examples, please see the wiki:
http://wiki.openstreetmap.org/wiki/User:Ekidd/Routing_to_public_lands_with_designated_parking_lots

In an ideal world, there would be some way to clearly indicate "This is an
official parking lot for accessing this area/POI/business/etc."

Possibilities include:

   - amenity=parking with destination=*. This seems straightforward, but
   it's rarely used.
   - A relation linking the destination with its official parking lot(s).
   More complicated, but it might handle other odd cases.
   - Some way to associate a "preferred routing point" with an area (a bit
   hacky, frankly).

Does anybody have any suggestions? Are there existing conventions? Would
any OSM-based routing software be interested in delivering people to the
correct parking lot? Are there other related use cases?

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

Re: [Tagging] pk vs kp on *=milestone and default unit?

[Eric Sibert]

Did yo had a look at the discussion of the proposed feature?

http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Milestones

I agree that for pk, by default, unit should me considered as metric,  
as for height, maxweight, maxwidth, maxheight, maxlength...


Eric




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

Re: [Tagging] Juice "restaurants"

[Eric Sibert]

I'd not choose amenity=cafe if they don't sell besides the juice  
also coffee. Look how quite specific the other tags are for places  
where you can drink, eg biergarten, pub, cafe, bar, kiosk, nightclub  
 ...


I'm wondering if the way we are coding different places where we can  
drink or eat is not too specific. May be, we should think about a more  
general model like:

amenity=drink_place/eat_place
seat=yes/no
indoor/outdoor
fast_food=yes/no
beverage
cuisine
operator
...
So renderer can easily handle a lot of cases. We can then add a tag to  
specify local cultural items:

drink_place:type=biergarten, pub, cafe, bar, kiosk...
but renderer can work without this last tag.

My 0,02 €

Eric


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

[Tagging] Feature Proposal - RFC - historic=marker

[Eric Polk]

Perhaps tagging this as "tourism=historicmarker" would be a better 
option.  Thoughts?


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

[Tagging] Feature Proposal - RFC - historic=marker

[Eric Polk]

Then we have historic=memorial und memorial:type=plate
 This is forhttp://en.wikipedia.org/wiki/Commemorative_plaque

gruß reneman


According to the OpenStreetMap Wiki, historic=memorial is for 
"remembering special persons, peoples lost their lives in the world 
wars."  A historical marker is for more than just people who lost their 
lives in a war.


A few examples:

* CASA DE GOVERNOR PÍO PICO - former residence of the last Mexican 
governor of California.

* BLACK STAR CANYON INDIAN VILLAGE SITE
* STAGECOACH INN - a historic inn
* JUANA BRIONES, PIONEER SETTLER OF YERBA BUENA

I am open to changing the definition of historic=memorial to include all 
historical markers and not just memorial to individuals.  Would that be 
a better option?

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

[Tagging] Feature Proposal - RFC - historic=marker

[Eric Polk]

> Is this identical to information=board with board_type=historic ??

They are similar in the information they present but there are 
structural differences the physical way they are presented.


Information boards are flat surfaces that either mounted in a table top 
form or vertically as a flat display.  The content of an information 
board is printed onto the material, often covered with a sheet of clear 
plastic.  The signs are held up by either pre-fabricated metal poles 
that are welded together or by a wooden framework.  This format of 
presenting information is relatively inexpensive and easy to reproduce 
if replacement is needed.


Historical markers are often made in the form of monuments of stonework, 
are set in large stones, or are placed on poles.  The marker itself is a 
metal plate that is either embossed, cast, or stamped with the text of 
the marker.  This format of presenting information is expensive to 
initially produce and replace if damaged due to the more permanent 
nature of the materials used.


The agency that creates the content is also different between the two.

Information boards are created by a wide range of agencies, companies, 
or organizations.  No formal list is kept of the information boards and 
there is no formal set of criteria for what makes the site valid for 
recognition.


By contrast, historical markers are usually placed by governmental 
agencies that have a set of criteria that they use to determine the 
historic importance and relevance of a site before authorizing a 
marker.  Official lists are kept of the sites and new additions must be 
submitted for review.


There are a few exceptions to the governmental role in the placement of 
some historical markers.  There are a number of organizations that do 
place historical markers, sometimes in cooperation with government 
agencies, and other times independently.  Examples are the Native Sons 
and Daughters of the Golden West and the Daughters of the American 
Revolution.  These organizations often have historical preservation as 
one of their goals and do have standards for what qualifies as a 
historic marker site.


My overall reason for not tagging historic markers as information boards 
is that the are physically similar to monuments and memorials.


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

[Tagging] Feature Proposal - RFC - historic=marker

[Eric Polk]

I am reactivating the abandoned historic=marker proposal.



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

Re: [Tagging] piste:type=nordic but without underlying track

[Eric Sibert]

Hi,

I'm also using piste:type=nordic alone not only in field but also on  
track/road because a lot of things are different between piste and  
road. Physically, the piste is over the road but don't use his  
surface. Road is open in summer, piste in winter. Piste could be  
oneway and not the road...


You can see what I did there : http://osm.org/go/0CC~gQzS

Eric



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

Re: [Tagging] Money transfer agents

[Eric SIBERT]

Le 19/11/2012 15:58, Janko Mihelić a écrit :

Maybe something even wider like:

service:money:transfer=yes
service:money:exchange=yes (because you can exchange currencies in some
banks too, not only exchange bureaus)
service:money:withdraw=yes
service:money:deposit_coins=yes


I like it.

So service:money:transfer:operator="Western Union" ?

Quite long...

Éric

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

Re: [Tagging] Money transfer agents

[Eric SIBERT]

There's a proposal in the  wiki that money transfer agents such as
Western Union should be tagged as amenity=money_transfer.
I don't like this tag because of the over use of amenity key.


+1.


Many of the money transfer agents are banks or bureau de change, which
are amenities.


Yes, in France, they are always part of an other shop/bank...

In Madagascar, they are not only part of some banks put they also have 
stand alone offices.


Eric

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

Re: [Tagging] Feature Proposal - RFC - Obstacle

[Eric SIBERT]

About the values existing
[...] For example, in my proposal there are a
comment about obstacle=bridge (69,57% values of obstacle now), that can
see here


I'm surprise by the large use of obstacle=bridge. Do we have any idea on 
how it is used now?


Éric

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

Re: [Tagging] designation=* is a mess in Germany

[Eric Sibert]

Hi,

In France, we have a strong misuse of this tag. Some people are using  
it instead of name=*. Maybe due to a lack of translation in Potlatch  
because "désignation" in French is a synonym of name. It is also used  
instead of note=*.


For instance :

building = school
name = Maison de la Petite Enfance
designation = Crèche

indeed, amenity=kindergarten.

osmose [1] show a warning for designation use.

Eric

[1] : http://osmose.openstreetmap.fr/map/


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

Re: [Tagging] How to tag: road in Luxembourgish park with unclear status

[Eric SIBERT]

Road classification... such a difficult subject in many countries.

For the part that inhabitants can use, highway=residential and 
access=destination.


After, for me, the road is large enough for a car but motor vehicles are 
prohibited -> highway = pedestrian. Don't care about park maintenance.


until picture 9.

At this point, a car can't use it.

highway=footway : a intentionally organized way for pedestrians. 
(opposite to highway=path for way that appears after repeated use by 
pedestrians but not intentionally made for).


In booth cases (pedestrian and footway), bicycle status is not clear by 
default. Clear indication is welcome : bicycle = yes (assuming that the 
way is mostly designed for pedestrian).


Photo11 : I never now if it is mostly designed for bicycle 
(highway=cycleway) or for pedestrians (highway=footway).


segregated=no to indicate mixing of both type of users.

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

Eric

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

Re: [Tagging] Emergency lane used by PSV at rush time

[Eric Sibert]

"Other lanes such as Wikipedia spitsstrooken in the Netherlands or
Wikipedia temporäre Standstreifen in Austria, Germany and Switzerland
which are available to GENERAL traffic (I.E. NOT LIMITED TO A SPECIFIC
KIND OF VEHICLES) at certain restricted times, for example during the
rush hour. "

To prevent contradicting statements I want to add at the end of the
aforementioned text the following: "This also applies to lanes which
are usually excluded, e.g. emergency shoulder lanes."


I don't find the last sentence very clear. "This" refers to what?

Eric


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

Re: [Tagging] Emergency lane used by PSV at rush time

[Eric SIBERT]

Sorry for late answer. There is so much traffic related to lanes on this 
mailing list.



I suggest the following rewording which should reflect the initial intention:
"Other lanes such as Wikipedia spitsstrooken in the Netherlands or
Wikipedia temporäre Standstreifen in Austria, Germany and Switzerland
which are available to GENERAL traffic (I.E. NOT LIMITED TO A SPECIFIC
KIND OF VEHICLES) at certain restricted times, for example during the
rush hour. "


+1.

Éric

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

Re: [Tagging] Emergency lane used by PSV at rush time

[Eric SIBERT]

For practical tagging I think it is too theoretical for most mappers to
understand the difference.

[...]

In somehow, having a not to complicated model or at least a two levels 
model a first simple model could be better.


Back to my initial problem

lanes=2

lanes:condtional = 3 @ traffic_jam
lanes:psv:conditional = 1 @ traffic_jam

Basic data users just need to understand the first key. More advanced 
one may use the two last.


lanes=* wiki would need to be modified to not count temporary lanes. It 
would be more consistent as most of the time only two lanes are available.


Eric

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

[Tagging] Emergency lane used by PSV at rush time

[Eric SIBERT]

Hi,

I'm translating the lanes=* wiki page into French. And some cases are 
coming into my mind :-p


On a motorway, the emergency lane can be used by psv (bus and taxi) when 
there is traffic jam on the usual lanes. There is no predefined hours. 
Just, when traffic jam is detected, light signal are switched to 
indicate it.


So, how would you tag this considering lanes=* definition and new 
"Conditional restrictions"?


Default is
lanes=2
oneway=yes

but considering that lanes=* should include lanes that are available to 
traffic at certain restricted times, it should be lanes=3


lanes:psv:conditional= 1 @ rush_time

but this will suggest that all 3 lanes are available for all vehicles 
out of rush time.


Some other suggestions?


--
Éric

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

Re: [Tagging] Narrow Bridge

[Eric SIBERT]

The standard English term for a bridge that is only wide enough for one vehicle to pass through at 
a time is a "one-lane bridge".  In the same way, a roadway only wide enough for one 
vehicle at a time is a "one-lane road".  The bridge or road is visibly only one lane 
wide; painting lane markings on it to point out its narrowness would be redundant.



Back to my initial case in Madagascar. I'm first talking about major 
roads where two vehicles (incl. trucks) can cross without lowering there 
speeds. Although there is not central line (except in curves), there is 
virtually two lanes.


I understand that there is some redundancy between lanes=* and width=*, 
especially for for roads without painted lanes. But I like lanes=* for a 
rough description of the gauge.


About the bridge, there is usually a road sign announcing the narrowing:
http://www.aua-signaletique.com/retrecissement,fr,4,4728.cfm
It may be completed with a stop a each end of the narrow passage and 
sometime with a bump. Without bump, you may cross the bridge at full 
speed if no other vehicle is arriving in front. Otherwise, first 
engaged, first served ;-) So lanes=1 corresponds to the bridge, although 
width=* would be better but hard to determine.



Éric

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

Re: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»

[Eric SIBERT]

you could use lanes=1 on the narrow parts.


Agree.



- a bridge or a raft with a bad link to the road/track i.e. a step at each
end of the bridge/raft. obstacle=unevenness ? or obstacle=step? For me
unevenness is to soft for what you describe.



split the way and put a short highway=steps, step_count=1


No. It would indicate that it can't be used by vehicles.


- a road on a dam or a bridge have been damaged : a bailey bridge
(http://en.wikipedia.org/wiki/Bailey_bridge) have been temporary (for ten
years ;-) ) added on it.



is this an obstacle, or is it simply another type of bridge
construction? If it is an obstacle the tagging should line out in what
the obstacle consists (smoothness, width, maxweight, ...)


It's first a lanes=1 and second short connecting slopes at each end. 
Something no so far from the steps I mentioned earlier i.e. you have to 
slow down at entrance and exit of the bridge.


Éric

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

[Tagging] Narrow Bridge (was: Reconstructing «Dificult passability» proposal to «Obstacle»)

[Eric SIBERT]

- a narrow bridge i.e. you can't cross a vehicle in opposite
direction. We may use width=* but it is difficult to get it
precisely. obstacle=narrowness


It's slightly offtopic, but wouldn't it be logical to use "car" as a non
accurate unit of length? So you can have a tag like "width=1car" or
"width=1.5car".



I like it :-)

In Europe, I found :
"1 car" used 2 times
"wide enough for a car" used 1 time

Not wildly used.

Indeed, as pointed out by Martin, I have to use lanes=1. I had a 
misunderstanding with the lanes=* key. I thought lanes=* indicated the 
number of lanes in each direction, not the total number in both 
directions. The French wiki lanes=* page need a strong update, compared 
to the English one (todo list...).


So, I will go on with lanes=1.

Éric

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

Re: [Tagging] Reconstructing «Dificult passability» proposal to «Obstacle»

[Eric Sibert]

Hi,

During my last travel in Africa, I was thinking on how to map  
obstacles on road. So I support your proposal but in a generalized  
way, not only for pedestrian or bicycle. And I take the opportunity to  
review what I observed:
- a narrow bridge i.e. you can't cross a vehicle in opposite  
direction. We may use width=* but it is difficult to get it precisely.  
obstacle=narrowness
- a bridge or a raft with a bad link to the road/track i.e. a step at  
each end of the bridge/raft. obstacle=unevenness ? or obstacle=step?  
For me unevenness is to soft for what you describe.

- a hole in the road.
  * A small hole you can drive other at full speed but that may  
surprise you when driving during night.
  * A medium hole where you have to use the other side of the road at  
full speed if nobody is arriving in front

  * A big hole where you have to slow down and drive inside.
(For full uneven sections, I use smoothness=*).
- a road on a dam or a bridge have been damaged : a bailey bridge  
(http://en.wikipedia.org/wiki/Bailey_bridge) have been temporary (for  
ten years ;-) ) added on it.


I would no use obstacle for thinks that are deliberate and/or in their  
initial state.


For river and water. If there is water year around (or large fraction  
of the year) : ford=yes. Only flooded few days a year (after heavy  
rain), flood_prone=yes. Use surface=* to indicate whenever you are  
just driving in the river or if there is some raft build. Seasonal?  
Use seasonal=yes in conjunction with access:conditional=* to indicate  
approximative closing period (discussed recently on this mailing list.  
I will update the wiki according soon...).


Same with traffic_calming, check points...

HOT is also dealing with obstacle :

http://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Model#Obstacle

Eric



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

Re: [Tagging] Seasonnal roads

[Eric Sibert]

I'm looking how to tag a road with seasonal opening or closing. ...




Have you tried: http://wiki.openstreetmap.org/wiki/Conditional_restrictions


May I improve the wiki on seasonal=* to indicate that it would be nice  
to use it in conjunction with Conditional_restrictions?


Regards

Eric



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

Re: [Tagging] Seasonnal roads

[Eric Sibert]

For mountain pass in Alps, this could be just

access:conditional = no @ Nov-Apr




That seems logical to me. One word on using "access:conditional" though -
this would indicate no access, including on foot.


In somehow, we may consider that the road does not exist in winter due  
to the large amount of snow over it. I mostly use it during ski touring.



For more details see [1]
and [2]. Essentially there is a hierarchy of subcategories for
transportation modes.
[2] http://wiki.openstreetmap.org/wiki/File:Access_hierarchy_simple.png


This scheme should be more wildly used. It seems to be use only in the  
German wiki.



Eric



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

Re: [Tagging] Seasonnal roads

[Eric SIBERT]

One of the main mountain highways here is closed to licensed vehicles
during the winter months, but snowmobiles are permitted.  Would
vehicle:conditional apply to snowmobiles?


I also have a similar problem with road that are use in winter for 
nordic (or not) ski. Up to now, I added a second way for winter 
activities on top the way for the summer road.


Éric

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

Re: [Tagging] Seasonnal roads

[Eric SIBERT]

 >I'm looking how to tag a road with seasonal opening or closing. ...
 >Up to now, I was using "opening_hours=*" with "Nov-Apr off".

Have you tried: http://wiki.openstreetmap.org/wiki/Conditional_restrictions


I had a look some time ago but without thinking at seasonal roads.

> Work is under way to help make the page clearer,

+1


[...] but essentially your tag would be:

* vehicle:conditional = no @ Nov-Apr


For mountain pass in Alps, this could be just

access:conditional = no @ Nov-Apr

For African tracks, something like

smoothness:conditional = horrible @ May-Oct
smoothness:conditional = very_horrible @ Nov-Apr

or

smoothness = horrible
smoothness:conditional = very_horrible @ Nov-Apr


All with seasonal=yes to indicate the random aspect of the time condition.

Do you agree?


Éric

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

[Tagging] Seasonnal roads

[Eric SIBERT]

Hi,

I'm looking how to tag a road with seasonal opening or closing. Typical, 
mountain pass are closed in winter due to snow. Usual opening and 
closing dates are published (like open from week 24 to 41). In opposite, 
some roads on ice are only opened in winter. In Africa, some unpaved 
roads are usually closed during rainy season. Up to now, I was using 
"opening_hours=*" with "Nov-Apr off". But I was looking for something 
more generic that can indicate the random aspect.


I saw the proposal seasonal=* :
http://wiki.openstreetmap.org/wiki/Key:seasonal

Use in Europe : yes (497), no (19), winter (12), summer (9), * (2), 
Spring, Summer, Fall (1), Yes (1)


Use in Africa : year_round (171), yes (75), wet_season (32), 
cannot_determine (27), another_pattern (16), dry_season (7), na_dn (1), 
dry_weather (1)


seasonal=* does not indicate typical opening period.

Any suggestion?

Éric

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

[Tagging] communal learning spaces / training areas

[Eric Brelsford]

In New York, we have a host of organizations that hold classes but are not
schools of the kindergarten/primary/college framework. Some of these
organizations are free or allow bartering in exchange for education. Most
don't have full-time teachers. Unsurprisingly, a lot of these are nomadic,
but some do have or are working on finding permanent spaces.

Here are a few examples:

http://brooklynbrainery.com/
http://thecommonsbrooklyn.org/
http://nyc.thepublicschool.org/


Similarly, I've been looking at features in Kibera, and there are places
where people are trained in, say, healthcare, but in a less formal format
than a school or college.

For all of these spaces, the classes are short-term and informal. Part of me
wants to tag them as informal training spaces (to avoid overloading
amenity=school), but I'm not too keen on bloating amenity=*, either, by
adding something like amenity=informal_training or amenity=informal_school.

I've also considered amenity=community_centre (too generic), and
amenity=social_facility (focuses on aid for the poor and drug-addicted, but
might adapt to this).

Does anyone have experience tagging such places? If not, any suggestions?

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

Re: [Tagging] name:English, name:Español and l eisure:pitch & pitch:? or sport:?

[Eric Jarvies]

On Sep 21, 2010, at 8:28 AM, David Paleino wrote:

> On Tue, 21 Sep 2010 06:32:30 -0600, Eric Jarvies wrote:
> 
>> Is this how to tag them?;
>> name:English Name
>> name:es:Español
>> 
>> Or do I need to do this:
>> name:English Name
>> name:es
>> es:Español
> 
> name=Name in English
> name:es=Nombre en Español

Thanks David... was not certain about the colon in the tag name... so it's ok 
to use "name:es" as a key name?

Eric


> 
> 
> David
> 
> -- 
> . ''`.   Debian developer | http://wiki.debian.org/DavidPaleino
> : :'  : Linuxer #334216 --|-- http://www.hanskalabs.net/
> `. `'`  GPG: 1392B174 | http://deb.li/dapal
>   `-   2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging

Eric Jarvies
e...@csl.com.mx

CONFIDENTIALITY NOTICE: The information contained in this e-mail is privileged, 
confidential, proprietary and is intended only for the use of the individual or 
entity named above.  Any contained or attached works in/of this email bearing a 
Copyright notice should not be duplicated or transmitted to any other party 
without the express written consent of Eric Jarvies, or unless indicated in any 
such terms or conditions as may be referenced in said works respective 
license(s).

If you are not the intended recipient, and have received this email in error, 
or from someone without permission to redistribute, you are notified that any 
disclosure, copying, distribution, electronic storage or use of this 
communication is prohibited. If you received this communication in error, 
please notify me immediately by e-mail, attaching the original message, and 
subsequently deleting the original message from your computer and any network 
to which your computer is connected.  

Thank you, and sorry for any inconvenience this may have caused.


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

Re: [Tagging] name:English, name:Español and l eisure:pitch & pitch:? or sport:?

[Eric Jarvies]

Hello,

I would like to start adding the spanish names to the points/ways I enter, but 
need further clarification as to the correct way.

Is this how to tag them?;
name:English Name
name:es:Español

Or do I need to do this:
name:English Name
name:es
es:Español

Another question regarding pitch, which of these apply?:
9pin
10pin
american_football
archery, athletics
baseball, basketball
beachvolleyball
bmx
boules
bowls
canoe
chess
climbing
cricket
cricket_nets
croquet
cycling
diving
dog_racing
equestrian
golf
gymnastics
hockey
horseshoes
horse_racing
ice_stock
motor, multi
orienteering
paddle_tennis
paragliding
pelota
racquet
rowing
shooting
skating
skateboard
skiing
soccer
swimming
table_tennis
team_handball
tennis
toboggan
volleyball
water_ski

And which is the correct one:

Is it?:
leisure:pitch
pitch:baseball

or is it?:
leisure:pitch
sport:baseball

Thank you,

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

Re: [Tagging] landuse=single family houses/apartments

[Eric Jarvies]

or dwelling_type


On Sep 8, 2010, at 5:34 AM, Alan Mintz wrote:

> I wrote:
> >...
> >type=site
> >+ site=housing
> >+ housing={house|apartment|condominium|mobile_home|public_housing}
>   ^^^
> This should be "housing_type", not "housing".
> 
> --
> Alan Mintz 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] [OSM-talk] Feature Proposal - Voting - Craft

[Eric Jarvies]

interesting...
On Sep 8, 2010, at 1:56 AM, M∡rtin Koppenhoefer wrote:

> 2010/9/8 Eric Jarvies :
>> I've never seen a locksmith shoe repair store either :-)
> 
> 
> there is a big franchise in Germany who offers exactly this:
> http://www.misterminit.de/
> 
> cheers,
> Martin
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] landuse=single family houses/apartments

[Eric Jarvies]

On Sep 7, 2010, at 10:17 PM, John F. Eldredge wrote:

> The problem with mixing ownership terms with building structure terms is that 
> you can't generally distinguish ownership by appearance, short of there being 
> signs stating the fact, or making inquiries.  I have heard of cases where 
> some units in a multi-household structure would be owned by the residents, 
> while other units would be available for lease, or even rented out 
> month-by-month.
Ok, makes sense.  So it's best to classify them as housing:condominium ?  And 
what about the 'shanty' value?  In my state, or more specifically, in my 
municipality, we have ~100,000 titled(legally) properties, and about ~120,000 
divided properties(squatters, ejido, etc.).  Of these, about 30,000 have 
'shanty' type dwellings.  Most Mexicans do not finance their 
properties/homes/home construction... which means they spend years building 
them, using their wages/earnings from each paycheck, advancing little by 
little.  New lower class neighborhoods that spring-up as a result of economy 
stimulation(driven in my area by tourism), usually takes about 4-5 years for 
those (mostly) immigrants to make the move from their shanty dwelling, to 
constructing a permanent cement/rebar dwelling, but this usually takes up to 
five years before they've finished(the obra negra/structural work including 
floors, walls, and roof).  So should these 'shanty' homes be tagged as a 
'house' just the same?  And if so, then what is the current common convention 
for classifying construction types?

Eric Jarvies


> 
> ---Original Email---
> Subject :Re: [Tagging] landuse=single family houses/apartments
> From  :mailto:e...@csl.com.mx
> Date  :Tue Sep 07 23:03:41 America/Chicago 2010
> 
> 
> housing:house/apartment/condominium/mobile_home/public_housing/shanty/fractional/timeshare
> 
> here in mexico, many properties have 'shanty' structures that are permanent, 
> albeit cheap/easily dismantled, they are permanent dwellings none the less.
> 
> fractionals are usually in ,multi-level/unit structures, but also come in the 
> form of free standing/singular structures, and timeshare are usually within a 
> resort/hotel, and are not commonly referred to as being condominiums per say, 
> but rather, as either timeshares or fractionals, and often times as suites or 
> villas(here in mexico).  mexico has a high percentage of these type of 
> dwellings... how do you think the best way to tag them is?
> 
> fractional:1/16, 1/8, 1/4, 1/2 3/4(ownership percentage)
> timeshare:1/2/3/4/5/6/7/8/9/10(weeks)
> 
> Eric Jarvies
> 
> On Sep 7, 2010, at 9:28 PM, John F. Eldredge wrote:
> 
>> Other arrangements are common as well, such as duplexes (buildings holding 
>> two households); the same property owner owns both halves of the building, 
>> and the land underneath both; he or she may live in one half and rent out 
>> the other half, or may rent out both halves.
>> 
>> ---Original Email---
>> Subject :Re: [Tagging] landuse=single family houses/apartments
>> From  :mailto:alan_mintz+...@earthlink.net
>> Date  :Tue Sep 07 22:07:45 America/Chicago 2010
>> 
>> 
>> At 2010-09-07 17:51, =?UTF-8?Q?M=E2=88=A1rtin_Koppenhoefer?= wrote:
>>> 2010/9/8 Alan Mintz :
>>>> At 2010-09-04 09:12, Erik Johansson wrote:
>>> 
>>>> I've taken a slightly different approach. I use landuse=residential to
>>>> outline the entire related area. I then add that way to a relation with
>>>> role=boundary. I add the various buildings, roads leading to and within,
>>>> swimming pools, tennis courts, etc. to the relation. On the relation
>>> itself,
>>>> I tag:
>>>> 
>>>> type=site
>>>> + site=housing
>>>> + housing={house|apartment|condominium|mobile_home|public_housing}
>>> 
>>> 
>>> that's fine, but adding simply the tag
>>> housing={house|apartment|condominium|mobile_home|public_housing}
>>> to the landuse=residential polygon would have a similar effect.
>> 
>> True - I wanted to be complete about it, though, so I described how I was
>> doing it, since at the time I started (a year or two ago), there was no
>> coverage of the subject in the wiki at all.
>> 
>> 
>>>> : house is a single-family detached dwelling where the owner owns the land
>>>> and the buildings on it
>>>> : apartment is a multi-family dwelling where the tenants pay rent to the
>>>> owner of the buildings and land
>>>> : condominium is where the tenant "owns" the building (or part of one, as
>>>>

Re: [Tagging] [OSM-talk] Feature Proposal - Voting - Craft

[Eric Jarvies]

I've never seen a locksmith shoe repair store either :-)

On Sep 7, 2010, at 10:06 PM, John Smith wrote:

> On 8 September 2010 12:15, John F. Eldredge  wrote:
>> Locksmiths who repair shoes?  I hadn't heard of that combination before.  
>> Wouldn't that be tagged separately as a locksmith and a shoe repair shop, 
>> instead of simply tagging it as a locksmith?
> 
> They also sell key chains and some do binoculars and rifle scopes...
> *shrug* it's pretty common here...
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
> 


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

Re: [Tagging] landuse=single family houses/apartments

[Eric Jarvies]

housing:house/apartment/condominium/mobile_home/public_housing/shanty/fractional/timeshare

here in mexico, many properties have 'shanty' structures that are permanent, 
albeit cheap/easily dismantled, they are permanent dwellings none the less.

fractionals are usually in ,multi-level/unit structures, but also come in the 
form of free standing/singular structures, and timeshare are usually within a 
resort/hotel, and are not commonly referred to as being condominiums per say, 
but rather, as either timeshares or fractionals, and often times as suites or 
villas(here in mexico).  mexico has a high percentage of these type of 
dwellings... how do you think the best way to tag them is?

fractional:1/16, 1/8, 1/4, 1/2 3/4(ownership percentage)
timeshare:1/2/3/4/5/6/7/8/9/10(weeks)

Eric Jarvies

On Sep 7, 2010, at 9:28 PM, John F. Eldredge wrote:

> Other arrangements are common as well, such as duplexes (buildings holding 
> two households); the same property owner owns both halves of the building, 
> and the land underneath both; he or she may live in one half and rent out the 
> other half, or may rent out both halves.
> 
> ---Original Email---
> Subject :Re: [Tagging] landuse=single family houses/apartments
> From  :mailto:alan_mintz+...@earthlink.net
> Date  :Tue Sep 07 22:07:45 America/Chicago 2010
> 
> 
> At 2010-09-07 17:51, =?UTF-8?Q?M=E2=88=A1rtin_Koppenhoefer?= wrote:
>> 2010/9/8 Alan Mintz :
>>> At 2010-09-04 09:12, Erik Johansson wrote:
>> 
>>> I've taken a slightly different approach. I use landuse=residential to
>>> outline the entire related area. I then add that way to a relation with
>>> role=boundary. I add the various buildings, roads leading to and within,
>>> swimming pools, tennis courts, etc. to the relation. On the relation
>> itself,
>>> I tag:
>>> 
>>> type=site
>>> + site=housing
>>> + housing={house|apartment|condominium|mobile_home|public_housing}
>> 
>> 
>> that's fine, but adding simply the tag
>> housing={house|apartment|condominium|mobile_home|public_housing}
>> to the landuse=residential polygon would have a similar effect.
> 
> True - I wanted to be complete about it, though, so I described how I was
> doing it, since at the time I started (a year or two ago), there was no
> coverage of the subject in the wiki at all.
> 
> 
>>> : house is a single-family detached dwelling where the owner owns the land
>>> and the buildings on it
>>> : apartment is a multi-family dwelling where the tenants pay rent to the
>>> owner of the buildings and land
>>> : condominium is where the tenant "owns" the building (or part of one, as
>>> they are often attached like apartments), but not the land, and pays
>>> proportional rent and maintenance fees for the land and common areas.
>>> : mobile_home is similar to condominium, but using pre-fabricated housing
>>> instead of permanent structures
>>> : public_housing is generally apartments (though occasionally houses) that
>>> are owned by a government agency and occupied by low-income/disabled
>>> tenants.
>> 
>> Your system is a mixture of typology and ownership.
> 
> Intentionally. Sometimes, I don't believe it's necessary to completely
> dissect all of the possible features from every different angle -
> particularly when many of those features may not be discernable from a
> quick survey in person or by records. AFAIK, in the US, these are the types
> of housing available when one goes to look for a place to live - this is
> the way that they are commonly categorized by people both in the real
> estate business and not.
> 
> 
>> The owner situation might be quite dependent on cultur (even locally,
>> i.e. differing from one city to another). In Berlin for instance there
>> are traditionally many people in rented apartments, but you will also
>> quite often find mixed situations: owners and leasers door to door in
>> the same building.
> 
> This can happen in condominiums here, too. You can sometimes get approval
> to rent out your condo. I don't think it's likely to be something you can
> see from a survey, though. It's still going to look like a condo, and be
> one in most respects. I wasn't attempting to be completely rigorous in the
> descriptions - just to try to describe what the thing is for those that do
> not know.
> 
> 
>> There are also people that rent a detached house.
> 
> Sure. It's still a house, though. It's still owned by the person that owns
> the land, and that is not the government. Perhaps my descriptions should be
> broadened to exc

Re: [Tagging] Non Proposed Features

[Eric Jarvies]

Perhaps all contributors should be required to vote one way or the other.  It 
should not be an option, and failure to do so after agreeing to such, should 
have penalty/consequence(like OSMF having right to then convert it to ODbL).

Eric Jarvies


On Aug 28, 2010, at 11:59 PM, John Smith wrote:

> 2010/8/28 Matthias Meißer :
>> You write in the wiki that it is unable to repair it and spot on a working
>> group.
> 
> Just so we're clear, I mean the current prescribed method of requiring
> people to vote on proposals is broken, there is thousands of
> contributors and most proposals don't get more than a dozen votes if
> they are lucky, this doesn't seem to be working to me no.
> 
>> I think this will be a nice idea even if it might result in a discussion if
>> this centralisation might gain to much power even if they are only janitors.
> 
> Also I didn't come up with the idea of a working group or a committee
> to evaluate proposals, but others are completely against this idea as
> well, however the current suggestion of a do-ocracy seems doomed to
> end in endless/pointless disputes as well, take a look at the most
> recent pointless thread over culverts.
> 
> On the surface this seems a complete waste of time to spend hours
> argumenting over something so simple, concrete or similar pipes in the
> ground or under road ways that carry water, yet it went on for days
> because of slight differences of opinion, and because there is no form
> of mediation in place there was no end result (that I saw) and now
> there is going to be 2 groups of thought that go off and do their own
> thing and be incompatible with each other, how is that actually useful
> at all?
> 
> From what I'm told this issue isn't unique to OSM, many different
> government/professional bodies have been having similar debates for
> decades.
> 
>> Should this group be part of the foundation? What tools will they need? Can
>> we modify the wiki to be a nicer tool?
> 
> The wiki should at most be used to document decisions or outcomes or
> usages, it is a very poor way to discuss things, although the mailing
> list isn't always useful either.
> 
> While face to face meetings might sort things out with professional
> bodies, that isn't practical for volunteers to keep funding out of
> their own pockets.
> 
> Teleconferences usually won't help either, languages and even just
> accents can complicate matters and that's before you even start
> dealing with time zones.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/tagging
> 


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