Re: [Tagging] Animal trails

2020-11-30 Thread Tod Fitch
Maybe animal_path=yes|cow|deer|...

Where the values cover the various animals that create paths visible on imagery.

--
Sent from my phone, please forgive my brevity.

> On Monday, Nov 30, 2020 at 1:15 PM, Graeme Fitzpatrick  (mailto:graemefi...@gmail.com)> wrote:
>
>
>
> On Tue, 1 Dec 2020 at 06:54, Yves via Tagging  (mailto:tagging@openstreetmap.org)> wrote:
> > Creating a new tag for this is not a bad idea.
>
> Not a bad idea at all, even if just to stop them being marked as paths, but 
> what would you tag them as?
>
> Footpaths etc are currently tagged as highway=xxx, which really isn't 
> appropriate for an animal track!
>
> New tag animal=track / trail / path?
>
> &, as in most things OSM, it's been discussed before, apparently with no 
> resolution?
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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


Re: [Tagging] Power line going underground

2020-11-09 Thread Tod Fitch
I’ve added those tags. JOSM still complains but if it fits the power line 
schema better I guess having some editor warnings is okay.

Thank you!

> On Nov 9, 2020, at 11:25 AM, Hidde Wieringa  wrote:
> 
> Hello,
> 
> You could use "line_management=transition" (and according to the wiki also 
> "location:transition=yes"). See for more examples the wiki 
> https://wiki.openstreetmap.org/wiki/Tag%3Aline_management%3Dtransition with 
> similar entries as the photo you posted.
> 
> Whether this suppresses the warning in JOSM, I do not know.
> 
> Kind regards,
> Hidde
> 
> 
> 
> On 09-11-2020 18:40, Tod Fitch wrote:
>> There are a number of places where an above ground power line transitions to 
>> below ground. I am not equipped to guess where the line runs once it goes 
>> below ground so I stop mapping at the last power pole.  However the 
>> validation in JOSM flags this with a warning and I hate warnings on my 
>> edits. Is there some tag to put on the last power pole to indicate this is 
>> not an issue? I don’t see tagging for this situation described in the wiki.
>> 
>> See
>> https://cloud.fitchfamily.org/index.php/s/k23qn2ERyqo4a3w
>>  for an example of this.
>> 
>> Thanks!
>> 
>> 
>> 
>> 
>> 
>> ___
>> Tagging mailing list
>> 
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Power line going underground

2020-11-09 Thread Tod Fitch
There are a number of places where an above ground power line transitions to 
below ground. I am not equipped to guess where the line runs once it goes below 
ground so I stop mapping at the last power pole.  However the validation in 
JOSM flags this with a warning and I hate warnings on my edits. Is there some 
tag to put on the last power pole to indicate this is not an issue? I don’t see 
tagging for this situation described in the wiki.

See https://cloud.fitchfamily.org/index.php/s/k23qn2ERyqo4a3w for an example of 
this.

Thanks!




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging from fire_service_areas - landuse:emergency

2020-10-28 Thread Tod Fitch
Sounds line what are signed as “fire lanes” in the United States.

--
Sent from my phone, please forgive my brevity.

> On Tuesday, Oct 27, 2020 at 6:59 PM, Graeme Fitzpatrick 
> mailto:graemefi...@gmail.com)> wrote:
>
>
> On Wed, 28 Oct 2020 at 09:43, Supaplex  (mailto:supap...@riseup.net)> wrote:
> >
> > We (or Christian) are talking about areas that must be kept free, 
> > especially near buildings, so that fire brigade vehicles can stand and work 
> > there in case of an emergency.
> >
> >
>
>
> Thanks, Supa - it's not a concept that I've ever heard of in Australia! Our 
> firies just park in the street as needed!
> >
> > I think tagging of these areas is very useful for use by rescue services,
> >
> >
>
> Yes, probably would be.
>
> >
> >
> >
> >
> > How about "emergency = rescue_area" (very rarely in use)? I agree that 
> > landuse should not be used in this case, but we have "emergency" for this.
> >
> >
>
> As I say, I've never looked at it, but would emergency=clear_area work?
>
>
> Thanks
>
> Graeme
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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


Re: [Tagging] automated edits seem to remove crossing=zebra drastically

2020-09-17 Thread Tod Fitch

> On Sep 17, 2020, at 9:30 AM, Matthew Woehlke  wrote:
> 
> On 17/09/2020 10.07, Shawn K. Quinn wrote:
>> On 9/17/20 08:15, Matthew Woehlke wrote:
>>> It's also atrocious because it can *only* be verified by survey. As
>>> much as we prefer surveys, the reality is that a lot of mapping
>>> happens just from aerials, where crossings (both marked and, in some
>>> cases, unmarked) can be seen, but signals cannot.
>> I have mapped many traffic signals (and, for that matter, stop and yield
>> signs) based on shadows visible on the satellite photos. If you look
>> carefully enough (Bing and Mapbox Satellite at least), they are there.
>> (Local knowledge helps too in some cases.)
> 
> *Traffic* lights I can buy. I am more suspicious of the claim that you can 
> tell whether they have pedestrian crossing signals or not, or that you can 
> reliably identify other signage based solely on outline. *Maybe* if you get 
> lucky and have a very clear shadow at the right angle, but if you try to tell 
> me you can identify https://www.openstreetmap.org/node/7695704414 (n.b. a 
> yield sign) from a shadow in aerial imagery, I am going to be deeply 
> suspicious ;-).
> 

Not from the signs or shadows of the signs, but in my area the pavement 
markings can often tell you if it is a stop or yield. Some times it is easy 
(“STOP” or “YIELD” painted on the pavement). But it seems that newer road work 
uses a different style limit line for a stop versus yield.

Back to the original topic: I am not really sure what, if any, the US version 
of a “zebra" crossing is versus a “marked” crossing. So I usually just tag as 
“marked” as that seems to be the more generic item.

The crossing you linked to *might* be an example of a US “zebra” crossing. Can 
anyone verify that for me. Also, there are no tags on the intersection node 
itself. Should there be? I have assumed that there should so that vehicle based 
navigation would have the information needed to advise the driver of particular 
type of crossing ahead.

Cheers!



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] We should stop using hyphens to denote address ranges

2020-08-18 Thread Tod Fitch

> On Aug 18, 2020, at 2:29 PM, Colin Smale  wrote:
> 
> 
> Maybe we should use a different character to indicate a range, such as a 
> slash?
> 

In the United States it is not too uncommon for infill housing in urban areas 
to have fractional street numbers. So you can see addresses like “123 1/2 North 
Main Street” for a building located between 123 and 125 (odd numbers are 
usually on one side of the street so 124 is not available in this example). I 
already am annoyed by QA checkers that flag that as an error. Defining a slash 
to mean something other that the, to me, obvious use as a fraction would make 
things worse.

Cheers,

Tod




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Waterway equivalent of noexit=yes?

2020-08-14 Thread Tod Fitch


> On Aug 14, 2020, at 6:23 PM, Graeme Fitzpatrick  wrote:
> 
> On Sat, 15 Aug 2020 at 00:57, Paul Allen  > wrote:
> 
> I'm not saying that OS is right to make those distinctions.  I'm not saying
> we should automatically do what they do.  But I do think we ought to consider
> what they've done and think about it before committing ourselves.
> 
> "Maybe" (as OSM is British English based) we should be doing exactly that?
> 

One question I have on this is how much are the OS maps tailored to the UK 
environment? I’ve only been to the UK a couple of times but my impression is 
there isn’t much arid or even semi-arid land there to be mapped.

—Tod




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Waterway equivalent of noexit=yes?

2020-08-12 Thread Tod Fitch
Not yet mapped, but my prototype case can be seen in the Bing Imagery with an 
area that collect water around 33.99268,-116.22239 and flows generally to the 
east and north only to dissipate around 33.06076,-116.06077. The collection 
area is no problem nor is the ephemeral waterway until about 
33.03910,-116.099138 where it start bifurcating into smaller and smaller 
channels which eventually disappear.

Cheers,
Tod

> On Aug 12, 2020, at 10:03 AM, Joseph Eisenberg  
> wrote:
> 
> Would waterway=spreads only be used for intermittent streams/rivers where the 
> waterway spreads out and evaporates on the surface?
> 
> If the water appears to sink into sand, gravel or fractured karst rock, would 
> we want a different tag instead, e.g. waterway=sink?
> 
> I understand that natural=cave_entrance can also be used when a waterway 
> drops into a sinkhole or other open cave entrance, often found in limestone 
> (karst) geology areas.
> 
> -- Joseph Eisenberg
> 
> On Wed, Aug 12, 2020 at 9:52 AM Paul Allen  <mailto:pla16...@gmail.com>> wrote:
> On Wed, 12 Aug 2020 at 17:07, Tod Fitch  <mailto:t...@fitchfamily.org>> wrote:
> 
> To clarify it for me, the a “waterway=spread” tag would be used on a node 
> (rendered possibly as an asterisk) or on a way? Or either depending the 
> situation?
> 
> I'd say "spreads" rather than "spread" because that's the term OS uses.  I've 
> only
> ever seen OS use it on the terminal node of a waterway.  More of a crow's-foot
> symbol than an asterisk, usually, but an asterisk works.  I have no idea how
> you'd render it sensibly on a way.  I assume you're thinking of something 
> like a
> very sandy river bed where the water sometimes gets further than other times,
> depending on conditions.  I'd be happy enough with a single node, because
> that's better than we have now.  If you can justify applying it to a way and
> think there's a need then do so, but if you're just trying to keep QA tools
> happy...
> 
> --
> Paul
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging 
> <https://lists.openstreetmap.org/listinfo/tagging>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Waterway equivalent of noexit=yes?

2020-08-12 Thread Tod Fitch


> On Aug 12, 2020, at 4:49 AM, Paul Allen  wrote:
> 
> On Tue, 11 Aug 2020 at 19:19, Tod Fitch  <mailto:t...@fitchfamily.org>> wrote:
> 
> It occurred to me that the area where water flow disappears is indeterminate 
> [1], thus the problem mapping it.
> 
> Ordnance Survey represents this as a sort of star of very short waterways
> at the approximate point of disappearance and labels them "spreads."
> 
> The map is representative.  We can tolerate precisely specified amounts of
> doubt and uncertainty.  The name "spreads" indicates the indeterminacy even
> if we map it as a node.  Just as we render a spring as a circle on the
> map, an asterisk would do for spreads.
> 
> Perhaps a “indeterminate=yes” tag on the last node of a water way that 
> “peters out” [2] could be used to signal the QA tools that the end of a water 
> way is not a mistake.
> 
> If we tag it as waterway=spreads the indeterminacy is implied and QA tools
> can be happy there is no mistake.
> 
> Might be useful in cases other than an ephemeral water way in the desert 
> though I haven’t thought of one yet.
> 
> Useful in coastal waterways that peter out in sand above high water.  Or 
> coastal
> waterways that peter out in sand just below high water when the tide is out - 
> they
> haven't carved a channel down to the low water mark, they just vanish into the
> sand (but QA tools won't have a problem with those if they connect to the high
> water mark).  And yes, there are coastal waterways that carve a channel 
> through
> a beach right down to low water and others that just peter out on the beach
> close to high water.
> 

To clarify it for me, the a “waterway=spread” tag would be used on a node 
(rendered possibly as an asterisk) or on a way? Or either depending the 
situation?

Thanks!
Tod





signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Waterway equivalent of noexit=yes?

2020-08-11 Thread Tod Fitch
I’ve not seen a suggestion for this case yet that has any traction. . .

It occurred to me that the area where water flow disappears is indeterminate 
[1], thus the problem mapping it.

> Definition of indeterminate:
> 1a : not definitely or precisely determined or fixed : vague
> b : not known in advance
> c : not leading to a definite end or result

Or from my old microprint edition of the Oxford English Dictionary (please 
excuse any transcription errors):

> 1. Not definitely set down; undetermined.
> 2. Not fixed in extent, number, character or nature; left uncertain as to 
> limits of extent, number, etc.; of uncertain size or character; indefinite, 
> indistinct, uncertain.

Perhaps a “indeterminate=yes” tag on the last node of a water way that “peters 
out” [2] could be used to signal the QA tools that the end of a water way is 
not a mistake. Might be useful in cases other than an ephemeral water way in 
the desert though I haven’t thought of one yet.

Cheers!
Tod

[1] https://www.merriam-webster.com/dictionary/indeterminate
[2] https://www.merriam-webster.com/dictionary/peter%20out

> On Aug 3, 2020, at 1:18 PM, Tod Fitch  wrote:
> 
> Signed PGP part
> I’ve yet to find a term or tag name that I like for the case where the water 
> disappears from the surface in a desert environment. One issue is the 
> location will vary depending on how big the storm was (or perhaps for a 
> seasonal stream how wet the preceding wet season was). So it might be a tag 
> applied to an intermittent way. Or, for simplicity, it might be a tag on the 
> last node of the way. And, of course, the only reason for it is to let the QA 
> tools know that it is not a mistake.
> 
> I wonder if the QA tools could simply ignore connectivity issues for 
> intermittent waterways?
> 
> Thoughts?
> 
>> On Jul 24, 2020, at 2:04 AM, Alan Mackie  wrote:
>> 
>> This is specifically about how to label the end point where the waterway 
>> doesn't drain into another waterbody, not how to label an intermittent 
>> stream in general.
>> 



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Apparent conflicting/redundant access tags

2020-08-05 Thread Tod Fitch
My reading of the wiki [1] indicates that the more specific tag overrides the 
less specific tag. And the transport mode section [2] of that has examples very 
much like those in your question.

So:
access=no
foot=yes

Means that all access other than foot is prohibited.

And:
access=yes
bicycle=no

Means you can walk, drive or ride a horse, etc. but you can’t bicycle.

For what its worth, I just had a question along this same line for a trail in a 
local wilderness park that I edited a year or so ago. All I did was split the 
way and keep the existing tagging (which I agreed with). But apparently the 
Strava app had a problem with the tagging (access=no, foot=designated, 
bicycle=designated), so I guess my reading of the wiki doesn’t match all data 
consumers implementations.

Cheers,

Tod

[1] https://wiki.openstreetmap.org/wiki/Key:access
[2] https://wiki.openstreetmap.org/wiki/Key:access#Transport_mode_restrictions

> On Aug 5, 2020, at 1:44 PM, Mike Thompson  wrote:
> 
> Hello,
> 
> If:
> access=no
> foot=yes
> 
> Does this mean that all access except foot travel is prohibited, or is it an 
> error?
> 
> If:
> access=yes
> bicycle=no
> 
> Does this mean that all access except bicycle travel is allowed, or is an 
> error?
> 
> Here is one example of the first case:
> https://www.openstreetmap.org/way/834296397 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Waterway equivalent of noexit=yes?

2020-08-03 Thread Tod Fitch
I’ve yet to find a term or tag name that I like for the case where the water 
disappears from the surface in a desert environment. One issue is the location 
will vary depending on how big the storm was (or perhaps for a seasonal stream 
how wet the preceding wet season was). So it might be a tag applied to an 
intermittent way. Or, for simplicity, it might be a tag on the last node of the 
way. And, of course, the only reason for it is to let the QA tools know that it 
is not a mistake.

I wonder if the QA tools could simply ignore connectivity issues for 
intermittent waterways?

Thoughts?

> On Jul 24, 2020, at 2:04 AM, Alan Mackie  wrote:
> 
> This is specifically about how to label the end point where the waterway 
> doesn't drain into another waterbody, not how to label an intermittent stream 
> in general.
> 



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Waterway equivalent of noexit=yes?

2020-08-03 Thread Tod Fitch


> On Jul 22, 2020, at 10:24 AM, Martin Koppenhoefer  
> wrote:
> 
> 
> Am Mi., 22. Juli 2020 um 17:27 Uhr schrieb Tod Fitch  <mailto:t...@fitchfamily.org>>:
> It certainly would not be my pick of terms, but it seems manhole=drain has an 
> appropriate definition in the wiki [1] and considerable use [2] for a place 
> that water disappears into a man made structure. Most of them around here are 
> not circular and many appear to be too small for a person to get into when 
> the grate is removed. But OSM has odd tagging for other things so why not 
> this too?
> 
> 
> I would rather try to limit the "odd cases", and maybe even get rid of them 
> in the long term. There is no benefit from using inappropriate terms. If 
> manhole=* is generally considered to be about manholes, why would we want to 
> encourage more usage for non-manhole objects?
> 
> IMHO we should fix the definition in the wiki by making it more precise, as 
> there aren't so many yet.
> 

Looking at wikipedia, it seems that “storm drain” is used in the UK, Canada and 
the US [1]. And there is an “inlet” [2] associated with it. What are the 
opinions using:

storm_drain = inlet

For the location that a surface drainage ditch disappears into an underground 
storm water system. The tag would most often be used on a node.

[1] https://en.wikipedia.org/wiki/Storm_drain
[2] https://en.wikipedia.org/wiki/Storm_drain#Inlet





signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

2020-08-02 Thread Tod Fitch


> On Aug 1, 2020, at 7:45 PM, Graeme Fitzpatrick  wrote:
> 
> Slightly OT question here, please.
> 
> I remember reading a US press article ~12 months ago (may have even been 
> mentioned on here in discussions at the time re = aboriginal_land?) to the 
> effect that the US Supreme Court was shortly due to rule on whether historic 
> tribal lands actually now belong to the Indian Nations?
> 
> Does that ring any bells with our US members, & are you aware of any outcome?
> 
> Thanks
> 
> Graeme
> 

Assuming that NPR is not geo-restricted to the US:

https://www.npr.org/2020/07/09/889562040/supreme-court-rules-that-about-half-of-oklahoma-is-indian-land
 





signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] addr:street for routes

2020-07-31 Thread Tod Fitch


> On Jul 31, 2020, at 12:45 PM, Paul Johnson  wrote:
> 
> So keep State Highway 214 in addr:street=* values, but that doesn't stop 
> noname=yes and ref=NY 214 being the correct values for the way itself.
> 

Which will, as I have found by experience, result in OSM QA tools flagging you 
as the last editor of a bunch of addresses with no matching street.



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Orange County, California Building and Address Import

2020-07-28 Thread Tod Fitch
I am beginning to thing you are correct that they intend to make the additional 
information available via RapiD and then assume various mappers will use to add 
data to OSM. I think he RapiD data can be accessed via the “MapWithAI: Download 
Data” mechanism within JOSM. In my part of southern Orange County that data has 
only the Microsoft/Bing at present and does not have address or height data.

If I get confirmation of that they are only preparing for use as additional 
layers within RapiD, then I will go ahead with my own import attempt with the 
next steps being creation of a wiki page and making the announcement here.

—Tod

> On Jul 28, 2020, at 12:11 PM, Alan Mackie  wrote:
> 
> I thought the thing ESRI recently announced was basically additional layers 
> within RapiD, but I may be conflating two separate things.
> 
> On Tue, 28 Jul 2020 at 15:53, Tod Fitch  <mailto:t...@fitchfamily.org>> wrote:
> I became aware that Orange County, California has released building outline 
> and address data to public domain [1] and started prep work for import to 
> OSM. In reading through the import guidelines [2] it seemed the process was:
> 
> 1. Create a workflow (but don’t do any actual importing at this stage).
> 2. Document the workflow in both a dedicated wiki page and in the import 
> catalog [3]
> 3. Announce to the tagging list and the list for the area, in this case 
> talk-us, the proposed import.
> 4. Once comments on the proposed import have been addressed, commence the 
> import (documenting progress along the way).
> 
> To that end, I have reviewed the data. Processed sample portions to the point 
> just short of uploading to OSM to verify I think the workflow is okay.
> 
> This is where I am at present:
> 
> 1. I’ve reviewed the data and decided that a rather slow manual process is 
> needed because of the low quality of the building outlines.
> 2. I’ve created a workflow and tested to the point where I think it will 
> result in a good quality import.
> 3. I’ve created a GitHub project containing the description and scripts I am 
> using [4].
> 4. I started to create a wiki page containing the same description but found 
> an existing import page for the same data [5]
> 
> At this point I am paused and looking for guidance as there is another import 
> proposed for this data. I don’t see evidence that this other import has 
> actually started.
> 
> I have added a discussion item to that import page expressing my concern 
> about building footprint quality and the steps that will be needed to bring 
> it up to standard and given my GitHub project page link.
> 
> But I am confused.
> 
> I thought that imports needed to be added to the catalog. This import is not 
> in the table at present.
> 
> I thought that import specific user IDs were required. This import pages 
> states “The plan is for most OSM mappers to use their standard OSM accounts 
> if they are editing with RapiD and JOSM editors. . .”
> 
> I thought that imports needed to be announced in this import list. Looking 
> though the archives [6] for the last few months, I don’t see it.
> 
> So, do I continue with my import plan with the next step being creating a new 
> wiki page for it? Or do I wait for ERSI to do an import then verify the 
> quality? I don’t see a way to participate with ERSI listed in the import wiki 
> page they’ve created.
> 
> Thanks for the guidance!
> 
> Tod Fitch
> 
> [1] 
> https://data-ocpw.opendata.arcgis.com/datasets/8db4b58e6bbf4f6cac676f477348be48_0
>  
> <https://data-ocpw.opendata.arcgis.com/datasets/8db4b58e6bbf4f6cac676f477348be48_0>
> [2] https://wiki.openstreetmap.org/wiki/Import/Guidelines 
> <https://wiki.openstreetmap.org/wiki/Import/Guidelines>
> [3] https://wiki.openstreetmap.org/wiki/Import/Catalogue 
> <https://wiki.openstreetmap.org/wiki/Import/Catalogue>
> [4] https://github.com/n76/OSM_OC_Buildings 
> <https://github.com/n76/OSM_OC_Buildings>
> [5] 
> https://wiki.openstreetmap.org/wiki/Import/Orange_County,_California_Buildings
>  
> <https://wiki.openstreetmap.org/wiki/Import/Orange_County,_California_Buildings>
> [6] https://lists.openstreetmap.org/pipermail/imports/ 
> <https://lists.openstreetmap.org/pipermail/imports/>
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging 
> <https://lists.openstreetmap.org/listinfo/tagging>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Orange County, California Building and Address Import

2020-07-28 Thread Tod Fitch
Oops. Sent to wrong email list. Should have been imports. Please disregard.

—Tod

> On Jul 28, 2020, at 7:52 AM, Tod Fitch  wrote:



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Orange County, California Building and Address Import

2020-07-28 Thread Tod Fitch
I became aware that Orange County, California has released building outline and 
address data to public domain [1] and started prep work for import to OSM. In 
reading through the import guidelines [2] it seemed the process was:

1. Create a workflow (but don’t do any actual importing at this stage).
2. Document the workflow in both a dedicated wiki page and in the import 
catalog [3]
3. Announce to the tagging list and the list for the area, in this case 
talk-us, the proposed import.
4. Once comments on the proposed import have been addressed, commence the 
import (documenting progress along the way).

To that end, I have reviewed the data. Processed sample portions to the point 
just short of uploading to OSM to verify I think the workflow is okay.

This is where I am at present:

1. I’ve reviewed the data and decided that a rather slow manual process is 
needed because of the low quality of the building outlines.
2. I’ve created a workflow and tested to the point where I think it will result 
in a good quality import.
3. I’ve created a GitHub project containing the description and scripts I am 
using [4].
4. I started to create a wiki page containing the same description but found an 
existing import page for the same data [5]

At this point I am paused and looking for guidance as there is another import 
proposed for this data. I don’t see evidence that this other import has 
actually started.

I have added a discussion item to that import page expressing my concern about 
building footprint quality and the steps that will be needed to bring it up to 
standard and given my GitHub project page link.

But I am confused.

I thought that imports needed to be added to the catalog. This import is not in 
the table at present.

I thought that import specific user IDs were required. This import pages states 
“The plan is for most OSM mappers to use their standard OSM accounts if they 
are editing with RapiD and JOSM editors. . .”

I thought that imports needed to be announced in this import list. Looking 
though the archives [6] for the last few months, I don’t see it.

So, do I continue with my import plan with the next step being creating a new 
wiki page for it? Or do I wait for ERSI to do an import then verify the 
quality? I don’t see a way to participate with ERSI listed in the import wiki 
page they’ve created.

Thanks for the guidance!

Tod Fitch

[1] 
https://data-ocpw.opendata.arcgis.com/datasets/8db4b58e6bbf4f6cac676f477348be48_0
[2] https://wiki.openstreetmap.org/wiki/Import/Guidelines
[3] https://wiki.openstreetmap.org/wiki/Import/Catalogue
[4] https://github.com/n76/OSM_OC_Buildings
[5] 
https://wiki.openstreetmap.org/wiki/Import/Orange_County,_California_Buildings
[6] https://lists.openstreetmap.org/pipermail/imports/



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-22 Thread Tod Fitch


> On Jul 22, 2020, at 8:09 AM, Jmapb  wrote:
> 
> If this unfortunate tagging practice really needs to be preserved (the idea 
> of retagging so many bicycle=no ways is certainly daunting) then I'd suggest 
> a new key, dismounted_bicycle=*, which will function as a regulation key 
> (like smoking=*) rather than a vehicle access key. Total bicycle prohibition 
> would be encoded with both bicycle=no and dismounted_bicycle=no, and other 
> dismounted_bicycle=* values can be developed for whatever the regulations are 
> in particular situations.
> 
Why? The suggestion that all the places that properly tagged bicycles=no now 
need to be revisited and have a new dismounted_bicycles=no tag added implies 
that the people who took “no” to mean something other than “no” prevail and the 
rest of us have to go back and re-tag things.

Since many miles/kilometers of ways will need to be retagged either way, why 
not go with the straight forward “no means no” and “dismount means dismount”? 
Makes a lot more sense to me that “no only really means no if there is an 
additional dismounted_bicycle=no” tag too.

Cheers!

—Tod





signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Waterway equivalent of noexit=yes?

2020-07-22 Thread Tod Fitch
It certainly would not be my pick of terms, but it seems manhole=drain has an 
appropriate definition in the wiki [1] and considerable use [2] for a place 
that water disappears into a man made structure. Most of them around here are 
not circular and many appear to be too small for a person to get into when the 
grate is removed. But OSM has odd tagging for other things so why not this too?

I will start tagging that where the surface drainage ditches disappear into the 
ground. I wonder if QA tools like Osmose will stop nagging me about those 
waterways.

We are still left with the situation where an ephemeral waterway fans out over 
the desert and disappears. We need some sort of tagging to indicate this is not 
a mistake and I’ve not seen a tag or value come up in this discussion that has 
any existing use or consensus in the list.

These are definitely not sink holes and shouldn’t be tagged as such.

Digression: The wiki page for natural=sinkhole [3] says that it is a tagging 
error to use natural=sink_hole. When I look at taginfo I see nearly 2000 
occurances of natural=sink_hole and none for natural=sinkhole [4]. I guess the 
write of the wiki page disagreed with the spelling of the most used spelling of 
the tag value.

Anyway, back to waterways dissipating in the desert. Where the flowing water 
disappears varies considerably from storm to storm so maybe it shouldn’t even 
be a tag on the last node of the way. Maybe the last section of the way could 
have a tag instead?

Would a tag on the way be better or worse than a tag on the last node on the 
way?

Maybe a discussion on this will turn up a possible way to map the situation.

Thank you for the responses so far!

—Tod

[1] https://wiki.openstreetmap.org/wiki/Tag:manhole%3Ddrain
[2] https://taginfo.openstreetmap.org/search?q=manhole%3Ddrain
[3] https://wiki.openstreetmap.org/wiki/Tag:natural%3Dsinkhole
[3] https://taginfo.openstreetmap.org/search?q=natural%3Dsink


> On Jul 20, 2020, at 3:19 PM, Volker Schmidt  wrote:
> 
> Manhole=drain has more than 2000 uses, most of them seem to be water drainage 
> grids with no access for humans.
> But if you want to retag them with something different you would need to do 
> this manually.
> I would not touch it, even if it is an unfortunate tagging.
> 
> On Mon, 20 Jul 2020 at 21:33, Alan Mackie  > wrote:
> 
> 
> On Mon, 20 Jul 2020 at 11:28, Paul Allen  > wrote:
> On Mon, 20 Jul 2020 at 10:59, Volker Schmidt  > wrote:
> manhole=drain is widely used in OSM for water drainage grids, that are not 
> suitable for people to entr - se the photo on the wikipage 
> 
> 
> People have used manhole=drain for that purpose and the wikipage
> for manhole=drain documents that use.  However, that photo appears
> to be of a UK storm drain which is not a manhole by my definition
> (too small for entry by a person) or by the wiki's definition for
> Key:manhole which states "Hole with a cover that allows access to
> an underground service location, just large enough for a human to climb
> through."
> 
> In my opinion we should deprecate manhole=drain except where
> it really is large enough for access by a person.  We need a
> better tag.  Well, two tags.  One for storm drains and one
> for sinks that are too small to merit natural=sinkhole with
> any of the current sinkhole=* types.  Oh, and a tag for
> spreads, too.
> 
> --
> Paul
> 
> I think we also need one for "entrances" to pipes/tunnels of unknown extent 
> where the entrance is by horizontal movement of the water rather than by 
> falling into a hole. The presence/absence of gratings or mesh may be useful 
> for these too.
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

2020-07-22 Thread Tod Fitch
This thread has been quite amazing to me. My impression is that it starts with 
some routers (a.k.a data consumers, a.k.a. “renderers”) treating a “no” as a 
“maybe” and now people are looking for a new term to indicate that “we really, 
really, mean NO!”. This is worse than tagging for the render, it is obsoleting 
a straight forward and explicit tag value for a broken renderer.

Discussion devolves into “if I disassemble by bicycle and put into wheeled 
luggage is it okay now?”.

Why not treat “no” as no? If I can push the bicycle through then we already 
have “dismount”.

Is there some other way of getting a bicycle through? If so, then come up with 
a new value for that (“disassembled”?).

In the meantime, file bug reports against any router that routes a bicycle over 
a “no”.

At least where I am, “no really means no” and if you are caught with a bicycle 
at all then you are subject to a fine. Thousands of kilometers of paths are so 
marked and it really wouldn’t be nice to redefine an existing value.

Cheers!
Tod

> On Jul 22, 2020, at 7:34 AM, Allroads  wrote:
> 
> 
> https://images.mapillary.com/yQWkL-XX5eRN5A2j0JkKIA/thumb-2048.jpg 
> 
> Geen toegang:
> - met (brom)fietsen.
> No access:
> - with bicycles.
> This is written, grammatically and  orthographly, in a way, that the 
> "vehicle" is meant.
> explicit the bicycle no access.
> 
> This is privat land, Staatsbosbeheer, owned or in control, all over the 
> Netherlands, you see these type of signs, arranged in the same way, the 
> layout.
> Mostly all of these roads/tracks path are permissive
> 
> https://commons.wikimedia.org/wiki/File:Waterloopbos._Natuurgebied_van_Natuurmonumenten._Informatiebord.jpg
>  <>
> - Fietsers op verharde fietspaden en wegen
> -Bicyclist on paved cycleway and roads.
> Here is written what is allowed.
> But more important:
> Overigens verboden toegang Artikel 461 W.v.S.
> Others prohibited access, article 461 Code criminal law.
> The word  “Overigens” means:  all the other which is not mentioned above on 
> the sign
> Not pushing a bicycle on a unpaved cyclway, path, tracks. So others then 
> “wegen” roads.
> 
> A active Openmapstreet member got  a ticket for pushing his bike on a not 
> allowed “wegen” by a certified ranger (BOA) Community service officer.
> 
> This sign with “Overigens”  of  the private organisation Natuurmonumenten, 
> you find them all over the Netherlands, with the same layout.
> 
> 
> 
> ‘'
> bicycle=explicit_no sounds to me like "there is an explicit sign forbidding 
> this",
> 
> Indeed.
> 
> not "bicycle vehicle itself is prohibited, not just cycling".
> 
> That sounds like bicycle=prohibited. :)
> 
> ‘'
> 
> Text on sign: “Overigens” and “- met fietsen”  "bicycle vehicle itself is 
> prohibited”
> 
> I need a value .*=explicit_no for “the vehicle” or some other value that 
> means the same. “the bicycle is not allowed”
> 
> This is for all kind of transportation and vehicles. Pushing carry/not 
> allowed.
> 
> 
> 
> 
> 
> 
> It seems highly strange that you wouldn't even be allowed to carry/push your 
> bike, are you sure that was what it meant?
> Do you have a picture of the sign?
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Waterway equivalent of noexit=yes?

2020-07-18 Thread Tod Fitch

> On Jul 18, 2020, at 12:24 PM, Andy Townsend  wrote:
> 
> On 18/07/2020 19:41, Alan Mackie wrote:
>> 
>> 
>> On Sat, 18 Jul 2020 at 19:09, Paul Allen  wrote:
>> On Sat, 18 Jul 2020 at 18:53, Tod Fitch  wrote:
>> 
>> What I’d like is one or two tags to indicate that all visible indications of 
>> a water way ends at this point and that the QA tools should not flag them as 
>> errors to be fixed.
>> 
>> One of the things we need is an anti-spring.  Marked on Ordnance Survey maps
>> as a sink.  We have natural=sinkhole but that seems only to apply to a large
>> hole and/or depression.
>> 
>> The closest I can find on the wiki is manhole=drain? sinkhole=ponor seems to 
>> be for natural-looking versions.
>> 
> The "one that everyone* did in geography at school" is 
> https://www.openstreetmap.org/node/944314148/history
> 
> That's currently tagged as "waterway=cave_of_debouchement”.
> 

The desert ones aren’t sink holes. Often the intermittent/ephemeral waterways 
spread out over the pediment [1] or alluvial fan [2] at the base of the 
mountains and simply dissipates.

Not yet mapped, but if you look at the Bing Imagery for this area [3] you can 
see a well defined “wash” (local term for this type of waterway) coming from 
the hills/mountains to the west and fan out to nothing over the desert floor in 
a north easterly direction.

[1] https://www.britannica.com/science/pediment-geology
[2] https://en.wikipedia.org/wiki/Alluvial_fan#In_arid_climates
[3] https://www.openstreetmap.org/#map=16/33.0877/-116.1253



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Waterway equivalent of noexit=yes?

2020-07-18 Thread Tod Fitch
During this period of “social distancing” I’ve been trying to work down the 
number of errors that tools like Osmose have reported about my editing. I am 
getting close to starting on the warnings about waterways not connecting 
properly. There are a couple of situations that I’ve mapped that I believe 
would benefit from having a waterway equivalent to the noexit tag used on 
highways:
A number of housing developments in my semi-arid area have concrete lined 
exposed drainage ditches installed on hill side cuttings to control erosion. 
Those ditches usually lead to a grates to an underground storm water piping 
system. The issue is that there is little or no evidence where those 
underground pipes go. So the exposed drainage ditches I’ve mapped just end at 
the grate and I get warnings from QA tools.
I’ve done some mapping in the much more arid desert areas inland and there is 
another issue there. The ephemeral waterways that start in the hills and 
mountains sometime turn into a delta like fan of splitting ways each eventually 
ending/disappearing in random places on the valley floor. My experience from 
hiking and driving in these areas indicates that the waterways are more visible 
from the air than on the ground, so if it disappears on the aerial imagery, it 
most definitely disappears if viewed on the ground.
I’ve found nothing in the wiki that seems to fit these situations.

What I’d like is one or two tags to indicate that all visible indications of a 
water way ends at this point and that the QA tools should not flag them as 
errors to be fixed.

I can see that the underground storm drain system may need a different 
indication as the waterway does continue, it is just not visible where. But in 
the desert cases, the water ways really do just end. Maybe two variations: “It 
continues but in unknowable direction” and another for “it really does stop 
here”.

Looking at TagInfo, the case of the surface drains disappearing might be 
covered by the lightly used and undocumented “drain:point_feature=inflow_pipe” 
[1]. But I haven’t found anything for the desert situation.

Suggestions?

—Tod

[1] 
https://taginfo.openstreetmap.org/tags/drain%3Apoint_feature=inflow_pipe#overview


signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag minor commercial roads?

2020-07-16 Thread Tod Fitch

> On Jul 16, 2020, at 10:22 AM, Paul Johnson  wrote:
> 
> On Thu, Jul 16, 2020 at 12:17 PM Matthew Woehlke  > wrote:
> I'm wondering what, if anything, I should do with
> https://www.openstreetmap.org/way/351516889 
> . It doesn't seem to meet the
> definition of a highway=residential, but I'm not convinced it is a lowly
> highway=service, either, but I also can't easily demonstrate it is
> highway=tertiary.
> 
> How should I classify this?
> 
> Unclassified?  It's the de-facto step down from tertiary.

It looks like it only services that one building/complex. I’d classify it as 
“service” if I were mapping it.




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - junction=intersection

2020-07-10 Thread Tod Fitch

> On Jul 10, 2020, at 9:26 AM, Matthew Woehlke  wrote:
> 
> On 10/07/2020 11.24, Peter Elderson wrote:
>> Well, if you do a couple of intersections it's no big deal, but if every
>> intersection would need this and it breaks relations, no matter whose fault
>> it is, it is a problem. Then it's not just modeling, but forced repair
>> work.

In the old days the wiki said you could put a highway=stop or highway=give_way 
node on a way and the data consumer would determine the nearest intersection 
and just do the right thing. I mapped several thousand, yes thousand, stop 
signs that way. Later it was decided that each of those nodes should also have 
a direction=forward or direction=backward tag as well. Years later, I am still 
updating those highway=stop nodes as the various QA tools nag that I am 
responsible for miss tagging them. So I am pretty sensitive to changing tagging 
norms on intersections.

That change in tagging was also annoying because at the time the direction tag 
was defined and used for showing the bearing, in degrees, something (cave 
opening, adit, etc.) was facing. So we ended up with two separate semantics for 
the direction tag depending on the type of node. And an inconsistency between 
how stop and yield sign directions were specified (“direction=*”) and how 
traffic light directions were specified (“traffic_signals:direction=*”).

> 
> Sure, but my point was that I don't think my proposal changes anything here, 
> since someone (myself, for example) might already split ways at intersections 
> for other reasons.
> 
>> May be worth it, but I would like to know that at proposal time, not
>> by discovering all routes and turn restrictions are broken.
> 
> That's fair. I'm not actually sure offhand what happens when you split a way 
> at or near an intersection, although I would hope that editors can update the 
> relations correctly. This is probably more of an issue with intersections 
> where turn lanes are separately modeled, and I wonder how many of those 
> aren't already split as they would need to be.
> 
> That said, I think it makes sense to add a note asking editors to be mindful 
> of such things. I'll add some wordage to the proposal.


With respect to what happens when a way is split near an intersection, I have 
been using the “tag all incoming ways” [1] method for mapping intersections. On 
two way roads leading into an intersection current tagging asks for a 
direction=* tag on stop and yield signs and for a traffic_signals:direction=* 
tag on traffic signals. I have seen a few intersections where the limit line 
(where you would place the stop sign or traffic light node) exactly on top of a 
the transition to a bridge. This leads me to wonder what the semantics of 
“direction=forward | backward” or “traffic_signals:direction=forward | 
backward” are if the node is at the change of ways, especially if the ways have 
different directions. I haven’t seen this defined.

But I think it is a situation that could be come more common if all ways are 
split where they enter an intersection so some thought should be given to that.

Cheers!
Tod

[1] 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Tag_all_incoming_ways




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] QA Tag for addr:city vs al8/al9 boundary

2020-06-30 Thread Tod Fitch
Simon is being much more polite and succinct than my first reaction. Checking 
the addr:city against the enclosing administrative boundary will not work well 
in the areas I am familiar with.

Let me give some examples from the western United States:

• The “town” I lived in growing up was Tucson, Arizona. It was used in our 
mailing address. It was used for emergency response. It was given in directions 
to our house. Except we lived about 20 KM outside the incorporated boundaries 
of the City of Tucson and our area was administered by Pima County.

• In the San Fernando Valley area of the Los Angeles metropolitan area you have 
a bunch of named areas, some having relatively distinct boundaries: Granada 
Hills, Chatsworth, Northridge, Van Nuys, etc. Those are the postal “town” names 
even though they are not administrative areas for anything other than delivery 
of goods and services to the addresses therein as they are officially part of 
the City of Los Angeles and administered by the City of Los Angeles. And don’t 
confuse those “towns” with Burbank, San Fernando, etc. also in the San Fernando 
Valley, which are separately incorporated real cities for real administrative 
boundaries.

• The “town” of Oracle, Arizona where my parents moved when they retired isn’t 
really a town even though it has a post office, a sheriff’s substation and even 
a regional county administration building with the name “Oracle” on it. It is 
an “unincorporated” area administered by the Pinal County (county seat is in 
Florence about 150 KM away). And it has no distinct boundaries. Heck, even 
“Biosphere II” which is promoted as being in Oracle is about 10 KM from the 
centroid of houses that are considered to be “in” Oracle. Oracle is another 
interesting case in that there is no local mail delivery: Residents are given a 
free postal box at the Oracle Post Office. The street addresses, including 
addr:city, are used for other delivery services (FedEx, UPS, etc.) and for 
emergency response (fire, ambulance, sheriff). So addr:city values there can’t 
even be considered as postal city values. They just “are”. There is no 
administrative boundary, no nothing. Except you need that information if you 
are going to give directions or hope that a call for emergency services results 
in people getting to the correct location.

This is even more misguided than the recently added validation check nagging 
you to put a “segregated” tag on multipurpose paths that allow both hikers and 
(mountain) bicyclists: The back country trails here vary between 1 meter (if 
we’ve done “trail maintenance” recently) to maybe 10 cm if it has been a while 
since our teams have been able to get to that section. Adding “segregated” to 
the list of tags for a back country trail is just noise around here.

At least “segregated” on a multipurpose backcountry path is only noise. 
Checking “addr:city” against the enclosing administrative boundary will do real 
harm if mappers “correct” things to “fix” the reported mismatches.

Cheers,
Tod


> On Jun 30, 2020, at 5:38 AM, Simon Poole  wrote:
> 
> Signed PGP part
> IMHO addr:city is the "postal" city at least for countries that have such a 
> concept. With other words validating the tag against admin boundaries is 
> fundamentally flawed to start with and will only work in the cases in which 
> admin entity and postal city just happen to have the same name (in the 
> country I'm resident in there are nearly no post code boundaries that are 
> exactly the same as the administrative boundary with the same name).
> 
> Simon
> 
> Am 30.06.2020 um 13:59 schrieb Florian Lohoff:
>> Hi,
>> i am running some address validation pipeline as others do aswell. In
>> Germany we have the case that most of the time the addr:city
>> on the addresses matches the name on the admin_level 8 boundary
>> (Sometimes admin_level 6).
>> 
>> So normally you have:
>> 
>>  boundary=administrative
>>  admin_level=8
>>  name=Gütersloh
>> 
>> And all addresses carry a
>> 
>>  addr:city=Gütersloh
>> 
>> Now there are some exceptions. One example i always paint red in the
>> validator is 33428 Marienfeld.
>> 
>> For Marienfeld there is an admin_level=8 which carries the
>> name=Harsewinkel which is correct for all "suburbs" or villages
>> belonging to Harsewinkel except Marienfeld.
>> 
>> Marienfeld itself carries a admin_level=9
>> 
>> So i'd like to have a place in OSM where i store this exceptions
>> information (There are plenty other places which have this
>> exception).
>> 
>> So i would propose to set an "addr:city=Marienfeld" on the admin_level=9
>> boundary. So the address validator knows that addresses contained within
>> this al9 should carry a different addr:city than they normally would
>> using the al8.
>> 
>> Other ideas?
>> 
>> Flo



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org

Re: [Tagging] "Feature Proposal - RFC - Qanat"

2020-06-21 Thread Tod Fitch
A few questions:

1. What is the “elevation” tag supposed to mean? It is not in the wiki and the 
use count is pretty small [1].

2. Why level=-3? I seems like that would be dependent on what other underground 
features were being mapped.

3. Why status=abandoned | active? Wouldn’t the lifecycle prefix be a better fit?

—Tod

[1] https://taginfo.openstreetmap.org/keys/elevation#values


> On Jun 21, 2020, at 3:05 PM, Joseph Guillaume  
> wrote:
> 
> Hi all,
> 
> I've been in touch with the person who's mapped a lot of the 
> waterway=canal+man_made=canal, and they didn't have any specific rationale.
> 
> After seeing the proposal page, their preferred tagging is:
> 
> canal=qanat
> elevation=-3
> layer=-3
> location=underground
> name=Bir.1.2
> status=abandoned or active
> tunnel=flooded
> waterway=canal
> 
> I'm not sure how to check how many other people have been mapping 
> man_made=qanat, but as someone who's mapped a lot of canal=qanat, I'm happy 
> to proceed with that as a new de facto.
> 
> I'm happy to still go to a vote if Jeisenbe would like, but I don't 
> personally feel comfortable mapping either man_made=qanat (too generic, 
> doesn't fit with waterways) or historic=aqueduct+aqueduct=qanat (visions of 
> Roman aqueducts don't sit well with me in this case - only some qanats are of 
> historic value).
> 
> Thanks for the interesting discussion,
> 
> JoeG
> 
> 
> 
> On Sun., 21 Jun. 2020, 4:44 am Joseph Eisenberg,  > wrote:
> > Most existing uses of man_made=qanat by the way are in combination with 
> > waterway=canal.
> 
> Thank you for mentioning this. There are only 5 ways with man_made=qanat, 
> without waterway=* - https://overpass-turbo.eu/s/Viq 
> 
> 
> I will update the proposal page with this information.
> 
> So there is no debate about whether or not to tag these features with 
> waterway=canal.
> 
> We are deciding whether or not the additional tag should be man_made=qanat or 
> canal=qanat.
> 
> Since waterway=canal is currently used for all kinds of irrigation canals and 
> aqueducts, it makes sense to consider these irrigation features to be a type 
> of canal.
> 
> I have previously considered whether or not it might be sensible to create a 
> whole new value of waterway=* for aqueducts and irrigation canals, but that 
> does not seem to solve any particular problems: irrigation canals can be as 
> narrow as 20 cm or as wide as 20 meters, as can aqueducts used for drinking 
> water, so tagging usage=irrigation and width=*, while using the existing main 
> tag, is probably reasonable.
> 
> – Joseph Eisenberg
> 
> On Sat, Jun 20, 2020 at 5:17 AM Christoph Hormann  > wrote:
> 
> I think this is a good idea.  Both in the sense of establishing a distinct 
> tagging for it that does not engross qanats with other types of underground 
> waterways and in the sense of using a non-English and non-European term where 
> the most descriptive and clear term comes from a non-European language.  We 
> have other cases of such tags in OSM but still in a proposal process which is 
> dominantly discussed in English this is rare and kind of a litmus test for 
> how culturally diverse tagging in OSM can be and if the cultural geography of 
> non-European regions can be mapped in the classifications used locally just 
> as we are used to doing it in Europe and North America.
> 
> Most existing uses of man_made=qanat by the way are in combination with 
> waterway=canal.
> 
> --
> Christoph Hormann
> http://www.imagico.de/ 
> 
> ___
> 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 mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Help explain the difference between path and track

2020-06-10 Thread Tod Fitch


> On Jun 10, 2020, at 12:19 PM, Mateusz Konieczny via Tagging 
>  wrote:
> 
> Jun 10, 2020, 19:40 by t...@fitchfamily.org :
> 
> 
>> On Jun 10, 2020, at 12:31 AM, Volker Schmidt > > wrote:
>> 
>> Two points to get this thread back on track:
>> 
>> 1) The highway=track tag has always been wider than agriculture and 
>> forestry. There is an often overlooked "etc." in the description on the 
>> wiki, and it has been there from the very first version of 26 May 2008. (see 
>> also Duck_tagging )
>> 
>> 2) "In my rendering of hiking maps I currently have to look at 13 tags and 
>> their values to make a decision ..."
>> "I think we need some more values for the highway tag..."
>> These two statements together (made in the same message in this thread)  
>> highlight the basic problem of this and other discussions:
>> If we need to look at X tags and values now, adding new values only makes 
>> the list longer - there's no way around this.
> 
> My hope would be that addition of more highway=* values that better match 
> what people are trying to map would be a short term pain (data consumers need 
> to add one more check) but long term benefit.
> 
> For example, as mappers discover they can map a voie verte in France or a 
> “Rails to Trails” in the USA as highway=greenway and not as arbitrary choice 
> of track, path, cycleway or bridle path differentiated by a bunch of 
> foot=designated, bicycle=designated, etc. tags they are likely to migrate to 
> the simpler tagging. At some time in the future data consumers could begin to 
> be more restrictive on their logic.
> While not categorically opposed - it would need a solid proposal. 
> highway=via_ferrata seems one
> that is most viable
> 
> and highway=greenway seems to not be a real improvement and its meaning is 
> utterly unclear for me

“Greenway” [1] was a term unknown to me too until I started reading a bit about 
voie verte [2] in France. I probably would have considered them to be “rail 
trails” [3] prior to reading about them.

But I am not wedded to a particular set of words for new highway values, just 
that we should consider the possibility of them and maybe have a discussion on 
what highway=* features seem to be hard for mappers to tag consistently. There 
are no via ferrata paths that I am aware of in my immediate area, but reading 
wikipedia about them I can see where that could be hard to map using our 
current tagging so that could certainly be one of the new highway values.

[1] https://en.wikipedia.org/wiki/Greenway_(landscape)
[2] https://fr.wikipedia.org/wiki/Voie_verte
[3] https://en.wikipedia.org/wiki/Rail_trail



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Help explain the difference between path and track

2020-06-10 Thread Tod Fitch


> On Jun 10, 2020, at 12:31 AM, Volker Schmidt  wrote:
> 
> Two points to get this thread back on track:
> 
> 1) The highway=track tag has always been wider than agriculture and forestry. 
> There is an often overlooked "etc." in the description on the wiki, and it 
> has been there from the very first version of 26 May 2008. (see also 
> Duck_tagging )
> 
> 2) "In my rendering of hiking maps I currently have to look at 13 tags and 
> their values to make a decision ..."
> "I think we need some more values for the highway tag..."
> These two statements together (made in the same message in this thread)  
> highlight the basic problem of this and other discussions:
> If we need to look at X tags and values now, adding new values only makes the 
> list longer - there's no way around this.

My hope would be that addition of more highway=* values that better match what 
people are trying to map would be a short term pain (data consumers need to add 
one more check) but long term benefit.

For example, as mappers discover they can map a voie verte in France or a 
“Rails to Trails” in the USA as highway=greenway and not as arbitrary choice of 
track, path, cycleway or bridle path differentiated by a bunch of 
foot=designated, bicycle=designated, etc. tags they are likely to migrate to 
the simpler tagging. At some time in the future data consumers could begin to 
be more restrictive on their logic.

Cheers,

Tod




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Help explain the difference between path and track

2020-06-10 Thread Tod Fitch


> On Jun 9, 2020, at 5:29 PM, Kevin Kenny  wrote:
> 
> 
> I don't use 'path'  very much except that JOSM wants to use it for
> 'combined foot- and cycleway'.  Using JOSM, I'll typically tag a way
> as a 'path' so that I get the dialog where I can quickly fill in
> surface, smoothness, maybe width and incline.  Then I retag using one
> of the 'footway', 'cycleway' or 'bridleway' presets depending on the
> largest creature that uses it - so I've recently tagged a few
> track-ish things around here as 'highway=bridleway surface=compacted
> smoothness=good bicycle=designated foot=designated width=3'  There's
> some evidence that motor vehicles use it occasionally, but only for
> official purposes.
> 

Precisely why I need to look at so many tags and tag values to decide if 
something is a “hiking trail” or not.

Also, I think, a good argument that the current tagging fails to cover this 
domain very well.




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Help explain the difference between path and track

2020-06-09 Thread Tod Fitch


> On Jun 9, 2020, at 2:22 PM, Mike Thompson  wrote:
> 
> On Tue, Jun 9, 2020 at 3:02 PM brad  > wrote:
> A track does have a different function, it can handle a 2 track vehicle, a 
> path can't.
> Yes, a "track" has a different function, its function is for agriculture or 
> forestry.
> 
> A wide path on the other hand has the same function as a narrow path.
> 
> 
> If functional is sacrosanct,  why do we have motorway?   A motorway could 
> just be a trunk or primary with extra tags denoting limited access.
> That is a good question.  But it was stated on this list just a couple of 
> weeks ago that the highway=* tag was a functional classification, "except for 
> motorway"
> 

In my rendering of hiking maps I currently have to look at 13 tags and their 
values to make a decision if a “path” or “footway” might be what I want to 
render. This is ridiculous. It is neither easy for the mapper nor the renderer.

On the motor vehicle side this would be the equivalent of saying all ways 
intended for cars should be mapped as highway=road and we can distinguish them 
by using surface, width, smoothness, maximum speed, etc.

I think we need some more values for the highway tag that would allow a mapper 
to easily tag:

1) A narrow rural trail where you probably want good footwear and are likely to 
take a small pack with water, snacks, etc.
2) A smooth hard surfaced walk, usually in or near urban/suburban areas) 
suitable for pushing a stroller.
3) A wide fairly smooth way (usually in or near urban/suburban areas) designed 
for getting exercise. Probably not paved, but with a natural appearing surface 
that is maintained to be fairly smooth.

In my part of the world many of those things are general purpose (mixed foot 
and bicycle use and often horses). Mappers end up using highway tag values of 
path, footway, track, and, rarely, cycleway or bridlepath. If we are lucky they 
might put a surface tag or some access tags on it. It is a mess. Hard for a 
beginning mapper to decide what tags to use. Hard for a data consumer to figure 
out what the mapper was trying to map.

The two major factions seem to be set in their ways: “It is only a track if it 
is used for agriculture or forestry” on one side. “It has the same physical 
characteristics as a track, so it is a track even if it is currently used for 
hiking, bicycling, riding horses, or by ATVs” on the other side.

That also spills into is it a track or a service (driveway)? Depends on if it 
goes to a barn or a house! But I can’t tell without trespassing, how can I map 
it?

First step, I think, is to be less pedantic about function on things that look 
exactly like a track. Mappers in all the areas I’ve looked at will tag a way 
that is unpaved and about the width of a four wheeled vehicle as a track 
regardless of current use. Maybe it is being used as a driveway. Maybe it is 
being used as a bicycling/hiking/equestrian trail. Maybe it accesses a field. 
Maybe it hasn’t been used for a while and just hasn’t decayed or been overgrown 
into nothing. Who knows? But it looks like a track. Saying that the way “isn’t 
for forestry or agricultural use” so it can’t be a track is worthless: Real 
world mappers have voted otherwise with their tagging.

Cheers!
Tod




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Adding man_made=spoil_heap to the Map Features page?

2020-06-03 Thread Tod Fitch

> On Jun 3, 2020, at 5:45 PM, Jarek Piórkowski  wrote:
> 
> On Wed, 3 Jun 2020 at 20:40, Mateusz Konieczny via Tagging
>  wrote:
> (about Map Features wiki page)
>> In its current state it is still barely usable.
> 
> Personally I've given up on the current Map Features page and would
> rather use the wiki search or taginfo search than wait for it to load
> and probably still not find what I'm actually looking for.
> 

+1

I can’t recall the last time I went to the map features page. Like Jarek, I 
just use the wiki search and/or taginfo.

Cheers!
Tod




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Adding man_made=spoil_heap to the Map Features page?

2020-06-03 Thread Tod Fitch


> On Jun 3, 2020, at 4:19 PM, Paul Allen  wrote:
> 
> On Wed, 3 Jun 2020 at 23:56, Joseph Eisenberg  > wrote:
> 
> The one issue is whether it is clearly different than landuse=landfill.
> 
> Different.
> 
> Spoil heaps are, as the Wikipedia article documents, heaps.  Tips.  Piles.
> Piles of non-degradable mining waste.  Rock.  Rubble.  You pile them
> up and that's how they remain (except in the case of disasters, such
> as Aberfan).
> 
> Landfills are (generally) holes in the ground that are filled in and often 
> act as
> bio-reactors to degrade organic material.
> 
> Not the same thing.  Usually.  At least not in the UK.
> 

Not the same thing in the US either.





signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

2020-06-02 Thread Tod Fitch

> On Jun 2, 2020, at 5:48 AM, Volker Schmidt  wrote:
> 
> 
> 
> On Tue, 2 Jun 2020 at 09:04, Daniel Westergren  > wrote:
> I think the reason that this is so messed up because of the desire to tag 
> according to function.   A trail/path can have many users/functions, but it's 
> still a dirt path.
> 
> Right. But is there another way? Can we tag dirt paths/wilderness 
> paths/forest paths/mountain paths with another main tag?
> No you cannot inroduce another main tag, because of the existing stock of 
> "path" 8.7 million and "track".(18.7 million). This would only add additional 
> confusion with mappers and an enormous burden on renderers and routers
> Can we somehow "enforce" additional tags for physical characteristics that 
> will tell what this path|footway|cycleway actually looks like?
> We have no way to "enforce" anything in OSM. But, as we do have the necessary 
> tags (maybe to many different ones, but they all are in use.and we need to 
> reamin backaward compatible in view of the enourmous numbers). What we can do 
> and need to do is to improve the description of the various existing tagging 
> options in the wiki (without touching their definition)

My translation of these two statements combined is roughy: “We can’t change any 
tagging”. I don’t find that helpful.

> I'm OK with taking this off this list & I can add my comments to the google 
> docs doc.
> 
> Ok, I'll email those who have expressed interest in following or 
> participating in the discussion. Suggestions and comments can also be done in 
> the Google Doc.
> 
> As said before I would prefer that his discussion remain on one of the tools 
> of the OSM community, mainly for documenting the discussion.

I agree with you on this. Especially as I’ve gone to fairly extreme measures to 
reduce my exposure to Google.



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

2020-05-30 Thread Tod Fitch


> On May 30, 2020, at 4:20 PM, Graeme Fitzpatrick  wrote:
> 
> Something else that I've just thought about & not sure whether it would need 
> to be mentioned - possibility of encountering dangerous wildlife?
> 
> Yes, there are 1000 things in the Australian bush that'll kill you :-), but 
> none of them will actually eat you! (not even Drop Bears! 
> https://australianmuseum.net.au/learn/animals/mammals/drop-bear/ 
>  :-)) Same 
> applies to (virtually?) all of Western Europe, but how about North America, 
> Africa, Asia & so on? Do we have / need a way of tagging that bears (or 
> whatever) may be encountered while walking in this area?
> 

Just about every trail head in my local area has warning signs about 
rattlesnakes and mountain lions [1]. One of the local county operated 
wilderness parks was closed this week because of mountain lion sightings.

But for the moment my goal is not tagging for dangerous wildlife but rather how 
can a mapper simply indicate that the way is a non-urban hiking (and possibly 
mountain biking and equestrian) trail.

I’ve spent too much time recently trying to figure out how to better determine 
whether the ways I am rendering should be shown as an urban/suburban walkway 
versus a non-urban hiking trail (intentionally not using “footway” and “path” 
as words for this). For straight rendering it doesn’t seem to be too big a deal 
if I get it slightly wrong, the map just looks uglier than I’d like.

But I am trying to display accurate mileage numbers on hiking trails and that 
means combining ways that are, for my purposes, functionally equivalent 
descriptions of a hiking trail: I really don’t want the distance between 
changes in width or surface or even bridges, so I need to “heal” those edges in 
my graph based on a simple hiking_trail=yes|no check. My 
Postgresql/PostGIS/osmfilter/osm2pgrouting skills aren’t great so I am probably 
missing something. But all the ways I’ve come with to munge the various 
surface/sac_scale/width/trail_visibility/width/etc. combinations into a simple 
“this is a hiking trail or not” are neither accurate nor fast to run on tagging 
I am finding in the field. There just has to be a better way to map these 
things!

Cheers!
Tod

[1] https://en.wikipedia.org/wiki/Cougar



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing, importance of trails in OSM

2020-05-30 Thread Tod Fitch


> On May 30, 2020, at 7:57 AM, Rob Savoye  wrote:
> 
>> Date: Sat, 30 May 2020 15:46:31 +0200
>> From: Daniel Westergren 
> 
>> *An additional issue:*
>> 6. sac_scale is currently the only tag (possibly together with mtb:scale)
>> to denote the difficulty of a hiking trail (that is, the way, not the
>> route). But it's very geared towards alpine trails and there is not enough
>> nuance in the lowest levels. Could the Yosemite Decimal System (YDS),
>> Australian Walking Track Grading System and others complement or expand on
>> sac_scale?
> 
>  As a climber, I don't think we'd want to apply YDS to hiking trails.
> To me, YDS should only used for technical routes requiring equipment
> (usually). I think "mountain_hiking" is what you can do without
> equipment, even if occasionally using your hands for balance.
> "alpine_hiking" is when I'm up near or above treeline, often in snow or
> large scree fields. A fuzzier category are climber access trails that
> most hikers shouldn't use. We have many of those around here.

As a Sierra Club member in Southern California (where the YDS originated long 
before my time), a hiker and a former climber I must mention that 1, 2, 3, and 
4 on the YDS are basically levels of difficulty in hiking. Climbers really only 
work with 5 and its various subdivisions. Ruling out the whole scale simply 
because one level of it is dedicated to climbing is a bit much.

OTOH, the Australians have a bush walking scale that does not, from what I’ve 
seen, include levels for climbing so that might be choice that does not 
automatically connote a different outdoor activity.

> 
>> Would this be a fair summary? What have I missed? Who is interested in
>> continuing this work in a smaller group? Or should we continue to spam this
>> mailing list?
> 
>  I'd be interested in a working group on this, as my map data and maps
> are used by multiple rural fire departments and SAR groups. You wouldn't
> be surprised by how many people we rescue that misjudged the trail
> difficulty... For us though, looking at the subtags helps determine the
> type of response and equipment. sac_scale is a bit open to
> interpretation based on one's experience, but better than nothing.
> 



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-30 Thread Tod Fitch

> On May 30, 2020, at 6:46 AM, Daniel Westergren  wrote:
> 
> Ok, I hope this will be my final post in this long thread. I will try to 
> summarize what I understand from the discussion as the main issuesa and what 
> needs to be addressed to make it easier for mappers and data consumers.
> 
> I would also suggest that instead of filling the inboxes of each and everyone 
> on this tagging list, we create a smaller "working group" that can come up 
> with a concrete suggestion to solve the major issues. What do you think about 
> that? Who would like to work with such a proposal?
> 
> Major issues, as I understand it:
> How do we treat highway=path and highway=footway that has no additional tags?
> Is highway=path a type of way (wilderness trail or whatever term we use) or a 
> way for non-specified/mixed use? That is, are we talking about the physical 
> characteristics of a way or its function? Btw, this would likely mean that 99 
> % of path/footway/cycleway in Sweden should be path, if the latter 
> interpretation is to be used.
> #1 & #2 makes it really difficult for data consumers, they have to depend on 
> (often non-existing) subtags.
> Additional tags must be used to denote accessibility for pedestrians/cyclists 
> of ordinary ability, that is "this is NOT a hiking trail/wilderness trail!. 
> But which would these tags be?
> Additional tags must also be used to tell !this IS a wilderness trail! (or 
> whatever term we use).
> 
> Subtags
> To specify the physical characteristics of a highway=path or highway=footway 
> we have a multitude of tags, with no particular recommendation about which 
> ones must or should be used (see #4 & #5 above): surface, smoothness, width, 
> trail_visibility, sac_scale, mtb:scale and possibly incline.
> 
> 
> An additional issue:
> 6. sac_scale is currently the only tag (possibly together with mtb:scale) to 
> denote the difficulty of a hiking trail (that is, the way, not the route). 
> But it's very geared towards alpine trails and there is not enough nuance in 
> the lowest levels. Could the Yosemite Decimal System (YDS), Australian 
> Walking Track Grading System and others complement or expand on sac_scale?
> 
> 
> What needs to be done?
> We have to rely on subtags...
> We need to decide what subtags to be used to tell this is an accessible path 
> or this is a wilderness trail.
> We need a way to better nuance hiking trails.
> Documention needs to be much more clear and specific, in order for mappers 
> and data consumers to really know when different kinds of highway tags should 
> be used and what subtags must/should be used.
> Editors need to be improved to encourage tagging that will make it easier for 
> data consumers.
> Better default rendering of non-urban paths, to encourage the use of 
> mentioned subtags.
> 
> Would this be a fair summary? What have I missed? Who is interestet in 
> continuing this work in a smaller group? Or should we continue to spam this 
> mailing list?
> 
> /Daniel
> 

This seems to be an accurate summary of the discussion so far.

As a hiker who both maps and renders maps for hiking, I am interested in 
getting this area of tagging improved and would be willing to exchange emails 
among a smaller group.

Thank you for the summary!

Tod




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-27 Thread Tod Fitch


> On May 27, 2020, at 6:42 AM, Volker Schmidt  wrote:
> This does not describe the situation
> highway=footway is "urban", implies foot=designated, usage can be expanded 
> with tags like bicycle=yes|permisive||designated to describe mid-use ways
> 
> highway=cycleway implies bicycle=designated, usage can be widened with tags 
> like foot=yes|permissive|designated to describe mixed-use ways (this
> 
> path is being used for two completly different  things:
> (a) a "hiking" path, mostly in non-urban situations, including mountain hiking
> (b) with the additional tagging foot=designated plus bicycle=designated plus 
> segregated=yes|no as a mixed use foot-cycle-way
> 

And there is (c) a non-urban trail with legal access for bicycles but in 
practice only usable with a mountain bike but lacking a MTB scale tag as the 
hiker, like me, who mapped it has no clue what MTB scale to put on it.




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-27 Thread Tod Fitch


> On May 26, 2020, at 9:18 PM, Warin <61sundow...@gmail.com> wrote:
> 
> For me highway=footway and highway=path without any other tags are the same 
> thing. Introducing yet another tag for similar paths/footways may lead to 
> more confused tagging of these things.
> I think the use of sub tags would lead to cleaner tagging.
> 
Therein lies the issue.

For me footway [1] and path [2] are distinctly different. The photos are from a 
blog post of mine regarding rendering of trail distances [3].

Cheers!
Tod

[1] 
https://retiredtechie.fitchfamily.org/wp-content/uploads/2020/02/IMG_0420-768x1024.jpg
[2] 
https://retiredtechie.fitchfamily.org/wp-content/uploads/2020/02/IMG_0425-768x1024.jpg
[3] 
https://retiredtechie.fitchfamily.org/2020/02/17/distance-between-trail-junctions/


signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-26 Thread Tod Fitch


> On May 26, 2020, at 12:37 PM, Mateusz Konieczny via Tagging 
>  wrote:
> 
> May 26, 2020, 20:50 by bradha...@fastmail.com:
> Yes!  We have an overload of tags for trails, many poorly defined, many 
> rarely used.   KISS -  keep it simple stupid.  I think it would help if we 
> narrowed the focus for cycleway and footway.
> How about this, as default:
> cycleway - paved path that a typical tourist or casual rider can ride on a 
> road bike.
> footway - smooth path, very firm surface or paved that is good for someone 
> with less than average ability.
> bridleway- for exclusive (or almost exclusive ) horse trails
> path - for everything else.   Implies not paved.  Routers should not route 
> road bikers here.
> 
> The difficulty for bikes (& maybe hiking) can be simple green/blue/black 
> similar to what is used on US bike trails, and ski areas.
> 
> The tricky part is that such redefining is not solving problem of already 
> collected data.
> 
> You need to resurvey all already collected data and mark it as reviewed (by 
> adding some tag,
> for example reviewed_to_new_path_scheme=yes or explicit surface value).
> 
> Overall I see no benefit over explicit tagging of a surface value.

Not necessarily a tricky part: First, this is more of a clarification than a 
redefinition. Second, there is no need to immediately retag everything as the 
situation before clarification of these meanings isn’t really any different 
that it would be after (renderers will have to rely on the current jumbled mess 
of modifier tags for a while).

But agreeing on these definitions would mean in the medium term renderers and 
routers could clean up their logic which would the point to ways that have 
tagging that needs review (when a trail ceases to be shown or routed over it is 
likely someone will notice and fix the tagging).

In my part of the world the interpretation of the existing tags pretty much 
matches the above so little, if any, retagging of hiking paths or city park 
walkways would be needed in my area.

Cheers!
Tod



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-23 Thread Tod Fitch
Being a Sierra Club member in California, it seems to me that the Yosemite 
Decimal System (YDS) [1], originally created by the Sierra Club is made to 
order for this. Classes 1 through 3 are basically hiking, 4 is transitional and 
5 is technical climbing. My understanding having been exposed to this for 
decades is slightly different from that in Wikipedia mine are:

1 - No special gear or equipment needed. If not the equivalent to a city 
sideway in difficulty, it is very close.
2 - Uneven, loose or other surfaces where good hiking shoes are advisable.
3 - You may occasionally need to use a hand to steady yourself in difficult 
areas.
4 - Climbing or scrambling but low exposure and/or low risk of injury such that 
safety equipment like ropes are not required.
5 - Climbing requiring technical skills and equipment.

Class 5 was divided into 10 levels (thus a “decimal” system) but has been 
expanded to well more than 10 sub levels over the years as techniques and gear 
have evolved. But that is off topic when dealing with hiking trails. I think 
for most of what I’d map as a trail we are dealing with classes 1 through 3. In 
Kevin’s example system, the trail with a toddler would be a 1 and the other two 
examples would be either 3 or 4.

I only see one mention of YDS in the wiki [2] and only a few uses that seem to 
use it in TagInfo [3] likely because the various 5 class sub-levels are 
associated with climbing [4][5] and many people seem to be unaware of classes 1 
through 4.

Cheers,
Tod

[1] https://en.wikipedia.org/wiki/Yosemite_Decimal_System
[2] https://wiki.openstreetmap.org/wiki/Climbing#Grading
[3] https://taginfo.openstreetmap.org/search?q=yds#keys
[4] https://taginfo.openstreetmap.org/keys/climbing%3Agrade%3Ayds_class
[5] https://taginfo.openstreetmap.org/keys/climbing%3Ayds_class

> On May 23, 2020, at 4:59 PM, Kevin Kenny  wrote:
> 
> On Sat, May 23, 2020 at 5:42 PM John Willis via Tagging
>  wrote:
>> 
>> =path is such a horrible catch-all tag and one that is extremely entrenched 
>> - I am surprised no one has implemented a path=trail subtag, similar to 
>> sidewalk, so we can separate all the hiking trails and other “hiking” paths, 
>> and then apply different hiking limitations you wouldn’t expect to find on a 
>> sidewalk or playground way.
>> 
>> Mixing trails and sidewalks in the path key is as horrible as mixing up 
>> runways and train tracks in a “highway=not_car” way.
> 
> Yeah. But it's so entrenched that trolltags are probably the only way
> out of the mess. And sac_scale is _surely_ not the right trolltag! The
> problem with sac_scale is that it's an impossible scale. I'm told that
> https://youtu.be/VKsD1qBpVYc?t=533 is still only a 2 out of 6 on that
> scale, and that https://www.youtube.com/watch?v=3y5_lbQZJwQ is still
> only a 3. Note that one misstep on either of those trails can easily
> mean death.
> 
> Confusion on what to expect from wilderness trails abounds. Hardly a
> year goes by without someone from New York City driving up to do one
> of the Catskill or Adirondack trails, expecting something like a
> developed trail in a suburban setting, and winding up dead, from
> either a fall or hypothermia.
> 
> This is a `highway=footway surface=ground`:
> https://www.flickr.com/photos/ke9tv/34048181 - a toddler can do it
> with ease.
> 
> So is this: https://www.flickr.com/photos/65793193@N00/3183604743/ -
> requires good physical condition, a head for heights, and some
> technical hiking skills. Shorter hikers may be at a disadvantage.
> 
> And this: 
> http://3.bp.blogspot.com/-oOi7vvpUt0Q/VJnktGwmMDI/BoY/xYpcKlxPPqI/s1600/DSC_3880.JPG
> - requires winter mountaineering skills and a modicum of technical
> equipment (at least snowshoes or skis, ski poles, crampons, ice axe).
> 
> 
> 
> --
> 73 de ke9tv/2, Kevin
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Section numbers in hiking routes

2020-05-23 Thread Tod Fitch
I was under the impression that the consensus was that a route name should be 
in a route relation that holds all the segments and that the segment names, if 
different from the route name, were on the segment.

Has that consensus changed or has my impression been wrong?

Cheers!
Tod

> On May 23, 2020, at 9:41 AM, Peter Elderson  wrote:
> 
> Hold on to your hat In the name tag I will store...The Name Of The Route!
> 
> Op za 23 mei 2020 om 18:18 schreef Jo  >:
> In the end, what will be left in the name tag exactly?
> 
> Polyglot
> 
> On Sat, May 23, 2020 at 5:53 PM Peter Elderson  > wrote:
> I am trying to improve on the name-tag mess in the many hiking/foot routes in 
> Nederland. All kinds of information is packed in those names. I am not doing 
> any cleaning (yet) until all this information can be stored in proper tags 
> and is handled or scheduled by significant renderers/data users/tools. There 
> must be reasons for this (ab)use, because it is done all over the globe.
> 
> It's very common to store - and sometimes  in the name tag. 
> That's an easy one: we have from=*, via=*, to=*.
> 
> Sometimes a complete description, a comment or a note (.e.g. about a 
> temporary detour) is added to the name. Easy: we have description=, note=*, 
> comment=*.
> 
> A ref in the name: store in ref=*.
> 
> Another item is section number. This is often used when the route is split in 
> sections, often according to the sectioning given by the operator/website. So 
> firstly it's a sort of reference, secondly its an ordering and sorting 
> mechanism.
> Sometimes sections have their own name. I see that a lot in international 
> (super)routes.
> 
> Any ideas how to do this without (ab)using the name tag? Is there a proper 
> tag that springs to mind, or should we invent one?
> 
> Peter Elderson
> ___
> 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 mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

2020-05-22 Thread Tod Fitch

> On May 22, 2020, at 5:24 AM, Ture Pålsson via Tagging 
>  wrote:
> 
> 
> 
>> 22 maj 2020 kl. 12:52 skrev Daniel Westergren > >:
>> 
>> […] Then there is width, which is only tagged on 3.5% of highway=path. I was 
>> discussing width of paths in another forum. For a forest path, would you say 
>> width is measured as the actual tread on the ground only? For a runner and 
>> MTB cyclist that would make sense, but for a hiker with a big backpack a 
>> width of 0.3 m may mean they think it's not possible to walk there.
> 
> We need loading_gauge=* tag. :-)
> 
> (https://en.wikipedia.org/wiki/Loading_gauge 
> )
> 

Width is, at least in my area, going to be a hard issue.

For background, I have been volunteering on trail maintenance teams in a near 
by designated wilderness area where the vegetation is largely chaparral (scrub) 
and this has shaped my opinion.

Many of our trails were originally ranch access roads (highway=track) and in 
some short sections here and there where things were scraped to bedrock the 
trails remains that wide, maybe 3m. However the overwhelming majority of the 
trail mileage have been overgrown to the point of being impassible on foot 
without constant maintenance. Our standard for maintaining a section of trail 
is that the tread (where your foot meets the ground) should be a minimum of 
0.5m and that the width at shoulder level should be 2m. In the occasional areas 
where we have trees, etc., we strive for about 3m vertical clearance so that an 
equestrian can get through. Being a designated wilderness, no power tools or 
wheeled vehicles are allowed so access is by hiking and work is performed with 
hand tools.

If you look to motor vehicle roads, width is of the traveled way, not of the 
right of way nor of the way cleared of vegetation (i.e. side drainage or 
shoulders, etc.). From that point of view, a trail width should likely be the 
tread width. But as noted by Daniel, a hiker with a big pack might be more 
interested in the width at pack/shoulder level (“loading gauge”).

The issues in mapping trail width in my area include:
Chaparral is fast growing. So that 0.5m/2m width trail we fixed today will 
shrink each rainy season and without maintenance is likely to become impassible 
in maybe 5 years time.
Trail maintenance teams are lucky to be able to clean up 2km of trail in a 
session. So it takes multiple sessions to keep a typical trail maintained and 
for any given trail those are sessions occur over a number of years (we target 
areas where things are worst).
The result is that trail width is highly variable both over the length of a 
trail and over time. If mapped in high detail, the width you map this hiking 
season will be wrong next year. Heck, it might even be wrong next month 
depending on what month of the year your did your survey.

For what it is worth, I don’t usually tag the width of the trails. Mostly for 
the above reasons: To do it properly I’d have to be taking very detailed field 
notes and have to re-survey each trail at least once a year. And even if I did 
that, when I look at the typical data consumer I see that they usually have 
stale OSM data so any attempt to keep OSM up to the day correct on field 
conditions wouldn’t be very useful anyway.


Cheers!
Tod




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Dog hazard

2020-05-12 Thread Tod Fitch
dog=yes|no|leashed already exists for a totally different semantic (letting dog 
owners know if their pet is allowed).

If this goes forward I would prefer reversing thing and make it hazard=dog. 
That would also allow other types of hazards to be mapped.

Checking taginfo it seems hazard=* [1] is in use. Why not go with it?

[1] https://taginfo.openstreetmap.org/keys/hazard
--
Sent from my phone, please forgive my brevity.

> On Tuesday, May 12, 2020 at 3:16 PM, Ty S  (mailto:mensaty2...@outlook.com)> wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Dog_hazard
>
> Dangerous area with dogs.
>
> Please discuss on the page. I will respond to emails, but I rarely check, and 
> it may take a bit to get back with you.
> -- Floridaeditor
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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


Re: [Tagging] highway=service, service=driveway vs highway=track

2020-04-30 Thread Tod Fitch


> On Apr 30, 2020, at 11:25 AM, Paul Allen  wrote:
> 
> On Thu, 30 Apr 2020 at 19:17, Joseph Eisenberg  > wrote:
> 
> This mis-tagging is probably common because OpenStreetMap-Carto and some 
> other common map styles do not distinguish between unpaved and paved service 
> roads. (We're working on it: 
> https://github.com/gravitystorm/openstreetmap-carto/pull/3399 
> )
> 
> Or it might be common because, from aerial imagery, it's clearly an unpaved
> track.  Or possibly added as a track from the NPE and never changed when
> somebody later added buildings to the map.
> 

In the rural southern Arizona community where my parents retired the only real 
way to tell the difference between a track and a service+driveway+upaved is 
whether you end up at a house in a reasonable amount of distance.

I forgot how I mapped those, so I just went back and looked at the area. 
Apparently when I mapped it 4 or 5 years ago I decided on service+driveway.

But if you aren’t looking at it on the ground it would be very difficult to 
tell which would be correct. Even in person it is often quite difficult.

Cheers!
Tod





signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Updating definition and description of place=square

2020-03-27 Thread Tod Fitch


> On Mar 27, 2020, at 5:29 PM, Clifford Snow  wrote:
> 
> 
> 
> On Fri, Mar 27, 2020 at 5:23 PM Paul Allen  > wrote:
> 
> I can think of one US city square which has "square" in the name
> (not square shaped, though) that is rather well-known.  If you
> can't think of it the ball will drop eventually, at midnight on Dec 31st.
> 
> The University of Washington has "Red Square" tagged as a place=square 
> https://www.openstreetmap.org/#map=19/47.65612/-122.30974 
> 
> Madison, WI has a square tagged as a park. 
> https://www.openstreetmap.org/way/415148381 
> 
> Atenas, CR has a square, as many Costa Rica cities, also tagged as a park. 
> https://www.openstreetmap.org/#map=19/9.97911/-84.37985 
> 
> 

Looks like Union Square in San Francisco is tagged as both leisure=park and 
place=square https://www.openstreetmap.org/way/25278818




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] What language is the name tag value? Was: Which languages are admissible for name:xx tags?

2020-03-26 Thread Tod Fitch
I was blissfully unaware of the issues involved in creating a bilingual map 
(dual labeled in the local language and in my language) until I actually tried 
to create one.

Most objects in OSM do not have name: tags for non-local languages and it 
is unreasonable to expect that every named village, town, river and stream in 
some far off land have a name: value for your language. Especially since 
the vast majority of the values would be transliterations which we would like 
to avoid [1].

In my case I thought it would be useful to have a printed map with features 
showing the local name in the local language and script along with an English 
version of the name. If the name:en existed use it. If not then use an 
automatically generated phonetic transliteration. The problem I ran into was 
you need to know the language used in the name tag [2] to know what rules to 
use for transliteration.

As I understand it, there are several ways to determine the language and there 
has been at least a couple of proposals or tagging list discussions on this 
topic but with no consensus. The ones that come to mind for me are:

1. The current situation where the there is no formal method. If one follows 
the wiki recommendation [3] that the name value be duplicated into a name: 
tag then the language can be determined in many cases. Unfortunately this fall 
apart if the same spelling and alphabet are used with different pronunciations. 
An example that comes to mind would be for the city of Paris where there are 
several name: tags that exactly match the name value. Which one should be 
picked? The pronunciations are different in different languages, if you are 
going to attempt automatic transliteration you would like to correctly pick 
French as the language to transliterate from. So the current situation is not 
ideal: This wiki recommendation is seldom followed. If it is then some mappers 
are going to decide that the “duplicates” are undesirable and remove them. And, 
if followed there are fairly common cases where it still is not possible to 
determine the language.

2. Create a scheme where a default language can be set on boundaries as has 
been suggested by Joseph Eisenberg [4]. This has the advantage that relatively 
few objects need to be tagged, for example it might be possible that only one 
tag could be used to cover the continental United States. But it falls apart 
for features that are on the boundary between multiple language areas 
(Mediterranean Sea for example) and for areas that are multilingual (Wales for 
example). In addition, it seems that any type of “we should add a default for 
an administrative area” proposal that has come up here has been rejected or 
“bike shedded” into oblivion.

3. Drop the name tag altogether and add a name formatting tag [5]. As I 
understand it, the formatting specification would be used to take one or more 
name: values and specify how they should be combined to create a name for 
display purposes. Migrating to this scheme could be hard and may only be 
possible if a default name format could be specified for an area as in the 
default language scheme in 2 above. Even if a default mechanism could be agreed 
to, the magnitude of changing all the name=* to name:=* for even a relative 
small monolingual area would be a big task if automated changes are not used. 
Finally, it does not resolve the issue of ambiguity in the language used.

4. Create a new tag explicitly specifying the language used in the name tag. 
This has the same disadvantage as the current wiki recommendation for 
duplicating the name value into a name: value in that it has to be done on 
each object. But it does have the advantage that it there is no ambiguity in 
showing the language of the name tag value and it can be rolled out a little at 
a time.

5. ??? There are probably other schemes that have been proposed that I haven’t 
noticed.

Thoughts?

—Tod

[1] https://wiki.openstreetmap.org/wiki/Names#Avoid_transliteration
[2] https://wiki.openstreetmap.org/wiki/Multilingual_names#Issues
[3] 
https://wiki.openstreetmap.org/wiki/Names#Repeating_name_with_language_specific_tag
[4] 
https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
[5] 
http://blog.imagico.de/you-name-it-on-representing-geographic-diversity-in-names/


> On Mar 25, 2020, at 11:25 PM, Joseph Eisenberg  
> wrote:
> 
> That's why I previously proposed a tag like default_language=* which
> could be added to features and boundaries. See
> https://wiki.openstreetmap.org/wiki/Proposed_features/Default_Language_Format
> 
> Unfortunately that was not approved. It's a confusing topic, many of
> the people who opposed the proposal seemed to think it would do
> something else.
> 
> -- Joseph Eisenberg
> 



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Which languages are admissible for name:xx tags?

2020-03-25 Thread Tod Fitch


> On Mar 25, 2020, at 8:05 PM, Warin <61sundow...@gmail.com> wrote:
> 
> I would think that a default should be used - where the required language 
> name is not within OSM then the local language name should be used.
> This should stop the copying of the local language name into other languages 
> and reduce data bloat.
> Only when the name is different from the local name should another name:xx be 
> used, particularly where a different alphabet/symbols are used.
> 
> However, a sample case?
> The name Uluru is Yankunytjatjara, but probably shared with 5 other local 
> languages. So those language tags would all be the same value.
> The 'old' name is Ayres Rock, English language.
> There are many people that come there from overseas who speak other 
> languages, having their name in those languages may help them.
> 
> Common languages heard around Ayres Rock or Uluru are English, German, 
> Japanese, Chinese, French and some dialect of the Western Desert Language.
> 
> The peak is node 2251425855,
> the rock itself is way 32639987,
> the park is relation 8314513.
> 
> Some tags used at present are;
> 
> alt_name  Ayers Rock
> alt_name:cs   Ayersova skála
> alt_name:en   Ayers Rock
> name  Uluṟu
> name:cs   Uluru
> name:en   Uluru
> name:pjt  Uluṟu
> name:ru   Улуру
> 
> I would drop the tags name:en, name:cs, alt_name:en as they duplicate the 
> name/alt_name.
> I would keep the tags name:ru and alt_name:cs as they are different from the 
> 'normal' value.
> 
> I would also keep name:pjt as that is the source of the name and different 
> from the official language of the Country.
> 
Let's assume that I want to make a map for use by native speakers not covered 
by the name:* tags given. In your example case, I’ll pick Japanese as I don’t 
see a language code for that in your example. I would like to automatically 
transliterate the name value into kana (I believe that is the Japanese phonetic 
alphabet but I am no expert).

How do I determine the language of the glyphs “Uluṟu” so I know how to 
transliterate it?

If the current name:pjt=Uluṟu is retained in addition to the name=Uluṟu tag, I 
could determine the name is in the pjt language (the values of the name and 
name:pjt tags are the same) and then, with appropriate external references 
about the phonetics that language, automatically transliterate it for display 
on my map.

If you remove the name:pjt tag because it is redundant (i.e. the same value as 
the name tag) then there is no way for me to algorithmically detect the 
language the name is in. It makes dealing with internationalization of the 
final product much harder.

In your example above, the name:en and name:pjt values appear to be different 
“Uluru” vs “Uluṟu” (I have no idea how an “r” with an under bar is supposed to 
change the pronunciation). So why would you remove the name:en value?

Cheers!
Tod




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Which languages are admissible for name:xx tags?

2020-03-25 Thread Tod Fitch


> On Mar 25, 2020, at 3:56 PM, Paul Allen  wrote:
> 
> On Wed, 25 Mar 2020 at 22:25, Graeme Fitzpatrick  > wrote:
> 
> Is there any reason to actually specify name:en= when English is the 
> Australian language?
> 
> It's not the language of all Australians.  Ayers Rock is now Uluru. So it may 
> be
> sensible, in some cases, to add name:en to allow for future such changes.  I
> probably wouldn't bother because local mappers ought to have an idea if the
> name is English or not.  However, the wiki suggest it's not only permissible,
> it's also desirable: 
> https://wiki.openstreetmap.org/wiki/Names#Repeating_name_with_language_specific_tag
>  
> 
> 
> & how about name:international?
> 
> The wiki doesn't seem to have that, but does have int_name.  Which it doesn't
> explain very clearly but seems to be for cases like IATA airport names.
> 

OSM doesn’t have a way to specify the language used for the name tag
value. If I recall correctly, there was some discussion about how to
do this by setting defaults for administrative areas or some other
bounding polygon a while back but it went nowhere. Part of the issue
is that it is a hard problem once you start considering features
that are on the border of multiple language areas or for any names
in areas that are multilingual. Another suggestion was to create a
new tag that would specify the language of the name tag value thus
providing the missing metadata. That was not received well either.

I attempted to create a multi-lingual map recently and came to the
conclusion that the suggestion in the wiki to repeat the name=* with
name:=* was the only workable way we have at the moment for a
data consumer to determine what the language used in the name value
was.

Near as I can tell, without this there is no worldwide way to
determine the language of the name tag. When I looked at how the
German map decided to transliterate names I found that they had to
resort to shape definitions embedded in the libraries. Same for the
bilingual Welsh/English map, there is a non-OSM shape definition
embedded in the renderer to help it decide what language is likely
the default for the name tag value.

Duplicating the value into a name: tag value at least gives a
data consumer a chance to decide how to process the name tag. For
monolingual areas this may seem wasteful but we don’t really have
any other accepted way of doing this at the moment.

Cheers!
Tod



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] key damage and HOT

2020-02-07 Thread Tod Fitch


> On Feb 6, 2020, at 10:35 PM, Warin <61sundow...@gmail.com> wrote:
> 
> On 7/2/20 3:47 pm, Graeme Fitzpatrick wrote:
>> 
>> 
>> 
>> On Fri, 7 Feb 2020 at 14:30, Warin <61sundow...@gmail.com 
>> > wrote:
>> Let say a hospital has collapsed.
>> 
>> The crisis mapping page I linked to would have you add the tag 
>> damaged=collapsed to the amenity=hospital.
>> 
>> So the render would render the hospital the same as a fully functional 
>> hospital. That is certainly not want I'd want.
>> 
>> 
>> 
>> Better if life cycle things were rendered .. but different from fully 
>> functional things.
>> 
>> 
>> How about rendering a nice, big red X overlaying the outline of the building 
>> when it's marked as disused! :-)
> 
> Not only buildings.. paths, roads, train stations/tracks shops,  etc. And not 
> only disused, abandoned, razed, etc...
> 
> Rendering is not easy.
> 

+1

Based on the little rendering that I’ve been doing, it seems to me that each 
and every feature may require different treatment when handling lifecycle 
tagging. I handle lifecycle tagging on buildings as there are a number of them 
along some of the trails I hike and they are distinct landmarks so I’d like 
them to be on my hiking focused maps. But my treatment of lifecycle tagging on 
buildings would not be suitable for rendering a ruined railway or highway 
bridge. I’ve yet to hike (and map) a trail that took me within sight of a 
ruined bridge so I haven’t thought about how it could be rendered in a manner 
appropriate to my general map style.

I think a strong argument can be made that the style used to generate the 
“standard” map at https://www.openstreetmap.org/ should ignore ruins:* and, by 
extension, objects that also have “ruins=yes” tags. Though maybe it ought to 
treat disused:* and maybe abandoned:* as null prefixes (i.e. render the same as 
the equivalent *). But for maps where the state of a building or other feature 
is more important, like rendering for HOT, some effort should be made to 
support lifecycle prefixes on as many types of objects as possible.

Cheers,
Tod




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?

2020-01-27 Thread Tod Fitch
Grabbing some random images off the Internet, here are some highway=* and how 
I’d tag them:

highway=path [1]
This may or may not allow horses or bicycles depends on local signage and 
regulations.

highway=footway [2]
This may or may not allow bicycles, depends on local signage. My decision point 
between path and footway is if a wheelchair or baby stroller could be easily 
pushed along the way.

highway=cycleway [3]
This may or may not allow foot traffic (usually allowed but maybe not if there 
is a parallel footway).

Maybe it is just me, but the character of these are quite different to me. 
Major point being a path is not a footway and is not likely to be found in an 
urban or suburban environment in my part of the world.

If one were to say they are all “paths” and they are distinguished by things 
like surface, width, designated or allow modes of transportation then we could 
also dispense with motorway, trunk, primary, secondary, etc. highways and 
simply distinguish them by things like surface, width, direction of travel, 
allowed modes of transportation, maximum speeds, etc. too. But having values of 
footway, path, cycleway and bridal way allow a short hand that allows the map 
users (and renderers) to use a set of assumptions about the way. And it allows 
mappers to quickly categorize the way. I personally would find it tedious to 
the point of probably not mapping if I had to estimate surface smoothness and 
width (both of which can vary wildly) along the length of a hiking trail to 
indicate this was a “path” rather than a “footway”.

Cheers,
Tod

[1] 
https://www.christopherplace.com/wp-content/uploads/2015/06/smoky-mountain-hiking-trails-romantic-.jpg
[2] 
https://houstonconcreteraising.com/wp-content/uploads/2017/12/GettyImages-157284009.jpg
[3] 
https://www.gannett-cdn.com/-mm-/085c322bafe51f2640815fb843bd5dafc8d72095/c=36-0-623-440=x404=534x401/local/-/media/2016/07/27/Milwaukee/mjs-hikebike23_-nws_-sears_b.jpg



> On Jan 27, 2020, at 9:27 AM, Martin Koppenhoefer  
> wrote:
> 
> Am Mo., 27. Jan. 2020 um 16:37 Uhr schrieb Jmapb  >:
> And also editing the
> highway=path page, which currently says it's not for use in urban
> situations.
> 
> 
> 
> this seems very strange and is likely the result of fiddling. In the areas I 
> am aware of, path is the standard way to map mixed mode ways regardless of 
> context (urban or not).
> 
> Cheers,
> Martin
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] tagging historic ruins

2020-01-05 Thread Tod Fitch
The name value almost certainly should not be “Indian Ruin”. If “Indian Ruin” 
is used for a value at all it should be in the description tag. Probably the 
more politically correct nowadays might be “Native American ruins”.

Most of the larger sites have official names. “Montezuma Castle National 
Monument”, “Casa Grande Ruins National Monument”, “Tuzigoot National Monument”, 
“Tonto National Monument”, “Walnut Canyon National Monument”, “Palatki Heritage 
Site” and “Canyon de Chelly National Monument” in Arizona spring to mind. 
Within those sites the there may be individual buildings/groups of buildings 
that have names as well but those often seem to be descriptive (“Big House” or 
“South Buildings”).

I am not as familiar with sites outside of Arizona but suspect the same is true 
of those in New Mexico, Colorado, Utah, etc.

One trouble with names it that the people who lived in those areas moved out 
long before the advent of written documentation so we don’t know what they 
called the places. All the names are from later peoples (different native 
American tribes moving in, Spanish or Anglo). So I think the official names, 
probably found in the GNIS database is the best you are going to do.

Regarding historic:civilization tag using “Ancestral Pueblo people” vs 
“Anazazi”, I think I’d go with “Ancestral Pueblo” as I think that is, from 
current thinking, historically accurate. I believe that “Anazazi” is Navajo for 
something like “ancient enemy” but could be wrong on that. I guess I should 
have kept up contact with the fellow from the Hopi reservation that I went to 
high school with to be a bit more familiar with this history/background. :)

Regarding mapping of the individual buildings, my single feeble attempt at one 
site was foiled by the fact that it was, as is typical, in an overhang under a 
cliff with limited access. So my GPS had very inaccurate data and the site is 
not visible on aerial imagery. Best of luck in your mapping.

Cheers,
Tod

> On Jan 5, 2020, at 10:17 AM, Rob Savoye  wrote:
> 
> On 1/5/20 10:56 AM, Martin Koppenhoefer wrote:
> 
>> from my point of view, yes, it is usually preferable to tag ruins with
>> historic=archaeological_site (unless they are modern/recent). I’ve
>> myself used historic=ruins a lot many years ago and have since changed
>> most of them to archaeological site.
>> I also suggest to add historic:civilization to give more
>> context: https://taginfo.openstreetmap.org/keys/historic:civilization#values
> 
>  historic:civilization='Ancestral Pueblo people' or 'Anasazi' ? Yeah,
> last known inhabitants was 1300AD.
> 
>> And site_type of course: https://taginfo.openstreetmap.org/keys/site_type
> 
>  I think archeologists still are arguing over the site type. :-) Nobody
> really knows whether they were forts, food, storage, lodging, or all of
> the above.
> (https://www.smithsonianmag.com/history/riddles-of-the-anasazi-85274508/)
> 
>> I’d see historic=ruins as a very generic fallback when you have no clue
>> what you are looking at, but which should ideally be retagged if you do
>> have an idea what it is.
> 
>  I'll fix the tag. When I get down that way, I plan to collect more
> information from the locals. Most of it is reservation land and poorly
> mapped. It's about a remote a place you can get to in the continental US.
> 
>  Oh, most of these have 'name="Indian Ruin", not sure if that's
> necessary as it's redundant.
> 
>   - rob -
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [Talk-us] Trunk VS primary,

2019-12-20 Thread Tod Fitch

> On Dec 20, 2019, at 5:25 PM, Paul Johnson  wrote:
> 
> 
> What I'm saying is highway=bundesstraße could be acceptable, but 
> straße=bundestraße wouldn't be.  Mostly so way type objects with highway=*  
> are still potentially routable.

I sure wouldn’t want to be the person in charge of maintaining either the style 
definition or the SQL select function that had to decide which of many possible 
highway tag values I was going to render as a freeway, major road, minor road, 
etc. when creating a map that covers the whole world or even just a significant 
part of it.

Cheers!
Tod




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Public WLAN boxes

2019-12-18 Thread Tod Fitch
In the U.S. it would be called wifi or wi-fi rather than wlan. Anyone know what 
the British English is?

Sent from my phone, please excuse my brevity.

> On Dec 18, 2019, at 2:22 AM, Cascafico Giovanni  wrote:
> 
> Hello ML,
> which tags for those boxes, usually on pole or wall mounted which
> provide free public WLAN access? In my area they are managed by
> municipality and are subject to registration.
> 
> My tagging would be:
> 
> man_made=antenna
> operator=Comune di Cividale del Friuli
> antenna:application=wlan
> internet_access=wlan
> fee=no
> 
> ___
> 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] Route node roles - was Re: Feature Proposal - RFC - hiking_trail_relation_roles

2019-12-09 Thread Tod Fitch
In my area lots of search and rescue teams use maps and services provided by 
CalTop, SarTopo and other similar providers. And it turns out that 
CalTopo/SarTopo and others use OpenStreetMap data when generating maps. One 
reason for this is that OSM has much better (more data and more accurate data) 
trail and backcountry information than the big companies that focus on 
automobile navigation.

So many people are relying on OSM for their lives. They just may not know it.

With respect to nodes on hiking routes, many (most? all?) the trailheads for 
trails heading into officially designated wilderness areas near me have a 
sign-in station. Usually a sign and a weather resistant box with a notebook or 
clipboard in it where you are required to sign in with your party’s size, 
intended route, etc. That serves two purposes: 1) It helps track the use of the 
area for official reports, funding, etc. And 2) it is checked when people are 
reported missing or overdue to aid in the search effort. I am not sure if this 
counts as a “check point” as being discussed, but it is a useful thing to map.

Cheers!

> On Dec 9, 2019, at 2:47 PM, Peter Elderson  wrote:
> 
> Yes I know... I trust nobody will rely on OSM for their life, unless the 
> rescue service itself checks and guarantees that the data is 100% correct and 
> complete.
> 
> But it's nice if they are mapped.
> 
> Fr gr Peter Elderson
> 



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rethinking Map Features

2019-08-06 Thread Tod Fitch


> On Aug 6, 2019, at 12:56 AM, Martin Koppenhoefer  
> wrote:
> 
> sent from a phone
> 
>> On 6. Aug 2019, at 05:33, Tod Fitch  wrote:
>> 
>> When I walk down a street collecting house numbers I have no indication of 
>> the ZIP code of each building. If you require ZIP codes then I am forced 
>> into an import situation rather than a field survey
> 
> 
> you might survey this by asking locals about their address, or by looking at 
> addresses that businesses publish about themselves.
> 
> Cheers Martin

When I map businesses I do look to see what they publish about themselves and 
the ZIP code as well as hours of operation can be easily determined. But if you 
are asking me to knock on doors in residential areas or ask total strangers who 
look like they might be locals what their ZIP code is as I collect non-business 
addresses you are asking too much.

In the suburban sprawl of my country I am guessing there are far more 
residential addresses than business addresses. So putting postal code 
requirement on my collecting house numbers means that either we will never have 
a critical mass of house numbers or we will be doing it all with imports. By 
critical mass, I mean a sufficient density of numbers so people use OSM as 
their first choice for looking up an address to navigate to. At least where I 
live, ZIP codes are not needed or normally used for when giving an address for 
a navigation destination. ZIP codes are used really for just one thing: 
Delivering mail.

I can see a suggestion in the wiki that acquiring a postal/ZIP code for an 
address is desirable to provide completeness. But making it a requirement? No.

Cheers Tod.


signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Rethinking Map Features

2019-08-05 Thread Tod Fitch
Requiring postal codes on addresses makes no sense even in countries that use 
ZIP codes. When I walk down a street collecting house numbers I have no 
indication of the ZIP code of each building. If you require ZIP codes then I am 
forced into an import situation rather than a field survey.

Cheers!
Tod


On August 6, 2019 3:10:44 AM UTC, Marc Gemis  wrote:
>and what if I do not agree with the English text. I saw the example
>for addr:street in your movie.
>The description now says you have to add addr:postal_code. This is not
>true for countries whare postal code boundaries are mapped. I do agree
>that this is needed in countries that use ZIP codes though. How do we
>solve such issues (before they get translated in too many languagues)
>?
>
>regards
>
>m.
>
>On Mon, Aug 5, 2019 at 4:00 PM Joseph Eisenberg
> wrote:
>>
>> Thanks, I've got it now.
>>
>> The problem with the wikibase data item "labels": if you go to add
>the
>> description in another language for a recently created wiki page, the
>> top left of the page has a very large, gray text heading like "No
>> Label Defined" (but in Indonesian, or Spanish, etc), which suggests
>> that something is missing.
>>
>> I suspect this happens because the English "label" field may not have
>> been created in the data item?
>>
>> Also, when adding the description, the next field to the left is the
>> blank label field, with grayed-out text "No Label Found". It's quite
>> tempting to fill this in. Do we really want wiki users to feel they
>> should add translations for the "key" and "value" of each tag?
>>
>> On 8/5/19, Yuri Astrakhan  wrote:
>> > Joseph, you don't need to use preferences - just click the language
>> > switcher at the very top of the page, and you only need to switch
>to
>> > Indonesian and back once -- the interface will always offer both
>choices to
>> > fill out.  Please see the video, and let me know if what you see is
>> > different. You might be using mobile version of the site?
>> >
>> > Filling it out labels in every language is a bit silly - there are
>> > thousands of languages, why would we want to store identical
>information in
>> > every one of them, when the system automatically does fallback to
>English?
>> > I could create some sort of a javascript gadget that hides the
>label column
>> > when the item type is a key/value/relation/relation role
>(multilingual
>> > labels are still useful for other item types), but some people have
>already
>> > added some alternative language-specific labels, essentially
>localizing
>> > keys - not sure if we should just hide those.  BTW, if anyone wants
>to hack
>> > on it (I'm looking at you Minh :)), it would be awesome!  Or at
>least we
>> > should maybe give a warning when user tries to add a label
>identical to
>> > English?
>> >
>> > Every wiki page, including the data items have a "history" tab at
>the top
>> > that will show every edit done to that page.
>> >
>> > On Sun, Aug 4, 2019 at 12:17 PM Joseph Eisenberg
>> > 
>> > wrote:
>> >
>> >> Thanks, yes, changing the language under “preferences” for the
>wiki
>> >> works,
>> >> though it’s a little annoying.
>> >>
>> >> You should set the label field for all languages to the key=value
>or
>> >> remove this field and display the key=value at the top of the page
>> >> anyway.
>> >> It’s quite distracting Now.
>> >>
>> >> Is there a way to see the wikibase data item history? One big
>concern I
>> >> have is that it won’t be easy to see when something is changed.
>Can you
>> >> get
>> >> notified if someone changes a description?
>> >>
>> >> Joseph
>> >>
>> >> On Mon, Aug 5, 2019 at 1:05 AM Yuri Astrakhan
>
>> >> wrote:
>> >>
>> >>> P.S. I made a short video on how to add descriptions and
>translations
>> >>>
>> >>> https://www.youtube.com/watch?v=rI1NDD4MtC4
>> >>>
>> >>> On Sun, Aug 4, 2019 at 11:56 AM Yuri Astrakhan
>
>> >>> wrote:
>> >>>
>>  Joseph, before you click "edit description", change your
>language at
>>  the
>>  top of the wiki page (make sure you are logged in.  Also, if you
>change
>>  the
>>  language a few times to the ones you know, e.g. to Indonesian,
>to
>>  Spanish,
>>  and then to English, I think interface will always offer you to
>enter
>>  description in the last few you had picked.
>> 
>>  Thanks for adding translations!
>> 
>>  On Sun, Aug 4, 2019 at 11:40 AM Joseph Eisenberg <
>>  joseph.eisenb...@gmail.com> wrote:
>> 
>> > You're right, I was a little confused. Almost all the features
>on Map
>> > Features have a wiki page (and those that don't should get a
>page or
>> > more likely be removed), so I understand that they have an OSM
>> > wikibase entry, now, and creating the data item isn't an issue.
>> >
>> > But I still can't figure out how to add description in another
>> > language?
>> >
>> > I tried to get the Indonesian translation by:
>> > 1) Open the English wiki page (eg from the link on Map Features
>in
>> 

Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

2019-05-21 Thread Tod Fitch


> On May 20, 2019, at 4:28 PM, marc marc  wrote:
> 
> Le 21.05.19 à 00:58, Joseph Eisenberg a écrit :
>> I don’t feel enthusiastic about creating a 4th competing tagging
>> standard to go along with camp_site=pitch, camp_site=camp_pitch
>> and tourism=camp_pitch
> 
> it's an argument that makes sense.
> perhaps in this case, should we start by proposing to depreciate
> camp_site=pitch and camp_site=camp_pitch since these are the 2 most
> problematic in the logic of tag linking
> 
> both depreciated tags would be temporarily converted into
> tourism=camp_pitch but without voting on the choice of the final key,
> dividing the problem in two would allow, i hope, to have almost
> unanimity on the first step
> 

Please excuse possible Americanisms. What we’d call a “campground” is 
apparently called a “campsite” in British English and somehow turned into “camp 
site” in OSM. And what we’d call an individual place within a campground would 
be “camp site” but is apparently a “pitch” in BE. I keep mistyping these and 
then correcting myself. If I’ve missed some, I hope it is still readable. This 
is also a rather long post, so please bear with me.

At present we seem to have at least three ways used to mark an individual 
tent/caravan site (pitch) within a campground (campsite or camp site).

tourism=camp_pitch [1]
camp_site=pitch [2]
camp_site=camp_pitch [3][4][5]

With respect to tourism=camp_pitch, it seems to have limited use (227 
instances). I see no wiki on it at all, not even a proposal. So I don’t know if 
the taggers intended it to be for a place within a campsite or not. It has the 
unfortunate characteristic that it conflicts with tourism=camp_site so you 
can’t tag a site with only one place for tent/caravan with both camp_site (so 
it can be found at a top level by someone looking for camp sites) and 
camp_pitch (so you can potentially list the detailed characteristics (table, 
fire ring, etc.). For that reason I am very much against this.

With respect to camp_site=pitch, the argument against that in these mailing 
lists a while back was that “pitch” is more associated with sports playing 
fields so “camp pitch” was suggested. I believe this can be fully deprecated 
and replaced with whatever new tagging gains a consensus.

This leads us to camp_site=camp_pitch or some other not yet formally proposed 
tagging.

Arguments against camp_site=camp_pitch include (with my commentary):

“Problematic in the logic of tag linking”

See [6]. We are dealing with a pitch within a campsite. So 
camp_site=camp_pitch, camp_pitch=* (or camp_pitch:*=value) fits in this scheme. 
On my query about what was meant by tag linking one of the responses was:

> On May 21, 2019, at 6:20 PM, Joseph Eisenberg  
> wrote:
> 
> While "key=X" and "X=type_of_X" is a common way of tagging properties
> of features, there is not a standard way of tagging features that are
> located within a larger feature.
> 
> There are at least 4 ways of doing this:
> 
> 1) "key=X" -> "X=name_of_smaller_feature", where X is the term for the
> larger feature.
> Example: "allotments=plot" is used to define a specific plot within an
> area of "landuse=allotments"
> 
> 2) "key=X" -> "key=X_Y"
> Example 1: "amenity=parking" is used for a parking lot, and
> "amenity=parking_space" is used for the space to park one vehicle
> within a parking lot
> 
> 3) "key=yes" -> "key:namespace=yes"
> Example: "building=yes" and "building:part=yes" is used to define
> parts of buildings with different characteristics, eg a different
> number of levels or different type of roof.
> 
> 4) "key1=X" -> "key2=Y"
> Two unrelated keys are used with two unrelated values.
> Example: "man_made=works" should usually be within a "landuse=industrial” area

The use of “tourism=camp_site” -> “camp_site=camp_pitch” matches example 1. So 
while I think that this tagging does not go against good tagging syntax, others 
disagree.

Going down the list of negative votes on the proposal page.

“The tag is in conflict with the tag chain, according to which camp_site=* 
describes the type of the tourism=camp_site. I think that camp_site:part 
=camp_pitch
 

 would make most sense”. And “as already mentioned camp_site:part 
=camp_pitch
 

 makes sense. camp_site 
=camp_pitch 
 does not”. I 
can understand this argument. I think meets the goal of the current preferred 
tagging syntax and should be further discussed.

“I think too this is inconsistent. The key must be in tourism=*”. See my 
comment above: A camp pitch is within a campsite putting it at the 

Re: [Tagging] tag linking [was: Feature Proposal - Voting - camp_site=camp_pitch]

2019-05-21 Thread Tod Fitch


> On May 21, 2019, at 4:07 PM, marc marc  wrote:
> 
> Hello,
> 
> Le 21.05.19 à 03:25, Tod Fitch a écrit :
>> If there is someplace I can read up on this “logic of tag linking”?
> 
> this logic is massively used and yet I had a hard time finding a link
> whose content is limited to a line and an example
> 
> https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_tags
> 
> There's a common pattern of *iterative refinement* in use in many
> tagging schemes, which has the advantage that the scheme can grow over
> time to be more and more descriptive whilst still being
> backwards-compatible: highway=crossing crossing=uncontrolled
> 
> it would probably be useful to better document it
> 
> Regards,
> Marc

Now I am a little confused with respect to objections to

camp_site=camp_pitch [1]
camp_pitch:*=value [2]

For the individual camping places within a tourism=camp_site [3]. This is 
exactly the same type of thing you just listed:

highway=crossing
crossing=uncontrolled

Except that your crossing=uncontrolled is less flexible unless you start adding 
more information (controlled/uncontrolled, marked/unmarked, ramp/no ramp, 
tactile surface). So to be more precise you’d need something like

highway=crossing
crossing:controlled=yes/no
crossing:marked=yes/no
etc.

But that is an argument for another thread on the mail lists. Getting back to 
individual camping places within a camp site, for the whole area you tag with 
tourism=camp_site [4]. Things common to the whole place (address, fees, usage 
of tents, caravans, etc.) can be tagged on the overall area. Within that area 
you, for more detail, you can add shared amenities and individual camping 
pitches.

Now for detail within the pitch is there a problem using camp_pitch:*=value?

I don’t get it. Would people prefer something like camp_site:pitch:*=value to 
keep it within the camp_site namespace? If so, then why aren’t we arguing about 
changing camp site tagging to be along the lines of tourism:camp_site:*=value 
to keep that within the tourism namespace?

One objection I’ve read is for camp sites that have only one place to camp 
(possible on a back country trail). If the tourism=camp_site has only one place 
to camp then you can simply put a single node or small polygon with something 
like:

tourism=camp_site
camp_site=camp_pitch
camp_pitch:type=tent
camp_pitch:fire=ring
etc.

The camp_pitch:* key space is separate from any camp_site:* so you can do 
detailed pitch specific stuff without worrying about key overlap with any 
camp_site:*=value tagging. No problem there.

Anyway, it seems to me that the proposal was attempting to exactly follow the 
syntactic conventions for new tags.

Slightly off topic, but camp_site=camp_pitch came into existence because the 
older camp_site=pitch [5] was not well accepted by people on these mailing 
lists because “pitch” is more associated with fields for sports.

Cheers!

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch
[2] https://wiki.openstreetmap.org/wiki/Proposed_features/Key:camp_pitch
[3] https://wiki.openstreetmap.org/wiki/Key:camp_site
[4] https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dcamp_site
[5] https://taginfo.openstreetmap.org/tags/camp_site=pitch





signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - Voting - camp_site=camp_pitch

2019-05-20 Thread Tod Fitch


> On May 20, 2019, at 4:28 PM, marc marc  wrote:
> 
> Le 21.05.19 à 00:58, Joseph Eisenberg a écrit :
>> I don’t feel enthusiastic about creating a 4th competing tagging
>> standard to go along with camp_site=pitch, camp_site=camp_pitch
>> and tourism=camp_pitch
> 
> it's an argument that makes sense.
> perhaps in this case, should we start by proposing to depreciate
> camp_site=pitch and camp_site=camp_pitch since these are the 2 most
> problematic in the logic of tag linking
> 
> both depreciated tags would be temporarily converted into
> tourism=camp_pitch but without voting on the choice of the final key,
> dividing the problem in two would allow, i hope, to have almost
> unanimity on the first step

Is there some overall agreed upon “logic of tag linking” that I’ve missed 
reading about?

Near as I can tell tag formation/structure/logic is all over the place, 
obviously evolving with time and the opinion(s) of whoever decided they needed 
to map a particular set of features.

If there is someplace I can read up on this “logic of tag linking”? I’d love to 
have a link.

Thanks!




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Whispering asphalt

2019-05-02 Thread Tod Fitch
I have not heard of “whispering asphalt” but I know that in some areas of the 
state I live in they have been using a porous asphalt on roads to provide 
better traction during rain storms.

So I am not sure if the current uses of “asphalt:type=porous” would be to 
indicate pavement designed for good traction in the rain or if it was for 
making a less noisy road.

From taginfo, it looks like asphalt:type has only been used a few times and 
always with the value of porous. And it looks like they are all in the one area 
you found with your overpass query. Perhaps the original mapper could be 
contacted to see what they were trying to describe.

Cheers!
Tod

> On May 2, 2019, at 12:55 PM, amilopow...@u-cloud.ch wrote:
> 
> Signed PGP part
> Hello
> 
> I used to live in Fribourg, Switzerland where they put "whispering asphalt" 
> on one of the main roads in order to prevent noise. You can barely hear an EV 
> now, but that is another story.
> 
> Since we have quite a lot of discussions about noise pollution I thought it 
> might be a good idea to implement a tag for that.
> 
> surface=whispering_asphalt or surface=silent_asphalt came to my mind but I 
> don't know what the official term for that aspahlt in English is. In German 
> we call it "Flüsterbelag" or "Flüsterasphalt".
> 
> Then I found on Overpass-Turbo someone that tagged "asphalt:type=porous". [1] 
> Since I don't work in that area I don't know for sure if this is the same 
> thing as I imagine and I found only one Wikipedia article in German [2] about 
> that asphalt I mean.
> 
> I personally prefer one of my first ideas, since I hate to add another 
> key/value if I can say it in one.
> 
> I look forward to hear your thoughts and comments.
> 
> Regards
> Ueli (amilopowers)
> 
> 
> [1] https://overpass-turbo.eu/s/Iky  (click 
> "run")
> [2] https://de.wikipedia.org/wiki/Asphalt#Offenporiger_Asphalt 
> 
> 
> 
> Sent from ProtonMail , encrypted email based in 
> Switzerland.
> 
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Wiki page for natural=mountain_range

2019-04-30 Thread Tod Fitch

> On Apr 30, 2019, at 9:28 PM, Warin <61sundow...@gmail.com> wrote:
> 
> Depends?
> 
> Warning - my interpretation!
> 
> SADDLE = low point between two high points (mountains), it does not descend 
> near the level of the adjacent valleys.
> 
> PASS =A gap in a range of mountains or hills permitting easier passage from 
> one side to the other, it descends near the level of the adjacent valleys.
> 
> This gives me a difference between 'pass' and 'saddle',otherwise they appear 
> to be the same?
> 
> 
> If it were a 'pass' then that would make the range into two separate ways.
> If it is a saddle then it does not break the range, but forms part of it.
> 
> Some mountain ranges do not have crest along their entire length .. yet they 
> are a mountain range along the entire length.
> 

Hmmm. Then many of the passes, including Donner Pass and Tioga Pass, in 
California’s Sierra Nevada are actually saddles?

I’ve assumed that a pass was simply a saddle that was a convenient route for 
travel.

Looking at 
https://www.vividmaps.com/2018/11/gap-vs-pass-vs-notch-vs-saddle.html 
 maybe 
the difference between pass, saddle, gap and passage - at least in the US - is 
mostly a difference in regional dialect. In which case I guess OSM can do its 
usual and try to formalize the use and definition of one that most closely 
matches UK usage.




signature.asc
Description: Message signed with OpenPGP
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Subkey camp_pitch:*

2019-04-11 Thread Tod Fitch

> On Apr 11, 2019, at 1:01 AM, Joseph Eisenberg  
> wrote:
> 
> Thank you for your comments, Graeme
> 
>> aren't you duplicating everything that exists under the
>> tourism=camp_site & caravan_site pages ?
> 
> This proposal is for designating features that are available at
> individual spots for one tent or one caravan (normally, although I
> suppose a group tent site could also be tagged within larger
> campground). They key tourism=camp_site or tourism=caravan_site should
> be used on the area of the whole campground or caravan site.
> 
> The tag camp_site=pitch_site is only used if there are multiple
> designated pitches within the site.
> 
> So these subkeys were made to define if there are certain amenities or
> facilities available at an individual pitch, eg: do you have your own
> picnic table, fire ring, drinking water tap, electrical outlet, and
> parking right at the pitch? 
> 
> It would also be possible to map every feature with separate nodes, eg
> amenity=drinking_water on a node marking the location of a water tap,
> but if every pitch in a large campground has a water tap, this could
> lead to rather crowded map renderings.
> 


More than just crowded map renderings. Consider the case of a camp pitch with a 
picnic table, fire place, parking and water tap that are for the exclusive use 
of the people camping at that pitch. If you tag it with:

leisure=picnic_table
amenity=bbq
amenity=drinking_water
amenity=parking

Oops, can’t put multiple amenity tags on one object. And every time someone 
suggests formalizing a scheme for formalizing multiple values it gets bike 
shedded or worse.

So now you are having to use multiple objects for the camp pitch which leads to 
the issue of showing association (now we need a site relation or equivalent). 
And since these features can be for the exclusive use of the people occupying 
the site, we need to show some sort of access restrictions. Basically, it gets 
much more messy if we don’t have camp_site sub keys that implicitly show 
association and access restrictions.

Going over the old list of sub keys, I can see where some of them are probably 
not desired. “Surface” may be one, especially if the camp pitch is mapped with 
a polygon. Would surface still work if the pitch is only mapped with a point 
(that seems to be true of highway=turning_circle so a precedence has been set)? 
If so, then camp_pitch:surface could be removed from the proposal.

But it remains that some features of a camp site pitch that we have general 
tagging for if they are stand alone items are more easily mapped and 
represented with their mutual associations and access restrictions if we use 
sub keys.

Cheers,
Tod




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


Re: [Tagging] Feature Proposal - RFC - Camp_site=camp_pitch

2019-04-10 Thread Tod Fitch

> On Apr 10, 2019, at 12:02 AM, Joseph Eisenberg  
> wrote:
> 
> I've restarted the proposal process for camp_site=camp_pitch
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/camp_site_pitch 
> 
> 
> This tag has already been used over 6800 times by over 380 mappers and is 
> pretty well defined by the old proposal page from 2015 as an individual tent 
> or caravan spot within a tourism=camp_site area.
> 
> These features should be mapped as a node (or possibly an area, when this is 
> verifiable) and "ref=*" can be used for the number of the camp pitch. This 
> will be useful for routing and could be rendered like addr:unit (most 
> campsites do not have official unit numbers).
> 
> There is also a tag camp_site=pitch which is undocumented and seems to mean 
> the same thing, but it is only used 1500 times by 34 mappers, and does not 
> seem to be growing in usage. I'd recommend approving camp_site=camp_pitch 
> instead
> 
> Please comment here or on the proposal discussion page:
> https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/camp_site_pitch 
> 


I am not sure that a “restart” of discussion of camp_site=pitch on this list is 
required: There are nearly 7000 usages [1] spread pretty much around the whole 
world [2]. This implies to me that what someone ought to do is move this old 
proposal into a description of how it is actually being used. Bike shedding it 
here among the dozen or so people that will argue this forever is just a waste 
of energy.

The edit of the proposal made in the last couple of days removed details on how 
to tag the amenities associated with each camp pitch (the suggested 
camp_pitch:*=* tagging). These have also gained some traction [3] and by this 
deletion there is no explanation of them anywhere in the wiki. Not good! I am 
of a mind to revert that part of your changes just so the many uses found 
around the world have some definition of what they mean and what values are 
documented.

Given the usage trends, I agree that we should deprecate the camp_site=pitch 
(and its associated sub-tagging) and suggest the camp_site=camp_pitch tagging 
instead.


> On Apr 10, 2019, at 6:51 AM, Joseph Eisenberg  
> wrote:
> 
> The current proposal suggests that this is useful to define individual sites 
> for tents or caravans within a larger leisure=camp_site area. 
> 
> I don’t see much use in double tagging a single backcountry tent site with 
> leisure=camp_site and camp_site=camp_pitch on the same node.
> 
> Usually an individual campsite has a name rather than a ref= tag. 
> 
> For backcountry campsites, you can define the type of camp_site by using 
> camp_site=basic (if there is no water or toilet) - see Key:camp_site
> 
> Joseph
> 

If the camp site has only a single pitch then I agree the tagging is over kill 
and maybe some simplifications are in order. But I my part of the world many 
(most?) backcountry camp sites actually have more than one area to pitch a tent 
and many of those actually are developed enough to have fire rings (fires 
outside of an official location is highly frowned upon). So I’d argue that a 
blanket “we don’t need this for backcountry camp sites” may be region specific.

I strongly suggest the way forward here is to simply move the old “proposed 
features” for camp_site=camp_pitch, with sub-tagging defined, into the regular 
pages of the wiki that describe tagging actually in use.


[1] https://taginfo.openstreetmap.org/tags/camp_site=camp_pitch#overview
[2] https://taginfo.openstreetmap.org/tags/camp_site=camp_pitch#map
[3] https://taginfo.openstreetmap.org/search?q=camp_pitch

Cheers,
Tod



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


Re: [Tagging] Mapping deforestation wikipage

2019-03-14 Thread Tod Fitch

> On Mar 14, 2019, at 2:04 PM, Kevin Kenny  wrote:
> 
> On Thu, Mar 14, 2019 at 4:51 PM marc marc  wrote:
>> no:landcover=trees ?
>> or, as the previous landcover/imagery show tress, was:landcover=trees
> 
> However you want to spell it.
> 
> I just saw two replies to Lorenzo that were suggesting that his source
> data were unmappable because they didn't support a sufficiently
> detailed taxonomy of landcover, and I wanted to point out that "no
> trees here" is useful information that should be distinguished from
> "we haven't yet looked to see if there are trees here."
> 
> "was:landcover=trees" is not something that I favour, because there's
> also the useful combination, "no trees in the old imagery, and no
> trees in the current imagery either", still without information about
> whether one is looking at grass, scrub, heath, meadow, wetland or
> farmland, which can't always be distinguished in orthoimages.  I
> suppose that the "no:landcover=trees" COULD work, but I don't see
> no:*=* in wide use, and suspect that it will be controversial.
> 

Why not landcover=vegetation as an equivalent to highway=road? It would 
indicate that some type of plant matter is growing on it but exactly what is 
not yet known. Once more information (field survey? low level aerial 
survey/photos?) is available then a more specific landcover could be applied.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Mapping deforestation

2019-03-11 Thread Tod Fitch

> On Mar 11, 2019, at 10:44 AM, Mateusz Konieczny  
> wrote:
> 
> Note that https://wiki.openstreetmap.org/wiki/User:Rudolf/draft_landcover 
> 
> is proposal from 2014 and is rarely used (not used) in mapping.
> 

Maybe not that one, but I certainly map per 
https://wiki.openstreetmap.org/wiki/Landcover specifically I use it to map 
areas with trees, scrub and grass.

Cheers!




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] edit war about deletion of proposal

2019-02-05 Thread Tod Fitch
Another +1

That wiki page [1] should be reverted back to its prime, no need for it to be 
labeled for deletion.

[1] https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dbikeshed

> On Feb 5, 2019, at 1:02 PM, Sergio Manzi  wrote:
> 
> +1!! :-)
> 
> On 2019-02-05 21:57, Kevin Kenny wrote:
>> Oh, please bring back amenity=bikeshed!  I hadn't seen it before, and
>> it's hilarious!
>> 
>> (Unless we have a rule that the Wiki shall be devoid of the least
>> indication that mappers have a sense of humour...)
> 



smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Forest parcel with other landcover (scrub, scree…): how to map?

2019-01-22 Thread Tod Fitch

> On Jan 22, 2019, at 12:52 PM, Adam Franco  wrote:
> 
> As someone who has mapped a lot of landcover & landuse 
>  in my local area, I 
> welcome sorting out the confusion that is the current state of 
> natural=wood/landuse=forest. Many parcels around me are managed for forestry 
> purposes but don't have trees currently while others had been cleared at one 
> point, but have returned to forest due to neglect and are not managed for 
> timber production.  My current practice is to map areas covered in trees as 
> landcover=trees + natural=wood, but I'd love to drop the natural=wood if 
> landcover=trees was rendered. Generally, I don't imagine that I'd map much 
> landuse=forestry, which is probably a good thing as I don't often know which 
> land is managed for productive forestry and which is more negligent forest 
> succession. In cases where the management is known and is important to be 
> known, then landuse=forestry becomes a useful tag as it is unambiguous as to 
> what it means.
> 
> I hope that a shift toward landuse=forestry would also include a shift toward 
> landcover=*, in particular landcover=trees as the rightful clear designation 
> that "there are trees here". Here is an old landcover=* proposal 
>  that might 
> be resurrected and updated.
> 
> I'm not sure if I would want landuse=forestry to be rendered by default or if 
> so, how I would like it to be styled. Generally in my region, areas managed 
> for forestry are more parcel boundaries than anything equating the land-cover 
> on the ground, so renderings that include iconography like trees are 
> problematic if those icons overlap and conflict with other land covers. I see 
> landuse=forestry as something more useful for custom maps or maybe something 
> that would be rendered as a subtle modifier to more-visible land-cover 
> renderings which are more directly visible and impactful when traversing the 
> landscape.
> 
> Best,
> Adam

+10 for this!

I also dual tag areas with trees as natural=wood and landcover=trees with the 
hope being that landcover=trees becomes the norm.

Perhaps the way forward would be to change the wiki to indicate that 
landuse=forest is deprecated due to its confused usage. Add some text to the 
page directing mappers to either landcover=trees if they are simply mapping the 
presence of trees or landuse=forestry if they are mapping an area used for the 
production of wood products (lumber, paper, etc.) that may or may not have 
trees on it a the moment.

Not rendering landuse=forestry on the default OSM map to reduce “tagging for 
the renderer” is an interesting idea. I’ll have to think about that but it does 
have some appeal.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Drain vs ditch

2019-01-15 Thread Tod Fitch

> On Jan 15, 2019, at 7:28 AM, Paul Allen  wrote:
> 
> On Tue, 15 Jan 2019 at 15:22, Peter Elderson  > wrote:
> At what size is it that a ditch turns into a drain?
> 
> The same size that a boy turns into a man.  Or when  you line the boy with 
> concrete.
> 

I assume “line the boy with concrete” to mean “line the ditch with concrete”.

There are a bunch of irrigation ditches in places like Arizona that are 
concrete lined simply to assure the water makes it to the field rather than 
soaking into the very dry ground under the ditch.

So my take would be size and “same size that a boy turns into a man” is 
probably a good way to describe the choice, i.e. judgement call by mapper.

Cheers!





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Trailhead tagging

2019-01-14 Thread Tod Fitch

> On Jan 14, 2019, at 2:51 PM, Kevin Kenny  wrote:
> 
> On Mon, Jan 14, 2019 at 5:50 PM Graeme Fitzpatrick
>  wrote:
>> What's the key dangling there for, Kev?
> 
> Absolutely no idea! I left it as I found it.
> 

Guess: Someone found it on the trail and figured it would be easier for the 
person missing it to find it hanging from the sign than some place along miles 
of trail.
Source: I’ve seen that done elsewhere.



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Creating shop=caravan

2019-01-13 Thread Tod Fitch

> On Jan 13, 2019, at 7:27 PM, Graeme Fitzpatrick  wrote:
> 
> So what do you call "little houses on wheels that are towed behind your car 
> to stay in when you go on holidays"? :-)
> 
> Are they just "trailers"
> 
> Thanks
> 
> Graeme

“Travel trailers”.

A generic plain “trailer” is probably for cargo or hauling your ATV, 
snowmobiles or “dirt bikes”.





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Drain vs ditch

2019-01-11 Thread Tod Fitch
Most of what I’d call a drain around here would be large underground pipes 
designed to carry storm water. Empty most of the time except perhaps for a 
trickle of water from various urban/suburban watering overflow. Used most of 
the time by raccoons, possums and rats as away to navigate through or shelter 
in an area without having to worry about being attacked by neighborhood dogs, 
though the larger ones could be attractive for adventuresome teenage boys to 
explore.

I’d call the open air, usually concrete lined, versions “storm channels” though 
that might be a local colloquial. Many/most of those follow reasonably close to 
the alignment of the original natural waterways and often carry the same name 
as the original (e.g. “Santa Ana River”, “Los Angele River”, etc.). Again 
“river” would be a historic term as they are often dry except during or 
immediately after a storm.

Cheers!

> On Jan 11, 2019, at 10:18 AM, Eugene Podshivalov  wrote:
> 
> Tod, what would be definition of "drain"?
> 
> Eugene
> 
> пт, 11 янв. 2019 г. в 21:10, Tod Fitch  <mailto:t...@fitchdesign.com>>:
> 
> > On Jan 11, 2019, at 8:36 AM, ael  > <mailto:law_ence@ntlworld.com>> wrote:
> >
> > As a native speaker, I do not recognise "canal" as appropriate for
> > irrigation. That is not to say that some canals may also be used
> > partly for irrigation.
> >
> > But the phrase "irrigation ditch" is common and understood.  Bear in
> > mind that the UK is mainly a fairly wet place, so the need for
> > substantial irrigation is not high except in some special cases.  The
> > unqualified word "ditch" would normally be understood as an artificial
> > unlined and usually small watercourse. But also, in certain contexts,
> > for a historic trench acting as a defense or fence, not necessarily
> > containing water.
> >
> > That seems to accord with a the sub tag irrigation=yes on ditches -
> > and maybe on other waterways if that is one of the uses/functions.
> >
> > ael
> >
> 
> +1
> 
> In the desert where I was raised the cotton fields were surrounded with 
> “irrigation ditches”, or “ditches” for short. The fields were watered from 
> the ditches by either syphon hoses or sluice gates.
> 
> Later, when working on road projects, I found that the low areas on the sides 
> of roads (often used as “side borrow” areas during construction of the 
> roadway) were formally called “drainage ditches” or just “ditches” for short.
> 
> So to me a ditch is simply a channel dug to move water.
> 
> But I am an American and our terms diverge somewhat from UK usage. So I 
> looked it up in my older paper version of the OED to find the first two 
> definition are “1. An excavation narrow in proportion to its length; the 
> trench or fosse of a fortification, etc.”. “2. Such a hollow dug out to 
> receive or conduct water, esp. to carry off the surface drainage of a road or 
> field, etc.”
> 
> Based on the second, I can see the reason why some would conflate “drainage 
> ditch” with simply “ditch”. But I don’t see from this where even in UK usage 
> a ditch has to be for drainage. It is simply a long narrow excavation and, in 
> the waterway sense, dug to conduct water from one place to another.
> 
> 
> Cheers!
> tf
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org <mailto:Tagging@openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging 
> <https://lists.openstreetmap.org/listinfo/tagging>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Drain vs ditch

2019-01-11 Thread Tod Fitch

> On Jan 11, 2019, at 8:36 AM, ael  wrote:
> 
> As a native speaker, I do not recognise "canal" as appropriate for
> irrigation. That is not to say that some canals may also be used
> partly for irrigation.
> 
> But the phrase "irrigation ditch" is common and understood.  Bear in
> mind that the UK is mainly a fairly wet place, so the need for
> substantial irrigation is not high except in some special cases.  The
> unqualified word "ditch" would normally be understood as an artificial
> unlined and usually small watercourse. But also, in certain contexts,
> for a historic trench acting as a defense or fence, not necessarily
> containing water.
> 
> That seems to accord with a the sub tag irrigation=yes on ditches -
> and maybe on other waterways if that is one of the uses/functions.
> 
> ael
> 

+1

In the desert where I was raised the cotton fields were surrounded with 
“irrigation ditches”, or “ditches” for short. The fields were watered from the 
ditches by either syphon hoses or sluice gates.

Later, when working on road projects, I found that the low areas on the sides 
of roads (often used as “side borrow” areas during construction of the roadway) 
were formally called “drainage ditches” or just “ditches” for short.

So to me a ditch is simply a channel dug to move water.

But I am an American and our terms diverge somewhat from UK usage. So I looked 
it up in my older paper version of the OED to find the first two definition are 
“1. An excavation narrow in proportion to its length; the trench or fosse of a 
fortification, etc.”. “2. Such a hollow dug out to receive or conduct water, 
esp. to carry off the surface drainage of a road or field, etc.”

Based on the second, I can see the reason why some would conflate “drainage 
ditch” with simply “ditch”. But I don’t see from this where even in UK usage a 
ditch has to be for drainage. It is simply a long narrow excavation and, in the 
waterway sense, dug to conduct water from one place to another.


Cheers!
tf




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Surface on turning circles

2019-01-02 Thread Tod Fitch
I am implementing a map rendering that differentiates roads based the type of 
surface. A number of these roads have turning circles which I would like to 
render too and I’d like to base the rendering on the surface.

Looking at the wiki page for turning_circle [1] and at taginfo [2] it appears 
that there has been no discussion or use of a surface tag on a point tagged as 
highway=turning_circle.

I suspect there are cases where a turning circle’s surface may not match the 
surface of the roadway so even if I could figure out how to determine the 
surface of the highway way the node was on it would not be a solution.

So, what is the opinion on adding to the turning_circle wiki page a section on 
tagging its surface? My thought would be to simply use the same surface tagging 
as for a highway way [3]

Thanks!

[1] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dturning_circle
[2] 
https://taginfo.openstreetmap.org/tags/?key=highway=turning_circle#combinations
[3] https://wiki.openstreetmap.org/wiki/Key:surface


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] how to map soft story/soft storey buildings properly?

2018-12-18 Thread Tod Fitch

> On Dec 17, 2018, at 2:17 PM, Martin Koppenhoefer  
> wrote:
> 
> 
> The bigger problem could be verifiability. OSM is about crowd sourced geodata 
> while this property seems to require expert capabilities and additional 
> information you cannot get non-destructively on the ground?
> 

For what it is worth, the Community Emergency Response Team (CERT) training I 
took a while back included a session on earthquake damage including how to 
identify soft storey construction. CERT is a local citizen response system in 
the United States and seems to be implemented, sometimes with different names, 
in most cities in the country. Since earthquake response is an important thing 
in California there were a number of sessions dedicated to response including 
quick survey for levels of damage to buildings, setting up evacuation areas, 
establishing communications with the official fire/rescue/law enforcement 
agencies, etc.

All this is to say that in an earthquake prone area there are likely to be a 
fair number of people unassociated with official emergency response, building 
trades, engineering, etc., who have had at least an introduction to identifying 
buildings that are suspect for structural issues in an earthquake.

Cheers!





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Ephemeral a water property key.

2018-12-13 Thread Tod Fitch
I do like the idea of one key to rule them all. But I am uncomfortable with a 
key name which has a negative preface.

At first I wondered about a perennial tag but then the values might be 
difficult. Then it occurred that we are trying to tag the presence of 
something, in this case water. There are only a few things tagged with 
presence=* now [1] and they look unrelated to water. But how about:

presence=perennial/seasonal/intermittent/ephemeral/summer/spring/winter/autumn/ 
etc.

And state that perennial be the default if untagged.

Cheers!

[1] https://taginfo.openstreetmap.org/keys/presence#values

> On Dec 13, 2018, at 4:55 PM, Warin <61sundow...@gmail.com> wrote:
> 
> Thoughts ... (take on  Hobbit like theme - one key to rule them all...)
> 
> As both intermittent and seasonal are all render the same .. why not combine 
> them into one key as well?
> 
> 
> non_perennial=seasonal/intermittent/ephemeral/summer/spring/winter/autumn/intermittent_summer/ephemeral_summer
>  etc
> 
> I note that intermittent is taken by many as 'I know it is non-perennial' so 
> it may be appropriate to have a non_perennial=yes for the more common mapping 
> value.
> 
> ???
> Well? Is that a reasonable idea?
> 
> It could be implemented as a mechanical edit on
> seasonal 1:1.
> On intermittent=yes ... as non_perennial=yes with a request to determine a 
> more specific value?
> On intermittent=season ... as non_perennial=intermittent_season
> 
> These could coexist with the present tags while people changed over.
> 
> 
> On 14/12/18 10:58, Sergio Manzi wrote:
>> You can do exactly the same with my new proposed values for intermittent=*
>> 
>> No need for a new key, I think.
>> 
>> Cheers,
>> 
>> Sergio
>> 
>> 
>> On 2018-12-14 00:48, Warin wrote:
>>> On 13/12/18 12:48, Sergio Manzi wrote:
 
 On 2018-12-13 02:36, Warin wrote:
> At the moment developing a system to render seasonal values on requires a 
>  determination on spring/summer/autumn/winter etc .. this would add some 
> new terms. Not too hard but does add to things.
 Also developing a system to render the ephemeral key would add some 
 complexity, probably more...
 
> Not certain about ephemeral being subservient to intermittent.
 If it is not there all of the time, than it is intermittent.
 If it doesn't last long, than it is ephemeral (but then it is not there 
 all of the time and thus it is intermittent too).
 
>>> 
>>> The primary motivation for me is that a water feature with intermittent is 
>>> more likely to have water, even it I have to dig a meter or two for it, 
>>> than a water feature with ephemeral.
>>> 
>>> I don't expect a 'normal' map will tell me this. But a desert map should.
>>> 
>>> I would map the ephemeral river banks/courses.
>>> But then the places where water pools to form more permanent water sources 
>>> I would as natural=water, intermittent=yes. In this way they can be 
>>> distinguished as a more probable source of water.
>>> Some satellite imagery shows these .. but then some shows the area just 
>>> after rain! So it requires some judgements.
>>> 
>>> I'll add this as a rationale ...
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ___
>>> 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 mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] emergency=control_centre

2018-12-09 Thread Tod Fitch
> On Dec 9, 2018, at 7:11 AM, Paul Allen  wrote:
> 
> On Sun, Dec 9, 2018 at 3:06 PM dktue  > wrote:
> 
> I would like to propose a tag for emergency control centers (the place
> you reach when you call 112 in Europe).
> 
> Why?
> 
> As far as I know, these are places one contacts via telephone.  They may be 
> located far from
> the locality they serve, even though calls from that locality may be routed 
> to one particular
> control centre.  Are the ones you are familiar with of a kind where one must 
> walk in to report
> an emergency?  Unless they are, it serves no purpose to mark them on a map.  
> Unless, perhaps,
> one is a terrorist intent upon damaging infrastructure.
> 
> --
> Paul
> 

In North America they are called PSAP (Public Safety Answering Point). [1]

But I agree that there does not seem to be a driving reason to map them as the 
physical location is not relevant for their use.

And I don’t believe that they are a “control center”. More of a communication 
center. If it is a “normal” emergency, the police/fire/medical will have their 
own operations center, probably separate from the “answering point” that 
oversees the personnel dispatched, etc. If it becomes a big incident, then 
there will be a “Incident Command Post” (ICP) setup to handle the situation and 
the ICP will vary from incident to incident and could be anywhere.

Cheers!

[1] https://en.wikipedia.org/wiki/Public_safety_answering_point



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag shared waterway highway

2018-12-08 Thread Tod Fitch

> On Dec 8, 2018, at 2:31 AM, Joseph Eisenberg  
> wrote:
> 
> I would recommend drawing a separate “way” for the highway. I imagine that 
> the route taken by vehicles or people walking is a few meters off of the 
> center of the waterway, and perhaps a little straighter. If you are coarsest 
> tracing the waterway and road, then the two ways might share most of their 
> nodes.

As soon as I got to your “I imagine that” I decided you’ve no experience in 
this and I should discount anything that follows.

In the desert southwest of the United States where I was raised they call the 
usually dry water courses a “wash”. And they are often used for vehicle travel 
when dry which is almost all of the time. In hilly or mountainous areas the 
width of the waterway is often no wider than most vehicles so there is no place 
“a few meters off the center of the waterway”. And my experience in 
walking/hiking along them is you are often in the middle of the most recent 
route of flood waters as the walking is easier there (less debris, etc.).

 I don’t like the OSM mapping options but what I’ve settled on is a single way 
tagged as:

ford=yes
highway=track
intermittent=yes
surface=sand
waterway=stream

Some of the washes have names. Some of the tracks have names. Sometimes they 
both have names and occasionally the two names differ. I haven’t a solution for 
that.

It would be nice if there was a way to tag the intermittent flow as ephemeral 
but that has been “bike shedded” to death here before. I know/hope that anyone 
local will have a pretty good idea about whether or not there is likely to be 
water in the drainage (a summer cloudburst locally or in the adjacent higher 
ground) and be smart enough not to enter it for the couple of hours that a 
water event is likely to last.

Cheers!



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Neighborhood Gateway Signs?

2018-11-30 Thread Tod Fitch
One of the listed values of the place tag is “neighbourhood”. And, in the one 
case where I mapped such a overhead sign, it was the entrance to a 
neighborhood. It was, in fact, the location you’d be taken to by the 
motor-rickshaw from the metro station when you gave your destination and was 
part of the address I was given to reach the residence in question.

But that was in another country than I live in. In my own country, it is much 
more likely that a development would have a sign to the side of a main way in. 
Mostly there for advertising. Nobody, or at least almost nobody, would ever use 
it to give directions or use it as a destination itself.

So I guess the use of a place=neighbourhood tag might be dependent on the local 
situation. Is this the landmark the locals use for giving directions? If so, 
then place=neighbourhood is more likely to be usable by a routing engine than 
usage=welcome_sign.

Cheers!

> On Nov 30, 2018, at 9:18 AM, Sergio Manzi  wrote:
> 
> No, wait, I disagree with the "place=neighbourhood" thing!
> 
> See: https://wiki.openstreetmap.org/wiki/Places 
> <https://wiki.openstreetmap.org/wiki/Places> and 
> https://wiki.openstreetmap.org/wiki/Key:place 
> <https://wiki.openstreetmap.org/wiki/Key:place>
> Cheers!
> 
> On 2018-11-30 18:10, Sergio Manzi wrote:
>> Seems very good to me.
>> 
>> already used: https://taginfo.openstreetmap.org/tags/man_made=gantry 
>> <https://taginfo.openstreetmap.org/tags/man_made=gantry>
>> proposal exist: https://wiki.openstreetmap.org/wiki/Proposed_features/Gantry 
>> <https://wiki.openstreetmap.org/wiki/Proposed_features/Gantry>
>> In the proposal I don't like very much the way to indicate clearence, 
>> maxheight:physical=* (what? opposed to...  maxheight:virtual=*, maybe?), but 
>> that's another story...
>> I think you found the right key, bravo!
>> 
>> Sergio
>> 
>> 
>> On 2018-11-30 17:53, Tod Fitch wrote:
>>> I’ve mapped by placing a way across the road tagged with:
>>> 
>>> man_made=gantry
>>> name=“whatever”
>>> place=neighbourhood
>>> 
>>> I suppose one could add some sort of tagging indicating the vertical 
>>> clearance that might be of use for routing.
>>> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Neighborhood Gateway Signs?

2018-11-30 Thread Tod Fitch
I’ve mapped by placing a way across the road tagged with:

man_made=gantry
name=“whatever”
place=neighbourhood

I suppose one could add some sort of tagging indicating the vertical clearance 
that might be of use for routing.

> On Nov 30, 2018, at 3:48 AM, Joseph Eisenberg  
> wrote:
> 
> Yeah, that was how my thought process went too. Maybe there is no perfect tag 
> for these.
> On Fri, Nov 30, 2018 at 8:26 PM Warin <61sundow...@gmail.com 
> > wrote:
> On 30/11/18 20:12, Joseph Eisenberg wrote:
>> What key would you recommend, Martin?
>> 
>> Man_made=entrance_arch?
> 
> Not all are entrances, some mark the centre.
> No all are aches? An arch is a curved structure - some are rectangular .. 
> portals? That is not right either.
> 
>> barrier=...?
> no
>> Highway=...?
> ?
>> Entrance=welcome_sign?
> 
> Not a simple sign
> 
> Umm
> Man_made .. yes ...
> 
> information ... umm
> 
> 
>> On Fri, Nov 30, 2018 at 5:19 PM Martin Koppenhoefer > > wrote:
>> 
>> 
>> sent from a phone
>> 
>> > On 29. Nov 2018, at 04:27, AgusQui > > > wrote:
>> >
>> > We consider it as generic for any type of entrance arch
>> 
>> 
>> IMHO this is tagging for the renderer. You set the artwork bar incredibly 
>> low with this. Why not call them “entrance_arch” or maybe “welcome_sign”? Or 
>> even both of them, according to the situation?
>> 
>> 
>> 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 mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag named group of named water areas?

2018-11-02 Thread Tod Fitch
I prefer to have common tags on the relation. That said, in JOSM you can select 
the relation members and then easily add, update or delete a tag from all 
members of the relation.

Cheers!

> On Nov 2, 2018, at 4:00 PM, Dave Swarthout  wrote:
> 
> Of course. The Trans Alaska Pipeline is as good an example as any. It is a 
> man_made oil pipeline that stretches 1300 km across the entire state of 
> Alaska. The relation contains 280 members. The reason there are so many 
> members is because the pipeline way has been split into many individual 
> pieces, separate ways, that have certain differing characteristics, e.g. 
> where it runs underground or crosses a river on a bridge. The tagging for any 
> specific way deals with those differing characteristics. A section might run 
> for several miles underground and then emerge. At that point the pipeline way 
> must be split into a section with location=underground and the emergent 
> section with location=overground. Now it comes to a river that it crosses on 
> a bridge. The pipeline way is split again into a section that has the tags 
> bridge=yes and layer=1. You do the same thing to a highway where the number 
> of lanes changes, or maxspeed. Each change requires you to split the way.
> 
> Now say you've been tagging each piece with all the tags required rather than 
> the relation. You decide to add a Wikipedia tag to the pipeline. Using your 
> method, you must edit every piece of the pipeline, all 280 sections of it, 
> and add the Wikipedia tag. Tagging the relation with the Wikipedia entry, 
> however, requires only one edit. To make matters worse, let's just say you 
> misspelled the Wikipedia tag value. You meant to write 
> "wikipedia=en:Trans-Alaska Pipeline System" but forgot to include the "en:" 
> prefix. Back you go to your editor, editing all 280 pieces again. That's why 
> I say tagging it this way is a maintenance nightmare.
> 
> I would only use tags on a particular way when its characteristics demand it. 
> Tags that apply to the entire pipeline belong in the relation. Tags like the 
> Wikipedia tag, substance=oil, man_made=pipeline, operator, alt_name, etc., 
> belong on the relation. However, tags like bridge and location, tags that 
> apply to individual sections or ways, get applied to the ways and not the 
> relation because they don't apply to the entire pipeline.
> 
> On Sat, Nov 3, 2018 at 4:25 AM Mateusz Konieczny  > wrote:
> 2. Nov 2018 01:04 by daveswarth...@gmail.com :
> 
>  The only tags that should appear on the ways themselves are attributes of 
> those ways, for example, location=overground or location=underground, and 
> tags for bridge and layer. Everything else, Wikidata, substance=oil, 
> man_made=pipeline, etc, should appear only on the relation.
> 
> 
> I am not convinced that it is a good idea.
> 
> 
> If those tags appear on each way in addition to the relation, maintaining any 
> consistency in the tagging on this beast would be almost impossible.
> 
> 
> Can you give examples of task that you claim to be almost impossible?
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging 
> 
> 
> 
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Highway=track and piste:type=nordic, are we doing it right ?

2018-10-13 Thread Tod Fitch
In my part of the world I know of several highway=* that are closed in winter 
and used as nordic ski trails. Not just tracks, I can think of a few that are 
two lane paved roads used for general vehicular traffic in summer.

It makes no sense to me to have two OSM ways sharing the same nodes simply to 
satisfy the implementation of an editor. That is just about the same as 
“mapping for the renderer”. If iD can’t be fixed for this use case then it 
should not be used.

Cheers,
Tod

> On Oct 13, 2018, at 12:28 AM, yves  wrote:
> 
> I'd like it to be a genuine question and not attract judgements for a 
> particular editor.
> 
> For a long time, contributors map crosscountry skiing by adding piste:nordic 
> to existing highway=tracks when they follow them. That's about 66% of the 
> 68'000km of crosscountry ski trails mapped or 51165 ways.
> 
> I tried to add preset in iD editor [1] to make it easier for the contributors 
> to find the right tags for ski pistes. However, iD presets are exclusives, 
> thus if you select a highway=track and then use the 'piste' preset, the 
> highway tag is removed by the editor.
> 
> This behaviour is consistent with the good practice 'One feature, one OSM 
> element' [2], and I can hear the argument that separate geometries are easier 
> to map.After all I'd really like to attract more skiers into contributing. 
> But this is different than the mapping habits.
> 
> I'd like to hear more opinions about this, I guess the ski pistes are not the 
> only niche tags for which this question arises.
> 
> Here are the alternatives :
> 
>1) map ski pistes as separate geometries, even if they follow an existing 
> track
> 
>2) change iD behaviour, why not in a forked version.
> 
>3) accept that iD presets are not suited for this kind of mapping. Not my 
> preferred one, it's a great tool.
> 
> Yves
> 
> [2] Are preset tags exclusives?
> 
> https://github.com/openstreetmap/iD/issues/5398
> 
> [1] One_feature,_one_OSM_element
> 
> https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag named group of named water areas?

2018-10-08 Thread Tod Fitch

> On Oct 8, 2018, at 11:30 AM, Kevin Kenny  wrote:
> 
> Group relations have been proposed 
> (https://wiki.openstreetmap.org/wiki/Relations/Proposed/Group_Relation 
> ) in 
> the past. One has been used to group the Great Lakes: 
> https://www.openstreetmap.org/relation/1124369 
> 
> 
> I'm tempted to use type=group relations to group the Bisby Lakes, 
> https://www.openstreetmap.org/way/198380582 
> , the Cedar Lakes (First, 
> Second, Third and Fourth are all conflated in OSM) 
> https://www.openstreetmap.org/relation/3586769 
> , the Essex Chain of Lakes 
> https://www.openstreetmap.org/relation/3696734 
> , the Fulton Chain of Lakes: 
> https://www.openstreetmap.org/relation/195478 
> , and similar groupings, 
> because the unimaginative names of the individual lakes are, to say the 
> least, uninformative. If enough people use type=group, the renderers, 
> Nominatim, and other data consumers will eventually catch up, I suppose.
> 
> Note that US Geologic Survey topo maps have historically indicated the chain 
> names as well as the lake names, so the USGS cartographers have considered 
> both names to be significant: 
> https://caltopo.com/map.html#ll=43.87654,-74.23618=14=t=r=0.25 
>  
> shows the Essex Chain and 
> https://caltopo.com/map.html#ll=43.7229,-74.90313=14=t=r=0.25 
>  shows 
> the foot of the Fulton Chain, for instance.
> 
> I haven't tried to push this issue, because the rendering world is truly not 
> ready for it.  One of these years I'm going to want to try my hand at 
> implementing a renderer that incorporates some of the ideas of 
> https://pure.tue.nl/ws/files/88830694/labellingFramework.pdf 
>  and 
> http://geoinformatics.ntua.gr/courses/admcarto/lecture_notes/name_placement/bibliography/barrault_2001.pdf
>  
> 
>   for labeling elongated areas and groups (such as archipelagoes, mountain 
> ranges, broad rivers, and chains of lakes). Don't expect it any time soon. So 
> many projects, so little time...
> 

I had not noticed the existence of the group relation before. Seems to me that 
it and the controversial site relation have some overlap. For the examples I 
can think of where I think the site relation works it seems like the group 
relation would also work. So, at present and lacking counter-examples, it seems 
to me that one of these two relations should go away. I do not have a strong 
opinion on which but note that to me “site” implies a relatively small area 
whilst “group” does not.

Cheers!





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag named group of named water areas?

2018-10-07 Thread Tod Fitch
Perhaps a site relation. :)


On October 7, 2018 9:07:48 AM PDT, Mateusz Konieczny  
wrote:
>Lest say that we have ngroup of ponds called "Groble", with
>- a water area called "Small Pond"- a water area called "Big Pond"
>What is the best way to tag this?
>First part for obvious:
>- way with natural=water and name="Small Pond"- way with natural=water
>and name="Big Pond"- relation grouping this ways with name="Groble" and
>proper type
>But how relation should be tagged?
>Tagging it natural=water seems wrong to me - as result water areas
>would be tagged twice.
>But maybe it would be OK?
>If water is supposed to not be tagged twice - maybe use something like 
>place=water_areas? But it seems not better to me.
>Is there a good way to tag something like that?
>real example: https://www.openstreetmap.org/relation/8593489
>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] My "weirdly unnatural aversion to relations"

2018-10-02 Thread Tod Fitch

> On Oct 2, 2018, at 1:22 PM, Martin Koppenhoefer  
> wrote:
> 
> 
> 
> sent from a phone
> 
>> On 2. Oct 2018, at 17:01, Mateusz Konieczny  wrote:
>> 
>> Why selecting buildings and tagging them to site relation is easier than 
>> selecting building and adding them to  a multipolygon realation?
> 
> 
> you don’t need polygons for the site relation, you can add nodes…
> 

And on a site relation you can add linear ways.

My thought would be for a ski area. There is may an overall boundary polygon. I 
happen to volunteer at a winter sports area where there is no formal boundary 
but I do see formal boundary markers at alpine/downhill ski areas.

Within the boundary (if it exists), there are likely to be one or more interior 
polygons covering pistes/runs. For a nordic/cross country area the pistes 
themselves are likely to be narrow enough that ways rather than areas would be 
used to map them.

If there is a formal boundary and pistes wide enough to map as areas, how does 
that work? An outer polygon within an outer polygon?

There might be nodes marking locations of emergency equipment cache locations. 
And, for an alpine/downhill ski area there one or more ski lifts/aerial best 
mapped as ways.

So how do you add single nodes or linear ways to a multipolygon?

Using a multipolygon for this sounds a bit like the fellow that only had a 
hammer so everything looks like a nail to them.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

2018-09-19 Thread Tod Fitch

> On Sep 19, 2018, at 6:59 PM, Paul Johnson  wrote:
> 
> 
> An example of an interstate I would call trunk would be I 70 between I 68 and 
> I 76, given that those two are the two closest junctions.  Motorways should 
> terminate at an interchange with another motorway, not an at-grade 
> intersection…

A number of freeways in California would fail that test. Off the top of my 
head, I-280 terminating onto King Street in San Francisco [1]. US-101 
terminating on to Market [2] (actually 101 peels off a bit earlier to go up Van 
Ness). California 55 in Costa Mesa [3]. The western terminus of I-10 in Santa 
Monica [4]. I am sure there are a lot more those are just the few that I am 
familiar with that come to mind.

Cheers!


[1] https://www.openstreetmap.org/#map=18/37.77413/-122.39631
[2] https://www.openstreetmap.org/#map=17/37.77180/-122.42270
[3] https://www.openstreetmap.org/#map=16/33.6439/-117.9146
[4] https://www.openstreetmap.org/#map=16/34.0121/-118.4946


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

2018-09-19 Thread Tod Fitch

> On Sep 18, 2018, at 6:19 PM, Joseph Eisenberg  
> wrote:
> 
> So on the boundary=administrative admin_level=6 for Rogers County, we could 
> have something like maxspeed:type:default=45mph

Except that more typically there will be different default speed limits on each 
of the various OSM highway classifications. So maybe something more like 
“maxspeed:default:residential=25 mph”.

But I imagine there are other types of tags that might benefit from the ability 
to give defaults for a geographic area. So possibly it would be better to have 
“default:maxspeed:residential=25 mph” where and entire “default:*” namespace is 
created. For California something like:

“default:maxspeed = 65 mph” // State wide maximum for all roads unless 
otherwise tagged or overridden by a more specific default
“default:maxspeed:primary = 55 mph”// More specific default speed limits 
specific OSM road classifications
“default:maxspeed:secondary = 55 mph”
“default:maxspeed:tertiary = 55 mph”
“default:maxspeed:unclassified = 30 mph”
“default:maxspeed:residential = 30 mph”
“default:maxspeed:service = 15 mph”


> On Sep 18, 2018, at 10:15 PM, Mark Wagner  wrote:
> 
> . . .
> 
> The third law: RCW 46.61.400(1).  "No person shall drive a vehicle on a
> highway at a speed greater than is reasonable and prudent under the
> conditions and having regard to the actual and potential hazards then
> existing."
> 
> As a highway engineer pointed out to me recently, most county roads,
> especially unpaved ones, are designed around a speed limit of
> "reasonable and prudent".  The 50 MPH limit established by RCW
> 46.61.400(2)(b) simply sets a firm upper boundary; it's quite possible
> to get a speeding ticket at a lower speed.
> 
> Sure, you can put a number on any road.  But for most rural roads
> without speed-limit signs, the number is unrelated to how fast you can
> drive on that road.
> 

California, and I suspect most if not all other states, has a reasonable and 
prudent clause in the speed statutes too. So depending on conditions, 
especially weather conditions, theoretically you can get a speeding ticket 
while driving under the signed or prima facia speed limit.

However I think that is a diversionary argument that basically implies that we 
can’t tag any road with a speed limit because the default or signed speed limit 
can be trumped by a reasonable and prudent clause in the motor vehicle code.

I am a little curious about the highway engineer’s statement though. While not 
a civil engineer, I’ve had some interest in the field and the highway design 
books on my shelf (admittedly pretty old ones) all work off a design speed that 
is a specific number. Not a nebulous “reasonable and proper”. The design speed 
used to compute required sight distances, turn radii, ruling and maximum 
grades, etc.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] maxspeed:type vs source:maxspeed // StreetComplete

2018-09-18 Thread Tod Fitch

> On Sep 18, 2018, at 10:41 AM, Tobias Zwick  wrote:
> 
> There is a misunderstanding.
> 
> So, there are 597 towns, 77 counties and 2 councils in the state of
> Oklahoma and I understand that you want to say that all these entities
> have authority over defining the default speed limit(s) within their
> borders, right?
> But if they do set a different default speed limit for their town, then
> they will post signs for that.
> 
> What I mean with default speed limits are speed limits that apply *when
> no sign is posted*. These kind of speed limits that are known (learnt in
> driving school) by heart by drivers and usually explained in parts on
> big signboards at country borders [1].
> 
> These defaults are with very few exceptions always defined state- or
> country-wide, because, claro, noone can be expected to know the special
> default speed limit that applies only in your town/country. Even if
> there it is only signposted once at the city limits, it still counts as
> signposted - perhaps as a (large) speed zone [2].
> 

To the best of my recollection, there are no signs on the California border 
with Oregon, Nevada or Arizona stating default speed limits when you change 
jurisdictions.

It has been a long while since I have driven into or through states other than 
listed above, but I don’t recall seeing that type of signage anywhere I’ve 
driven and at one time or another I’ve driven in about half of the states.

I vaguely recall some towns and villages that had default speed signs when I 
lived “back east”. But that was the rare exception and I’ve not seen that in 
the western United States at all.

So, no: Many roads don’t have signed speed limits even if you accept a sign at 
a border potentially hundreds of miles away proper signing.

You are, I suppose, simply supposed to know the default or prima facia speed 
limits for the state or town you are going into. This is somewhat mitigated by 
the fact that the default speed limits are not radically different from one 
place to the next. A unsigned residential road might be 25 MPH or 30 MPH 
depending on the state but probably isn’t higher or lower than that. Since 
enforcement of speed laws is relatively relaxed you are pretty safe from being 
ticketed if you drive reasonably.

FWIW, at my last job one of my colleagues was originally from England and he 
noted that one of his pet peeves in driving in the United States was the lack 
of what he considered proper speed limit signage.






signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Slow vehicle turnouts

2018-09-13 Thread Tod Fitch
In California the narrow mountain roads will have “turn outs”. These are very 
short, basically just enough room for a vehicle to pull over and stop to allow 
others to pass. These are signed in advance with something like “Turn out 500 
ft ahead”.

There are also “passing lane” signs for areas where an extra lane extends long 
enough for slow vehicles to maintain their speed in the new right lane. These 
are generally signed longer in advance, e.g. “passing lane 1 mi”.

And on long grades like on the “grapevine” on I-5 between Bakersfield there are 
slow vehicle lanes marked off with a solid white line that extend for the full 
length of both up and down grades that are too steep for a loaded HGV to handle 
at the normal flat land speed limit. All the ones I can think of have reduced 
HGV speed limits.

Reading through this discussion I have the feeling that some areas have one or 
another of these features but not all three and are somehow assuming that what 
they are familiar with covers all the cases. For myself, I add slow vehicle 
lanes and passing lanes to the roadway along with any other tagging 
(maxspeed:hgv, change:lanes, etc.) And for turn outs, I either ignore them or 
put a node. Problem with a node is that the turn out is for one direction of 
travel and nodes are not good for that.

Cheers,
Tod

> On Sep 13, 2018, at 7:00 AM, Kevin  wrote:
> 
> Here in Georgia (USA) I believe we call these types of lanes "passing lanes". 
>  But that's usually only in reference to the left lane.  You generally stay 
> to the right except to pass.
> 
> https://www.dawsonnews.com/local/gdot-remove-hwy-53-passing-lane/ 
> 
> 
> Kevin
> 
> On Wed, Sep 12, 2018 at 6:21 PM, Dave Swarthout  > wrote:
> >You say "turnout".  But physically, is it just an additional lane that
> >appears, and (more or less) one is obligated to move right one lane into
> >it if you're in the way?
> 
> Exactly. I explained this several posts ago. It is an additional lane, 
> running for perhaps a quarter mile, sometimes longer, that any vehicle which 
> is holding back some number of other vehicles is obligated to use so that 
> those following vehicles may pass. The reason I used the term "turnout" is 
> because the signage erected by the Alaska DOT uses that term, as in, "Slow 
> Vehicle Turnout Ahead 1500 feet".
> 
> I see polyglot is ready to add some sort of processing to JOSM's PT_Assistant 
> plugin if only we can decide what to call such lanes in OSM. I think the term 
> slow_vehicle would work just fine.
> 
> Dave
> 
> On Thu, Sep 13, 2018 at 12:11 AM Jo  > wrote:
> A few months ago bus_bay=left|right|both was voted. For me this is similar, 
> albeit over a longer distance.
> 
> extra_lane_for_slow_moving_traffic_to_compulsory_halt_to_let_other_traffic_pass_by=left|right|both
>  ?
> 
> If you figure out which tag to use, we'll add it to the double split map mode 
> of JOSM's PT_Assistant plugin.
> 
> Polyglot
> 
> Op wo 12 sep. 2018 om 18:49 schreef Greg Troxel  >:
> 
> > Again, I emphasize, this is not a crawler lane or a hill climbing lane. It
> > is a lane into which one pulls over to allow faster moving traffic to pass.
> > In fact, Alaskan law demands that any vehicle being followed by 5 vehicles
> > must, at the first opportunity, allow those vehicles to pass. I doubt
> > anyone has ever been ticketed for this offense but nevertheless, the law
> > exists. Alaskan highways also have hill climbing lanes that are signed
> > "keep right except to pass". Those lanes are not the same as this one.
> 
> Sorry, didn't get that this is not climbing lane (my fault).   In New
> England, extra lanes that one would associate with "slow vehicle" are
> 99% on hills.
> 
> > Perhaps "slow_moving" isn't the best term for this sort of highway turnout
> > but it does the job.
> 
> You say "turnout".  But physically, is it just an additional lane that
> appears, and (more or less) one is obligated to move right one lane into
> it if you're in the way?
> 
> Do any routers do anything?  An example of how the data would be used,
> or how you think it would be used in an ideal future might be
> illuminaing.   Perhaps one's car computer could notice from forward
> radar that there is obstructing traffic and query osmand and give you a
> notification that the road becomes multilane in some distance, so you
> can get ready to blink to get the obstructor to move over if they stay
> left?   In that case, I wonder about the difference between a change to
> two lanes (perhaps because the row is wide enough and the long-term plan
> is 2) and a specific place like you describe.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging 
> 

Re: [Tagging] wiki modification landuse=meadow definition

2018-09-02 Thread Tod Fitch

> On Sep 2, 2018, at 5:41 PM, Martin Koppenhoefer  
> wrote:
> 
> 
> 
> sent from a phone
> 
>> On 3. Sep 2018, at 02:31, Warin <61sundow...@gmail.com> wrote:
>> 
>> The land is not used by/for  'meadow'.
> 
> 
> it is used as a meadow
> 

There are natural meadows within the forested areas in the mountains near me. 
At least they look like the typical images I see of meadows and the locals call 
them meadows. The use is exactly the same as the use of the surrounding forest: 
Recreation, wild life management, etc. What is the “use” of a meadow that makes 
it a meadow rather than, say and area of un-mowed, un-grazed herbaceous flowers 
and grasses?

For what its worth, I’ve been tagging them with landcover=grass though that is 
not exactly correct and it is not purely grass as there are usually a bunch of 
flowing plants intermixed.

Cheers!




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

2018-08-06 Thread Tod Fitch
In my area there are signed routes for tsunami evacuation. Very unlikely that 
they will change for an individual event. And the are ground verifiable as they 
are signed. I think these can and should be mapped in OSM.

There are also wildfire prone areas near by. Evacuations from those are ad hoc. 
They vary from incident to incident and are unsigned. I don't believe these can 
or should be added to OSM.


On August 6, 2018 11:55:18 AM GMT+05:45, Graeme Fitzpatrick 
 wrote:
>One thing that concerns me a little bit with marking evacuation routes
>is
>what happens if the normal route is changed for "this" emergency? - you
>usually drive North to reach here, but this time, due to unusual
>circumstances, we need you to drive West towards there.
>
>Or am I being *too* paranoid? :-)
>
>Thanks
>
>Graeme

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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


Re: [Tagging] Missing access value (access=license / authorization?)

2018-07-26 Thread Tod Fitch

> On Jul 26, 2018, at 5:45 PM, Kevin Kenny  wrote:
> 
> The only outcome of that thread - and several threads on the same
> subject that preceded it - was that there was no consensus.

I’ve been following the talk and tagging lists for a couple of years now and 
don’t think I’ve seen consensus on anything.

My take is to toss an idea/problem into the list and see if there is anything 
that comes back in the first few days that alters your opinion on how to tag. 
Sometimes there are good suggestions that can improve your thinking on how 
something should be tagged so it is worth submitting. Just be prepared to read 
and delete a myriad of email that is basically bike shedding by people who seem 
to have never been out of their cultural home area.

Then just go for it and tag things. Better if you document your tagging, at 
least as a proposal.

> On Jul 26, 2018, at 6:15 PM, Warin <61sundow...@gmail.com> wrote:
> 
> Just use the tag. 245 in the data base now.
> 
> As for fees they can be tagged with fee= tag
> As for the permit conditions .. well you could just tag permit=*
> 
> I'd just do it. Overpass turbo shows a wide distribution around the world.
> It makes much more sense that some tags already on the wiki.
> 
> I may well add it to the wiki, documents tags in the data base. While small 
> in number it does show what they are about and may help others to use them 
> appropriately rather than inappropriately or just ignore them through 
> ignorance.
> 
> 

I haven’t bother to check, but if there is a world wide distribution of people 
who have decided that access=permit makes sense then I agree that it a good 
thing to document it on the wiki.




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] tagging religion-based access

2018-06-29 Thread Tod Fitch
Maybe something like

access=no
muslim=yes

better fit the existing schemes for tagging access?


> On Jun 29, 2018, at 11:27 AM, Mateusz Konieczny  
> wrote:
> 
> I thought about muslim_only=yes tag.
> 
> 
> 27. Jun 2018 12:50 by matkoni...@tutanota.com 
> :
> 
> Is there some established way to tag religion-based access restrictions?
> 
> For example in Morocco only Muslims may enter a typical mosque.

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


Re: [Tagging] shop=discount

2018-06-25 Thread Tod Fitch


On June 25, 2018 8:12:33 AM PDT, Mateusz Konieczny  
wrote:
>
>
>
>24. Jun 2018 22:17 by dieterdre...@gmail.com
>:
>
>
>>
>>
>> sent from a phone
>>
>>> On 24. Jun 2018, at 22:00, Mateusz Konieczny <>>
>matkoni...@tutanota.com >> > wrote:
>>>
>>> It sounds like any type of shop may have discount shop variation.
>>
>>
>> usually the term discount shop refers to shops selling food “from the
>pallet”, i.e. a smaller selection and less laborious presentation,
>tending to bigger packages, for a cheaper price.
>> Sometimes also with supposed inferior quality. Nowadays also
>typically sell occasionally selected non-food stuff according to the
>season (like tools, clothing, toys, even electronics like 1 laptop or 1
>phone), but usually only from 2-3 boxes, it does not take significant
>space.
>>
>
>
>
>
>So it is shop=convenience that is selling “from the pallet” and is
>likely to be a cheaper?

In my area convenience stores are relatively small with a limited choice of 
products with the defining feature being that they are open more hours than a 
typical store, often open 24x7.

Usually the prices are higher at a convenience store, not lower.



-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] emergency=lifeguard

2018-06-21 Thread Tod Fitch
Graeme Fitzpatrick graemefitz1 at gmail.com  

Wed Jun 20 02:13:47 UTC 2018

> So the photos on
> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_tower 
>  &
> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dlifeguard_platform 
> 
> would be your sort of mobile towers?
Sorry, I must have deleted the email from this thread from my reader so am 
replying to the archived version. I am guessing this email will start a new 
thread.

I have uploaded some photos that show the types of lifeguard facilities near me.

First is the headquarters building [1]. I don’t see any particular reason to 
include it in any emergency tagging scheme. While it is locally called the 
“clock tower” and is sometimes used used as an identifiable point for meeting 
people, near as I can tell emergency response does not directly come from there.

Second is the year round staffed tower located just off the beach on the pier. 
[2] This is a permanent structure currently tagged with building=yes and 
emergency=lifeguard_tower.

Third is one of the stations on the city beach [3]. This one happens to remain 
in place all year as it is the marker for how close swimming is allowed to the 
pier. But you can see by the design that the whole structure can be moved and 
some of other stations/towers on the beach are moved to safer locations to 
survive winter storms. This particular station/tower is not on OSM at present 
largely because I was unsure about how to tag it.

Forth is one of the near by state parks beach [4]. Similar concept to the city 
version but different construction materials, etc. Some of these are also moved 
to safer locations during the winter.

Again, the towers that are moved to safer locations during winter are all 
replaced in the same place each summer. At least close enough to the same place 
that it probably doesn’t make much difference for OSM. I can see a desire to 
distinguish between a movable lifeguard tower and one that is very definitely 
not designed to move but don’t have any good ideas on how that might be tagged.

Cheers!

[1] 
https://wiki.openstreetmap.org/wiki/File:San_Clemente_lifeguard_headquarters.jpg
[2] https://wiki.openstreetmap.org/wiki/File:San_Clemente_Lifeguard_Tower_2.jpg
[3] https://wiki.openstreetmap.org/wiki/File:San_Clemente_Lifeguard_Tower_1.jpg
[4] 
https://wiki.openstreetmap.org/wiki/File:California_State_Parks_lifeguard_tower.jpg___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] emergency=lifeguard

2018-06-19 Thread Tod Fitch

> On Jun 18, 2018, at 9:23 PM, Graeme Fitzpatrick  wrote:
> 
> On 19 June 2018 at 08:45, Graeme Fitzpatrick  <mailto:graemefi...@gmail.com>> wrote:
> 
> That's the concern I have with "place" - our lifesavers operate out of a surf 
> club, a permanent building behind the beach (lifeguard=base). Each morning, 
> they will decide the safest part of the beach, so will set up 200 m's right 
> of the club this morning, but tomorrow they may be 100 m's left - that 
> shouldn't be a lifeguard=place
> 
> Just had a thought as I'm starting to work on a wiki page.
> 
> Could we use lifeguard=area (or similar) to show that there is a lifeguard on 
> duty somewhere in this area, but not at an exact location, or too messy?
> 


FWIW, I volunteer on a back country ski patrol (winter rescue) and while we 
have a building we use as our base of operations the areas we patrol are very 
dependent on snow pack and where we notice people going to. Your concept of 
lifeguard=area could possibly be applied to our situation. That said, mapping 
an exact boundary of the area served would be very problematic: Unlike a 
developed ski area there are no signs indicating you are leaving the the 
official boundaries. It is, after all, undeveloped “back country”.

The boundary issue may also apply to lifeguards on the beach: Both to the north 
and south of the beaches in the town I live in there is no clear demarcation of 
where the area served ends (no signs, etc.). Having a few years of observation 
and having talked to some of the year round lifeguards, I have a general feel 
for the areas but not exact enough to map.

And it may well be seasonal: Most of the lifeguards work only in summer as that 
is when the crowds are largest and the city (local beach by me) and the state 
(beaches to the north and south of the city) save money by having a greatly 
reduced staff and thus coverage in the off season.

> On Jun 18, 2018, at 11:52 PM, Graeme Fitzpatrick  
> wrote:
> 
> On 19 June 2018 at 08:34, Tod Fitch  <mailto:t...@fitchdesign.com>> wrote:
> 
> Might want to check if there is some sort of tag indicating seasonal before 
> removing from the map.
> 
> On the beach near me many of the lifeguard structures are built on what 
> amounts to a sledge and are dragged to storage at the end of the summer 
> season. In summer they are placed in the same locations each year, if nothing 
> else so that the communications and power connections don’t need to be 
> relaid. But even if they don’t need power and communications, the visitor use 
> patterns remain fairly constant so the location of lifeguard 
> stations/towers/structures remains fairly constant.
> 
> In any even, depending on the season the aerial imagery was taken you may see 
> only an empty stretch of beach. Or you may see what looks like a small 
> building from above.
> 
> Thanks Tod - sorry, I missed your post earlier.
> 
> I haven't seen any seasonal tags on any of the stations I've looked at so far.
> 
> A portable tower that get's put away over Winter then goes back in the same 
> spot next year is a new one on me, but could well explain some of the shots 
> that appear to show a structure, which then isn't there in other shots. What 
> area are you in?  
> 

Southern California. Two things probably contribute to the local practice: Lack 
of crowds during winter and winter storms typically do the most damage to beach 
side facilities. I am not even sure that other beach towns near by follow the 
same practice, only that the town I live in does.

Cheers!


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


Re: [Tagging] The endless debate about "landcover" as a top-level tag

2018-06-07 Thread Tod Fitch

> On Jun 7, 2018, at 11:13 AM, Michael Andersen  wrote:
> 
> For many years now I've been pretty happy to use landuse=forest pretty much 
> everywhere I found a group of trees. Yes, in some cases the semantics irked 
> me 
> a bit, but landuse=forest always rendered fine. I used what worked for me.
> 
> On many occasions however I've seen newbies remove or retag landuse=forest 
> areas as the very first thing they do after registering. "It's not a forest" 
> (whatever that means) they argue, even if the area in question is completely 
> covered with trees and sometimes even has "forest" as part of the name. On 
> some occasions it's been a real hassle trying to explain that landuse=forest 
> basically just means that the area is covered by trees, no more, no less, and 
> that we use it because this is what renders, not because the semantics are 
> perfect. 
> 
> So what I'm trying to illustrate is that while I'm happy to use 
> landuse=forest 
> myself, I do see a practical problem with it; Newbies taking it a bit too 
> literally. If landcover=trees would render, I imagine it would make my job a 
> lot easier.

Your use of landuse=forest is exactly opposite of my interpretation of previous 
discussions on this email list.

I happily started out tagging areas covered with trees as landuse=forest until 
there was a long thread here about how that was incorrect. There was a very 
vocal contingent that stressed that landuse=forest was for areas being managed 
to produce wood products and that one ought to use something like natural=wood 
if one simply wanted to show there were trees on it.

And then I came across areas that were tree covered but definitely not natural 
and not something that should be tagged as an orchard, etc. This has led me to 
prefer landcover=trees and landcover=* in general to describe what I see on the 
land without worrying if it is natural or not.

Now, for tree covered areas I use:

natural=wood
landcover=trees

I feel that the natural=wood is tagging for the renderer but I do it anyway. 
And I feel that landcover=trees is a more accurate description of what is there 
and hope that someday it will be rendered on the standard map.

Cheers!






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


Re: [Tagging] Feature Proposal - RFC - scenic

2018-06-02 Thread Tod Fitch

> On Jun 1, 2018, at 1:08 AM, Mateusz Konieczny  wrote:
> 
> 31. May 2018 23:50 by pame...@web.de :
> 
> Hi there,
> 
>  
> I would like to propose an new map feature and would like some comments. The 
> page can be found here:
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/scenic 
> 
> 
> Seems to be deeply subjective. Very, very subjective. Probably so subjective 
> that untaggable -
> 
> I expect that different people would have wildly different opinions here and 
> in cases
> 
> that are indisputable it may be possible to generate such classification from 
> existing data.
> 
> 
> 
> BTW,"grade" tags were horrible mistake for tracktype, it is horrible 
> to 
> 
> remember difference or even whatever grade1 is worst or best.
> 
> 
> 
> "(Will integrate pictures if somebody tells me how and where to upload, 
> because I get apierrors or missing rights)"
> 
> 
> 
> Are you the author and willing publish them under an open license?
> 
> 
> 
> Use https://commons.wikimedia.org/wiki/Main_Page 
> 
> 

I don’t know about hiking paths, etc. But the state I live in has signed a 
number of vehicle highways with scenic route signs. [1] At least in that case, 
there is an objective criteria for tagging, though not with the a level value 
as suggested. I’ve not gotten around to deciding what tagging I’d put on the 
officially designated scenic routes but assumed it would be scenic=yes on the 
various qualifying segments. Based on this thread, perhaps that might be better 
signed_scenic=yes.

Another similar thing, again for automobile roads, the national park service 
has some historic routes signed showing the way early explorers traveled prior 
to modern development. [2][3] I assume that would be tagged using a route 
relation. The written description of the exact routes are confusing enough, at 
least to me, that I think an on the ground survey would be needed to properly 
map them.

[1] https://en.wikipedia.org/wiki/State_Scenic_Highway_System_(California)
[2] https://www.nps.gov/juba/index.htm
[3] 
https://commons.wikimedia.org/wiki/File:Juan_Bautista_de_Anza_Trail_California_signage.jpg


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


Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

2018-05-29 Thread Tod Fitch

> On May 29, 2018, at 4:36 AM, Martin Koppenhoefer  
> wrote:
> 
> 
> 
> sent from a phone
> 
>> On 29. May 2018, at 12:50, Andrew Davidson  wrote:
>> 
>> assuming that people would think that natural=wetland + stream=ephemeral 
>> would look odd--otherwise no need for a new key).
> 
> 
> on which kind of object would you tag this? Usually a stream is mapped on a 
> linear way, a wetland on an area.
> 

There are also springs that are perennial, seasonal, intermittent, etc. Wiki 
shows those as being mapped as either points or areas.

It might be generally useful to have a tag that can be used for more than just 
water features. One example: I know of a place where portable toilets and trash 
bins are located every year for the winter sports season and removed in spring. 
I don’t know of a way to map those. Opening hours doesn’t work as that is for 
places that exist all the time but only are open during specified hours. A 
generic tag indicating when the feature is likely to be present could be used 
for both water features and other non-water features.



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


Re: [Tagging] Seasonal, intermittent, and ephemeral water tags

2018-05-26 Thread Tod Fitch

> On May 26, 2018, at 12:02 AM, Warin <61sundow...@gmail.com> wrote:
> 
> My take  for water bodies:
> 
> Perennial: I expect to find water here at any time. Exceptions: drought
> 
> Seasonal: I expect to find water here on a yearly cycle, usually for months. 
> Exceptions: drought
> 
> Intermittent: I don't expect to find water here. Exceptions: heavy rainfall 
> or snow melt. The water could be here for some time .. up to 2 months. 
> 
> Ephemeral: I don't expect to find water here. Exceptions: heavy rainfall or 
> snow melt. The water can only be here for a short time .. less than a week, 
> usually a day or less.
> 

Those definitions match up with my understanding. So something like

waterway=* (or natural=spring | water )
presence=perennial | seasonal | intermittent | ephemeral

If the presence is seasonal, then the existing seasonal=* could be used to 
describe what times of year the item is normally present.


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


  1   2   3   4   >