Re: [Tagging] [Talk-us] Heavily-wooded residential polygons

2020-06-04 Thread Greg Troxel
stevea  writes:

> We agree.  The issues are both around the different behavior of the
> (Carto) renderer when both landuse=residential and natural=wood are
> combined (and there are highly complex ways they can be and are
> "combined" in the OSM database), and around how mappers understand
> these data should be entered.  Should both natural=wood and
> landuse=residential be "stacked" as two tags on one (multi)polygon?

I would say probably not, as it is highly unlikely, really entirely
unlikely, that an extent of landuse=residential, determined by
aggregation of property with similar use, lines up exactly with an area
that is covered by trees.

> That was and is widely done in cases where heavily-wooded residential
> polygons exist, though a "better" trend (at least around here) is to
> break these apart into two polygons: one explicitly on the
> landuse=residential polygon (glom of parcels which are residential, to
> the area extent where they are), one on the polygon defining the
> extent of natural=wood.

Yes, this is sensible.  Two areas, entirely disconnected spatially, each
defining the area where their property applies.

> Unfortunately, Carto doesn't easily (it does consistently, but the
> rules are complex, having to do with sizes of the underlying polygons)
> render these consistently, requiring frequent "fiddling" by craft
> mappers who are looking for both a desired effect and a visual
> semiotic which richly and accurately conveys what is going on: heavily
> wooded residential landuse.

THat's what I meant by suboptimal, which was a polite word: If there is
semantic markup of "this area is residential landuse" and "this other
area is covered by trees", then the rendering rules should do the same
thing regardless of the precise form of the relation/polygon/etc.  It is
a bug if anyone needs to walk on eggshells to make it come out right.

I don't mean in any sense to say "the people that do Carto are bad
people".  This seems incredibly hard to get right and I don't know how
to fix it.  I just mean that it is a failure of software to be ideal and
a place for improvement, in a descriptive and non-judgemental way.

>> The basic problem here is that it's pretty straightforward to render a
>> map that primarily shows landuse, and it's pretty straightforward to
>> render a map tha primarily shows landcover.  What carto does, and what a
>> lot of people want, is a way to show both of them.
>
> I wouldn't necessarily call it a "basic problem," more like the desire
> of "let Carto display both" doing so in complex ways, which gives rise
> to "well, what are the best practices here?"

I think we agree; I'm saying that designing rendering rules that show
land use and land cover at the same time is 1) hard and 2) beyond what
is typical in cartography.  In other words, the "what are best
practices" question you pose don't have an easy, consistent answer.

>> I would suggest that if tagging heroics are needed there is something
>> suboptimal in the renderer.  I think renderers probably need fancier
>> code to choose which of landuse/landcover to emphasisize depending on
>> local scale.  Or a deconfliction of symbology.
>
> Yes, heroics are sometimes employed, yet even that isn't always enough
> (it is often, but not always).  "Suboptimal" might be too damning, as
> I don't think it is "deficiencies" in the renderer, rather I think
> there are "projected expectations" of the renderer (that it appears
> Carto CAN render "both," so it SHOULD, and it DOES, but in
> sometimes-confusing ways).

I don't know if you are just trying harder than me to be nice, or if we
really see this differently.  I see a rendering plan like a
specification, something like "an area that is both landuse=residential
and natural=wood should have a 40% gray fill with a stipple of tree
icons at 20% green" (making that up, details not the point).  Then,
areas that are covered by each should be like that.  And  the exact form
of tagging should not matter, and people should not feel motivated to
mess around with tagging form to make the renderer work.  Otherwise,
it's a bug to be fixed.  Again, this is hard and I get it that people
with limited time are working on it.

> This is an example of amazing, sometimes
> beautiful things going on in the renderer "driving" whether and how
> OSM should and does enter data.  Yes, there is some "coding (data and
> tagging) for the renderer" going on, but it appears to be in the best
> longer-term interests of good data entering, not simply and only for
> the same of "pretty renderings."  I believe we can get there, an
> attempt to discuss "best practices" (I'll settle for "better
> practices" for now!) is a step in that direction.

As always, there is the question of whether people are really coding
tagging for renderer behavior that is not justified, or whether there is
a sensible semantics in between taggers and interpreters.  I feel like
you have arrived at having to walk on eggshells to make it 

Re: [Tagging] [Talk-us] Heavily-wooded residential polygons

2020-06-02 Thread Greg Troxel
stevea  writes:

> As I mentioned to Doug I exchanged a couple of emails with
> user:jeisenberg (a principal contributor to Carto) about what was
> going on with some examples of this, and Mr. Eisenberg explained to me
> (in short) that it is a complicated ordering (or re-ordering) of
> layers issue, both Doug and I continue to scratch our heads about what
> "best practice" might be here.  (For "heavily wooded residential"
> polygons, which are frequent in Northern California).  While Doug and
> I both tend towards the preference of the "superimposed look," it is
> not always simple to achieve, due to complexities in the renderer and
> data/tagging dependencies.  And, Doug and I are certainly aware of
> "don't code for the renderer."  However, given that Doug and I are
> fairly certain that others have noticed this, but aren't certain that
> others know what best to do (we don't, either), we ask the wider
> community "what do you think?" and "What are best practices here?"

Agreed this is really hard.

First, I'm going to assume that polygons for landuse=residential do or
are intended to align with property boundaries.  I'm also going to
assume that natural=wood aligns with the actual location of trees, which
is (in mass) almost always not aligned with property boundaries.  I have
thought it an error to have natural=wood tagged on a polygon that shows
conservation land, as the adjacent non-conservation land almost always
similarly has trees (around me).

I would suggest that perhaps a "this land has some trees" landcover tag
(cover != use, strongly agreed) may make sense.  I am not sure you are
talking about this, or not.   I find natural=wood to imply that the land
has none to very little built structures, mostly trees, and the usual
understory plants.   I would definitely not want to use this tag on an
landuse=residential area with houses, but I might use it on the rear
parts of a housing area that are basically trees.   I also would not
want to stop at the subdivision line.

The basic problem here is that it's pretty straightforward to render a
map that primarily shows landuse, and it's pretty straightforward to
render a map tha primarily shows landcover.  What carto does, and what a
lot of people want, is a way to show both of them.

I would suggest that if tagging heroics are needed there is something
suboptimal in the renderer.  I think renderers probably need fancier
code to choose which of landuse/landcover to emphasisize depending on
local scale.  Or a deconfliction of symbology.

To have a way forward, I think we need a coherent design for a style
(not code, but an articulation of how it ought to work, first) that uses
some kind of symbology for landuse and some other kind for landcover.
I naively lean to solid fill, tending to lighter shades, for landuse,
and stipple patterns for landcover.  I think this is what you are suggesting.

It is interesting to think about the 80s USGS topo maps, and surely also
interesting to look at other traditional maps for inspiration.  The USGS
ones were primarily land cover and very little landuse.   But they did
have a gray "house omission tint" in built-up areas, which I'd say is
"this area has many buildings" and is sort of landcover, even though
it's a proxy for landuse.

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


Re: [Tagging] RFC ele:regional

2020-05-08 Thread Greg Troxel

On 2020-05-08 11:33, Martin Koppenhoefer wrote:

It could be useful when mapping something like a building. You could 
establish a certain elevation as local zero (e.g. the elevation of the 
ground floor) and have all other levels based on this. It is something 
that could also not be needed because of an editor who abstracts this 
(no need to store relative information if some frontend could do it), 
but I would not hinder people from experimenting with it.


I can see wanting to do this, but I think it should not use the ele= 
tag, and this really feels like it needs to be "height above ground 
floor" or something.   It really needs a scheme that is well thought 
out.   I too think it's fine if people do this, as long as they don't 
use the ele= tag, which means something else.




 > ele:regional is about admitting that you don't know

But, it asserts that the value is in some particular datum, and that you
can tell which one from knowing the area.   All of this is untrue.

maybe a particular datum can not be given, but you can be quite sure (as 
sure as you are willing to accept from a tag which pretends it is) it is 
one of those common in the area (which also will not differ a lot, 
probably).


I think we now know that the existing datums don't differ much from 
WGS84 except Belgium, and given the EVRF2007 datum, it seems clear that 
Belgium now will have that and the old one, differing by 2m.

Hence the thing we need to know, we don't, in this case.

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


Re: [Tagging] RFC ele:regional

2020-05-08 Thread Greg Troxel
Martin Koppenhoefer  writes:

> I was not aware there weren't any meaningful differences (when comparing
> some official height references to the German DHHN92 those in wikipedia.de
> with delta information all are within 1m besides Belgium DNG/TAW, which is
> -2.3).

Thanks for looking into this.  It is interesting about Belgium's datum
being so far off, but I'm sure there's some long-ago historical reason
and various datums along the way matched some earlier datum.   Perhaps
relating a nautical datum (tends to be mean low water) with a land datum
(tends to be mean sea level).

> Maybe all we should do is clarify that we are NOT expecting
> ellipsoid heights in ele tags (leaving open the possibility to add
> ele:datum tags)?

I would very much like to clarify that, and it feels like we have
consensus on that point.  I can edit the wiki page to make it clearer,
since we have had a big discussion and there is no one advocating for
ellipsoidal height in OSM.

I am ok with some text about the possible future use of ele:datum to
refer to some other datum, although I think it's preferable for people
to transform, just as it is for horizontal.

> WGS84 uses a 2 dimensional ellipsoidal coordinate system?

WGS84 at its core is a 3-dimensional cartesian system, written XYZ, with
the origin at the center of mass of the earth.  There is a transform to
latitude, longitude, and ellipsoidal height (which is just math and not
a source of errors).   All modern datums are like this.  Note that WGS84
is essentially the same thing as ITRF2014, the current international
datum from the geodesy (since of measuring the earth) community, perhaps
differing by a few mm, perhaps not.

> Wouldn't "natural" height information be based on this ellipsoid? I'm all
> fine with stating we should use geoid heights, but it doesn't necessarily
> seem to be implicit.

It does need to be made clear, as there is ample reason to think there
has been confusion about it in OSM.


ellipsoidal heights are not natural!

To understand this, one has to look to the history of surveying.  Until
the satellite era, horizontal datums and vertical datums were basically
separate.  Horizontal was done by maesured baselines and triangulation.

Vertical was done by 'leveling' which is basically a telescope with a
bubble level, so you transfer horizontally from one place to another,
and then read the difference on a rod, which is basically a giant
measuring stick.  As you move from a tide gauge across a continent, you
keep track of the accumulated differences (and loops, and then you do
least squares).

Implicit in leveling is that two places at the same height are at the
same gravitational potential, and that when you say "height is x m" you
mean that if you measured vertically (along the plumb line) it was x
until you got to where the ocean would flow to if there were a tunnel.
So height as surveyors used it, and the national/regional datums taht
this height is referenced too, have always been about gravity, and the 0
reference level has more or less been at some notion of sea level.
Typical is the mean reading of a tide gauge over 19 years (a sun/moon
cycle).

NAVD88 is referenced to a single tide gauge at Father's Point in
Rimouski, Quebec.  NGVD29 set a number of tide gauges around the
continent at 0 (and this caused distortions).

Satellite techniques just measure position and distance, and not
gravity.  Thus they in their raw form give you ellipsoidal height.  But,
this is not useful for water engineering, because lower elllipsoidal
height is not downhill.  So WGS84 defines a "geoid model" that gives the
height of an equal-gravity surface that more or less corresponds to mean
sea level, compared to the ellipsoid, and except for 1) some buggy
android programs and 2) survey-grade GPS equipment, all GPS (GNSS,
GLONASS, Galileo, BeiDou, etc.) receivers give altitudes in height above
the geoid, because aligning (at the meter level) with the previous
national height datums is important, and having water flow to lower
elevations is important.  And because nobody except national-level
surveyors has ever cared about ellipsoidal heights.

Ellipsoidal heights are basically used only as internal steps in
surveying, and nobody in the surveying world would ever think to put
them on a sign, or say to the public "the ellipsoidal height of Mount
Washington is X".  (A datasheet for surveyors would say that, but it
would also give the NAVD88 height.  A poll of 1000 surveyors asking
"should we put ellipsoidal height or NAVD88 on the sign" would result in
all 1000 of them looking at you like you were crazy and saying "NAVD88,
of course".)

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


Re: [Tagging] RFC ele:regional

2020-05-08 Thread Greg Troxel
Colin Smale  writes:

> As I mentioned before, the national datums of the Netherlands and
> Belgium differ by over 2m, which for everything connected to water is
> very significant. Waterways often form the border, with bridges that
> cross the border. You cannot use a map/chart (at last for tidal waters)
> if you don't know what datum it uses. 

Thanks.  2m is perhaps significant, and I'm surprised it's that much.  I
would suggest that if people care about that 2m, then they need to
transform to a common height reference.

I would expect that Europe is working on a new satellite-native regional
height system, similar to the new 2020 in Australia and the 2022 one in
North  America, that will basically align heights.

> In OSM we often leave out "obvious" annotations, giving rise to a kind
> of "default" (such as maxspeed in km/h). But there is always a way of
> making it explicit, for those who feel the need. In this case we may
> agree to define "ele" as relative to the "local datum" or WGS84 or
> whatever, but we must always provide a system for making that explicit,
> and (preferably) a means to derive the intended basis for values that
> are not explicitly qualified.

So what do you think about what I've been saying:

  ele is assumed to be in, and should be represented in, WGS84 height
  above geoid (as the international norm, aligned with OSM's horizontal
  datum)

  ele:datum=unknown represents that the mapper doesn't know what datum
  the number they put in ele is expressed in

  ele:datum=EPSG:5703 (as an example for NAVD88), when the mapper really
  does know the datum, and doesn't want to transform to WGS84


I assume you are referring to:

  https://epsg.io/5709

  https://epsg.io/5710

and it seems that the European more modern height datum has already
happened:

  https://epsg.io/5730 (superceded)
  https://epsg.io/5621 (European Vertical Reference Frame 2007)

This looks useful:

  http://euref.eu/documentation/Tutorial2015/t-04-01-Liebsch.pdf

And this all makes me think that an elevation without a datum cannot be
reliably used at the better than 2m level.

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


Re: [Tagging] RFC ele:regional

2020-05-08 Thread Greg Troxel
Martin Koppenhoefer  writes:

> Am Fr., 8. Mai 2020 um 03:26 Uhr schrieb Greg Troxel :
>
>> The notion of "local" has the same problem, and it is also a poor choice
>> of words in that in surveying, "local", refers to coordinate systems
>> established for particular projects or surveys that have no lasting
>> significance.
>
> the "definition" for "ele:local" (in German language on the English talk
> page of the tag) seems to be about this: a local datum based on a local
> reference (i.e. not the same as ele:regional). I am not in any way involved
> in ele:local, just wanted to point it out.

That does sound like what I mean by local.   I would say that heights in
such local systems should not be entered into OSM, and I would find
their use in anything tourist-facing to be very strange.

>> Basically, either you know what datum an elevation is in, in which case
>> you can 1) transform it to WGS84 height above geoid or 2) label it
>> correctly, or you don't know, in which case you should simply *admit
>> that you do not know*.

> ele:regional is about admitting that you don't know

But, it asserts that the value is in some particular datum, and that you
can tell which one from knowing the area.   All of this is untrue.   In
contrast "ele:datum=unknown" is a crisp statement that you don't know
the datum, no more and no less.

As for guessing about regional, data consumers can guess too, but
encoding a guess in a vague way seems really unhelpful.

>> I would also ask: if this is reasonable for height, why isn't it also
>> reasonable for horizontal coordinates?
>
> because we typically have much more horizontal positional information with
> which we can compare. Errors in horizontal position are more evident
> because the relation to the surrounding (alignment, reference, angles,
> axis, proportions, etc.) won't fit. Up to a certain degree (e.g. when other
> information around is missing, and when accurate positional information is
> missing) we also do have and tolerate very approximate horizontal spatial
> information.

I'm talking about things like NAD83 vs WGS84, which is basically a 1m
difference around me.   We either transform or accept the fuzz, but it
would be crazy to label points as being in NAD83.  That's really my point.

> Greg, you wrote we should convert locally signed regional datum elevation
> information to the WGS84:geoid reference. In other context, we do not do
> unit conversions, for example we do not convert speed limits in mph to kph,
> nor do we convert weight information or maxheight information.

This isn't really about units.  Datum is about point of reference, and
the "don't convert" argument applies equally well to horizontal datums.

As I said before, if you want to put something like

information=board
inscription="Mount Washington // Elevation 6288 Feet"

that's totally fine.

> I could imagine doing a "reasonable" conversion (precision the same as
> expected from the original value) if there would be support from the
> tools (e.g.  mobile editors, iD or Josm), but otherwise I would not
> expect the vast majority of mappers doing this conversion at all in
> case of a value read off a sign, and even if they did I would expect
> this conversion step to be error prone (e.g. the mapper won't know
> which is the original datum).

I agree that casual mappers doing conversions is likely too much.

However, I don't see the harm in just entering a signed elevation in
ele= and not worrying about it, or also adding ele:datum=unknown to
represent that the data is not known to have been handled accurately.

My primary objection is not about having a tag to say the datum is
unknown.  What I really don't like is:

  the notion that it is a desired state to have elevations in other than
  the standard OSM datum, and that all data consumers should have to deal
  with this

  any notion that HAE is reasonable in OSM

  marking something as "regional" as if that is clear, when the reality
  is "unknown".  (If I come across a sign in the US with elevation, even
  I, as an elevation nerd, have no idea if it's NGVD29 or NAVD88, or if
  it's just plain bogus, with the number being copied from someone else
  who didn't really know either.)


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


Re: [Tagging] RFC ele:regional

2020-05-08 Thread Greg Troxel
Martin Koppenhoefer  writes:

> Am Fr., 8. Mai 2020 um 03:22 Uhr schrieb Greg Troxel :
>
>>   3) Look up the data sheet and mark it as ele:datum=NGVD29 or
>>   ele:datum=NAVD88 as it turns out.
>
> IIRR, in another mail, you wrote that the difference between these 2 is
> less than a meter, can you confirm this, or did I understand you or
> remember wrong?

Yes,it typically is.

So let me ask you again, since you keep declining to answer this:

  Please give an example of an elevation of a real thing that is
  meaningfully different in one of these "regional datums" (established
  by a country's survey agency) compared to WGS84 height above geoid.
  Identify the regional datum, and identify two values linked with a
  rigorous transformation (such as national survey agencies publish).


Thus far, you have not established that there is an actual problem that
needs to be solved.

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


Re: [Tagging] RFC ele:regional

2020-05-08 Thread Greg Troxel
Peter Elderson  writes:

> Why not use a datum:value pair?
>
> ele=[datum:]value
>
> datum: is optional. If you don't know, just leave it out. Data users can
> assume locally signed or known.

Becuase, as I have said many times and no one seems to be listening, in
OSM we have said that we use WGS84, and thus all elevations must be in
WGS84 (height above geoid), the same way that all horizontal coordinates
must also be in WGS84.

The very notion of putting in elevations in other datums is very
irregular, and it's a path to madness where data in OSM is in varying
reference systems and the data consumer then has to deal and transform.
It seems really obvious that the data should be in the standard OSM
datum and therefore correct.

This entire situation is really blowing up a situation of people who
want to simultaneously not be rigorous, by entering elevations that they
don't have any basis for trusting or knowing the datum, and to be sort
of appearing to be rigorous by labeling them in a way that isn't sound.

I think it's completely fair to have an extra tag that indicates the
elevation value is low quality, so that those mappers that know this and
those data consumers that know this can express and understand this.
But it's also very important for the simple case to remain simple.

Adding datum: into elevation means that every data consumer has to adapt
to the new rule, while ele:datum= does not - those that ignore it
are not harmed.


Other than your proposal making it difficult for data consumers, it
seems equivalent to ele:datum=.

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


Re: [Tagging] RFC ele:regional

2020-05-07 Thread Greg Troxel
Joseph Eisenberg  writes:

> Is there a reason to use this new tag ele:regional instead of ele:local=*
> which is already mentioned on the Key:ele page?

The notion of "ele:regional" is semantically wrong, because there is no
way to map a particular lcoation to a single vertical datum.

The notion of "local" has the same problem, and it is also a poor choice
of words in that in surveying, "local", refers to coordinate systems
established for particular projects or surveys that have no lasting
significance.

I have tended to say "regional datum", because in the US we share NAVD88
with Canada, and because I have the impression that in Europe multiple
countries share a vertical datum.


Basically, either you know what datum an elevation is in, in which case
you can 1) transform it to WGS84 height above geoid or 2) label it
correctly, or you don't know, in which case you should simply *admit
that you do not know*.


I would also ask: if this is reasonable for height, why isn't it also
reasonable for horizontal coordinates?

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


Re: [Tagging] RFC ele:regional

2020-05-07 Thread Greg Troxel
Mark Wagner  writes:

> What about regions where two or more reference systems are in common
> use?  If I copy an elevation from a USGS benchmark and put it in
> "ele:regional", how does an end-user know if it's a recent benchmark
> measured in NAVD 88 or an older benchmark measured in NVGD 29?

They don't, and this is why doing what you ask about is a bad idea.  (I
realize you are asking a mostly rhetorical question.)

The right thing to do is one of

  1) transform the elevation from whichever system it is in to WGS84
  height above geoid.  This is after all what we do with horizontal
  coordinates -- it is not acceptable in OSM to store coordinates in
  some random datum that is not WGS84, and then make up extra tags to
  pretend that's ok.

  2) Use ele:datum=unknown as a clue that the data is not that high
  quality.

  3) Look up the data sheet and mark it as ele:datum=NGVD29 or
  ele:datum=NAVD88 as it turns out.  Keep in mind that this 'on the
  ground' verifiability notion is taken to crazy extremes, and that
  looking up a height in a database is just as legit as reading it off
  the disc.  The physical discs are after all merely a distributed
  database.  If you are encoding "this disc says X", then you are
  reporting a fact you see with your eyes.  But once you report "the
  elevation of this disc is X (because it said so)", then you are making
  assumptions and *you have not actually verified* what you are putting
  into OSM.  In particular you have not verified it any more than
  looking it up in the NGS databse, and arguably you have verified it
  much less.

The next question is:

  If I just put a height that might be NGVD29 or NAVD88 into the db as
  ele, where it is interpreted as WGS84 heigh above geoid, what harm
  is done, and who suffers that harm?

and I would say "close to zero, and anybody who is upset is welcome to
look up the datasheets, transform precisely, and adjust the values in
the osm db, just like anybody who finds nodes that are not placed
correctly in horizontal coordinates is welcome to move them to better
places".


Not addressed at Mark, but I find the insistence that we have a real
problem to be hard to understand.


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


Re: [Tagging] RFC ele:regional

2020-05-07 Thread Greg Troxel
Simon Poole  writes:

> Am 04.05.2020 um 15:19 schrieb Kevin Kenny:
>> Elevation as height-above-ellipsoid, unless you're using it in the
>> intermediate results of a GPS calculation, is nonsensical.
>
> However if you read the argumentation on the Altitude page that was
> exactly the reasoning: store hae and therefore be able to calculate
> datum specific heights easily after the fact.

Yes, but this is a ridiculous stramwan.   HAE and height above wgs84
geoid are equally well defined, but one (height above geoid) is what is
used for height and also happens to be almost matching all civil height
systems.


The real point here is that people want to take data that has a number
but not a datum and enter it and feel good about themelves, instead of
realizing and admitting that they are doing something fundamentally
wrong.  I am perfectly ok with entering a height that has no datum, and
having some meta key that basically says that the height value is
inaccurate, and perhaps "ele:datum=unknown" is good for this, crisply
denoting that the height is without a solid basis.

But, I find it unreasonable that people want to legitimize this sort of
confusion, rather than mark it as confusion as a warning to others.

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


Re: [Tagging] RFC ele:regional

2020-05-04 Thread Greg Troxel
Martin Koppenhoefer  writes:

> So the question is how we can solve this. We could discourage the use of
> the "naked ele" and encourage to always use a more specific subtag, e.g.

But is there significant amounts of data that have ele as ellipsoidal
height, more so than the prevalence of somewhat wrong data in OSM?   If
not, there is nothing to be gained from tag churn.

> - ele:egm96= to mean ele referring to the EGM96 geoid

Again this makes life difficult for data consumers.  Plus it's EGM08
now, and approximately zero people are clear on which of these flavors
they or any device are using.

> - ele:wgs84= to mean ele based on the WGS84 ellipsoid (or maybe

This is very confusing and therefore a bad idea.  Elevation in WGS84 is
obviously, to those who really understand height, intended to mean heigh
above geoid.  Nobody with the slightest respect for existing practice
would ever use the word "elevation" to mean "height above ellipsoid".

And, I don't think we should encourage HAE to be stored in OSM at all.

> "ele:ellipsoid" which would imply the WGS84 ellipsoid?)

Also very confusing, as in the US ellipsoidal heights are often relative
to the NAD83 ellipsoid.  However, people that use them are clear on what
they are doing and they are labeled correctly.

> and whichever height reference system is used, e.g.
> - ele:dhhn92
> - ele:tm75
> and more: https://taginfo.openstreetmap.org/search?q=ele%3A
>
> - ele:regional for "I have no idea but it was written on a sign", could
> still be a way to be expressive about the reliability. For many use cases
> +- 50m is better than no information. We could also keep "ele" for this
> like you suggested, although it wouldn't be explicit then.

This really feels like solving a non-problem.  If you just put what's
on the sign in ele, and don't worry about it, that's ok.  If somebody
else actually makes a valid, hard-core measuremnt, and fixes it, even
better.  But this is just like having approximate horizontal coordinates
- if a hotel is 10m off from where  it should be, that's stil useful and
somebody can and will fix it later.


You still haven't articulated that there is a real problem  to be
solved, or made an argument that my proposal for ele and ele:datum is
unsuitable.


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


Re: [Tagging] RFC ele:regional

2020-05-04 Thread Greg Troxel
Volker Schmidt  writes:

> I am not an expert, but it looks as if the Wiki page Key:ele
>  is not up-to-date.
> I thought that WGS84 uses the EGM96 Geoid, named "WGS84 EGM96 Geoid".
> Hence there should be no difference between WGS84 and EGM96 elevations.

To be somewhat pedantic, EGM96 is a function that takes lat/lon as input
and produces a value which is the offset of the ellipsoid and  the geoid
(equal-gravity surface).   So "EGM96 elevation" is a big awkward.   But,
one uses WGS84 ellipsoidal height and EGM96 to get "WGS84 altitude".

I believe EGM96 was replaced with EGM08:
  https://earth-info.nga.mil/GandG/wgs84/gravitymod/egm2008/egm08_wgs84.html

But this is basically an update with more precision, so it's very much
the same thing.

> Also it would be helpful, f you could give examples of local elevation
> systems which would need explicit tagging.
> When I see an elevation value on the ground I do not see any reference to
> the reference system, so I cannot know, as a mapper, what reference system
> is at the base of the informaton that I find on the ground. In that respect
> the proposal is not at all clear from a practical perspective.

Completely agreed.  It is a good guess that signs you see are in your
national vertical datum.  But some (most?) places have multiple datums,
and it seems very likely that values people have known have been copied
forward on signs for who knows how long, and there's no way to tell
which one is meant.This is true on the US for things like mountains
and "highest point on the masschusetts turnpike" signs -- which lacks a
datum.  The wikipedia article doesn't address this point :-)

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


Re: [Tagging] RFC ele:regional

2020-05-04 Thread Greg Troxel
Basically I think the whole elevation as height above ellipsoid is
mostly a huge misunderstanding, and I wonder how much support there is
for it.

My memory matches what Martin pointed to: ele= is "height above sea
level".  And, given that layman's terms description, and that OSM is
using WGS84, then it seems really obvious that the particular flavor of
"height above sea level" should be "WGS84 altitude" meaning "height
above the WGS84 geoid".

In the US, ele= tags typically have the NAVD88 height, from GNIS, or
elevations from GPS receivers that do geoid corrections (e.g. Garmin).
(Yes, there's slight fuzz but it's tiny compared to vertical GPS
accuracy.)

The talk page you pointed to says "elevation should be WGS84 because we
use GPS" and then reasons that this must be HAE, even though almost no
GPS receiver used by a mapper (pre android) would have been showing HAE.
In fact, to this day I have not seen a GPS receiver (other than geodetic
survey type ones) display height in HAE (without labeling it as such),
other than buggy android apps.

So it's likely that people were using what their receivers displayed
(height above geoid) and perhaps just thought that was HAE, rather than
really intending to use height values with huge differences from
conventional height datums.

Stepping back from untangling the history, I have three questions about
ele=:

  1) Does anybody think it makes sense to use HAE in OSM, vs "WGS84
  elevation" meaning heigth above geoid?

  2) Are there lots of points in OSM that actually have ele in HAE?  (I
  am unaware of any such points in the US.)

  3) Are there any national height datums that are ellipsoidal height?
  (I think not, because height is very much about water and therefore
  about gravity.)  If not, why is it sensible for OSM to start doing
  this?  IMHO, OSM should follow existing standards and practices of the
  relevant fields in terms of definitions, to the extent that this is
  sensible.



So I would propose:

  adjust ele page to be very clear that this is WGS84 altitude (height
  above geoid) and caution about bad data on some android apps.

  mark Altitude page as an old proposal that has no current support



and if that's off base it would be good to hear from people how it's
off, and why.



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


Re: [Tagging] RFC ele:regional

2020-05-04 Thread Greg Troxel
Following up to myself, a few things I didn't have time to say last
night.

Once we accept that the base notion of ele= means WGS84 geoid height
(meaning the MSL sort of height), and that ellipsoidal heights basically
have no place in OSM, then:

  0) The entire notion of looking at a sign on a mountain and believing
  that is suspect.  I certainly think it's fair to put in a sign object
  with an inscription, as "there is a sign" is a fact.  But on mountains
  here, there is often some number in feet, and it's never clear whether
  that's in NGVD29, or NAVD88.  Often the number doesn't change much and
  it doesn't matter.  But a sign with a number without a datum has to be
  taken with a huge grain of salt.  (As I understand it, most countries
  have a 20s-50s generation height system and an 80s/90s height system,
  and many are moving to a 2020s height system.)

  1) For this proposal to be considered, we need to have examples of how
  different elevations are between "WGS84 altitude" and various national
  height datums.  In the US, the differences are at the meter or so
  level.  So while the ability to enter national datum heights without
  losing accuracy is useful, there is complexity in use to trade off
  against that.  I suspect that differences from most other national
  vertical datum to WGS84 are small.

  2) As always, I am concerned that tagging discussions tend to focus on
  what taggers want to represent and not be so concerned with how data
  consumers uses the tags.  Tags are after all a protocol that is
  written by mappers and read by renderers, routers, etc.  It's
  therefore important that simpler data consumers get sensible answers,
  and that mappers being less precise provide data that is not grossly
  wrong.

  Therefore, if we're going to represent this, I think we should say:

ele=
ele:datum=

  where ELEVATION is some sort of "height above sea level", where the
  main/primary datum is the WGS84/EGM, and if it is in some other datum
  (e.g. NAVD88 in the US and I am seeing various other ones on the
  list), then ele:datum denotes that datum.  This means that if a mapper
  just puts in an elevation, ignoring vertical datum, or if a renderer
  ignores it then nothing terrible happens, just a meter or two of fuzz.
  And, if the mapper is precise, and the renderer deals, then all is ok
  with no loss of precision due to datum issues.


I'll also say that this alternate datum notion is irregular, in that we
expect horizontal positions to be transformed from national horizontal
datums to WGS84, and that putting in a tag to say that coordinates were
in some other datum would be, I think, considered madness.  Instead, we
expect people to transform any such data to WGS84.  (And we realize that
meter level shifts are not that important usually, because measurements
and source data is rarely that good.)

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


Re: [Tagging] RFC ele:regional

2020-05-04 Thread Greg Troxel
Peter Elderson  writes:

> Thanks for explaining why my android phone says I am at +38m (+/- 3) in my
> backyard when in fact it is at Dutch sea level -4.4m.

Well, I didn't quite.   The location API returns HAE.For a program
to show that value to a human as "elevation" is buggy.   So in addition
to what I said, you have to add "your software is buggy".   File a bug
with that app!

On Android:

  install GPSTest (available in F-Droid).  It will show two heights.
  One is mislabeled "Alt", when it should say HAE*, and the other is "Alt
  (MSL)" which is the WGS84 sea level type height.
  * I have discussed with the author, but the notion is that people will
be baffled by HAE.  However, I think that's better than
misinterpreting it as a gravity-based height

  install OsmAnd.  In addition to maps, get the "World Altitude
  Correction" map.  This is really the WGS84 gravity model, and when it
  is loaded OsmAnd will convert HAE from Android to height above the
  WGS84 gravity surface
  

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


Re: [Tagging] RFC ele:regional

2020-05-03 Thread Greg Troxel
Martin Koppenhoefer  writes:

> I’m asking for comments on 
> https://wiki.openstreetmap.org/wiki/Proposed_features/ele:regional

Two big comments:

  First, the current wiki documentation about ele and Altitude should be
  really straigthened out, so that we have a basis for what we are
  comparing to.

  Second, the notion of a single regional vertical datum doesn't really
  work.  In the US, that could be the old NGVD29, or the current NAVD88.
  Plus, we are about to get NATRF2022.  However, all of these are within
  a meter or so, and in terms of vertical data in OSM, that's not really
  a big problem.  So if there is going to be precision, then we should
  follow GIS and have an explicit datum.  I would say an EPSG code is
  sensible -- see the proj package for canonical values.



As for ele/Altitude, there is great confusion out there about "WGS84"
and two separate concepts:

  height above the ellipsoid.  Often written HAE. The ellipsoid is a
  mathematical surface that is NOT a surface of equal gravity.  While
  geodesists and geodetic surveyors use it, and while it's part of the
  calculations within GPS, I am not aware of a single vertical datum in
  use in any country that is relative to the ellipisoid.  Note that
  water does not flow "downhill" when "down" means to a lower value of
  HAE.  Water is hugely important in elevation and mapping.

  height above geoid, or height above a reference equal-gravity surface,
  or height above sea level.  (Yes, I realize that "sea level" is a huge
  can of worms.)   This is more or less what every height system uses or
  intends to use.


In WGS84, one gets from the base computation lat/lon and a height above
the ellipsoid.  This is purely a geometric answer and is totally
disconnected from grravity.  Then, GPS receivers use a gravity model to
compute the offset from the ellipsoid and the reference gravity surface
(which is more or less the "sea level surface"), and they them use that
to get a "height above sea level".  Receivers that display to humans
display this sea level height.  NMEA has that same sea level height.

(Android stands alone in that the API returns height above ellipsoid.
That's not wrong, but it is unusual.  IMHO how Android defines an
interface is irrelevant to OSM's definitions.)


When people say "WGS84 altitude", they mean the height above the WGS84
equal-gravity surface as computed from the ellipsoidal height and the
gravity model.  This is sort of 0m at sea level.  Note that the
ellipsoid can be 100m different from this equal-gravity surface, and is
often significantly different.  It's ~30m in Boston and I hear it's 50m
in Switzerland.  Nobody who says "WGS84 altitude" really means "WGS84
ellipsoidal height".  If they did, they would say "WGS84 ellipsoidal
height".


___
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 Greg Troxel
Mike Thompson  writes:

> I have always been under the impression that the highway tag should be
> based off of function.  Recently I have come across a number of cases
> where driveways and residential roads were tagged "highway=track"
> (perhaps because they are unpaved?), e.g. [0].  Before I change these,
> I wanted to check with the rest of the community.

I agree with those who say driveways should be highway=service
service=driveway, unless they are so difficult to drive on that they are
really not recommended in a passengar car.

Not really germane to driveways, but a major distinction, at least
around me (ma.us) is that

  a road is a legal thing, with its own parcel

  a track is an agricultural road, or old time logging road, within a
  parcel

However, drivways are also not legally roads in terms of separate
parcels.


I also agree that this is a problem partially becuase of the default
style not showing dirt roads as dirt.  Whether a road is dirt or paved
is hugely important in all areas where both types exist.  My impresssion
is that England doesn't really have dirt roads because they would be too
muddy.  In New England they are quite common.  My town halfway from
Boston to Worcester has a few and as you go farther out there are more.
I think using track to get a dirt symbol is bad.  But, my impression is
that the symbology plan to short dirt roads on carto is considered too
hard, for reasons that may be valid but that I don't understand.  I
think it's so important that even some ugliness is better than not
showing it.

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


Re: [Tagging] Too many different features lumped together under amenity=social_facility?

2020-04-20 Thread Greg Troxel
Martin Koppenhoefer  writes:

> apart from workshops, it is this overly broad meaning of "social facility"
> that doesn't make the tag super useful. In the end you will have to add

I agree with this overbroad notion.  I am very much in favor of a
top-level tag with subtags when all of the subthings are clearly part of
some larger concept.  But social_facility seems to be not like that.

I said this in an earlier thread, but "group home" is a loaded word and
it would be good to avoid using it in a way that applies incorrect
connotations.  Specifically, in the US it is not used for a place where
people live because they are unable to care for themselves fully because
of normal aspects of aging (physical inability and dementia).

Also, there are places "independent living", and I think calling those
"social facility" is wrong.   Overall, I'd be in favor of completely
removing the use of social facility in tagging, as it carries too much
baggage and historical confusion compared to its value.

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


Re: [Tagging] insurance health

2020-04-15 Thread Greg Troxel

On 2020-04-14 21:16, Joseph Eisenberg wrote:

OK, but are there any countries in the world where you can would
normally buy health insurance in the same place as car or home or life
insurance?


I don't know.  Many countries might not even allow this.


If not, then this is a theoretical problem only.


The problem is having a messy namespace with tags that sort of mean the 
same thing, but aren't the same, which makes understanding the data much 
harder, for what I view as no good reason.



"if you  want to  ask "how many insurance offices are there and what
is the breakdown by type", it's much more natural to search one key..."

It's all one key either way ("office"), and database users already are
very accustomed to searching for more than one tag to find a set of
similar things. It only takes a few more seconds to add another tag to
an Overpass-API query.


It's not the time to change the query.  It's the semantic load on 
everything that looks at the data.  Every renderer and search program 
has to learn about this.   That's not so bad in terms of work, but when 
they don't know about it, users get missing results.



But it takes more time for each mapper to add 2 tags instead of one.
Mapper time is the most precious resource in OpenStreetMap: we don't
have enough mappers, and most are working for free, for fun.


I also have to often tag "barrier=wall" "wall=dry_stone".   Should we 
than have "barrier=wall_dry_stone" to save me a few keystrokes?  This 
way becomes madness if taken to the extreme with every detail promoted 
into the top-level tag.


In my mapping of POIs, the big amount time is actually going places. 
The next biggest is having to read the wiki to figure out what tags to 
use for things that I haven't mapped before.   When using vespucci, 
another big thing is actually typing the name correctly.


If there is a preset for "insurance" and  a subtype for what kind, I 
think most people would complete their tagging in seconds.   And this is 
something that isn't super common, and many people mapping it will be 
tagging one, very occasionally.


So I really think this de-normalized tagging, to use db terms, is a 
false optimization that doesn't help anyone.



Let's make things as easy as possible for mappers: one tag for one main feature.


That is begging the question of "main feature", and what's easy.

We have to have summarization or we will have thousands of top-level 
tags.  To me, a business that sells insurance is a kind of thing, and 
sensible to label.   Labeling what kind is perhaps of value, but I don't 
see people shoppingfor health insurance by searching for such places.


And, having a preset with a choice pulldown makes it easy.  Having a 
top-level shop preset choice with 10x the number of things in it is not 
easier, as it becomes too big to scan through.


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


Re: [Tagging] insurance health

2020-04-14 Thread Greg Troxel
Agustin Rissoli  writes:

> In Argentina we want to correctly tagging offices of companies dedicated to
> what we call prepaid medicine, by paying a monthly fee you access a series
> of medical benefits.
> We are hesitating between these tags:
>
> office=health_insurance
> It has no wiki, it has 185 uses, the majority in Belgium since it was
> created in 2013, they even have a preset in JOSM.
>
> office=insurance + insurance=health
> It has a wiki, curiously created by a Belgian user in 2018, it has 66 uses.
> It is the only documented insurance=* key.

While I see Joseph's point about what is normal, I think that's an
artifact of some, perhaps many societies.

I think if this is an office selling insurance of any kind, it should
have office=insurance and then a subtag.  I don't think it helps map
data users to make a second top-level tag.  Basically I think tags
should follow semantics as much as possible, when that's reasonable.

For what it's worth, around me, also in the US, my impression is that
most "insurance offices" are really "property and casualty insurance
offices".  This is for your car, and your house.  But typically not life
insurance so much, and not health.  (I am not sure about professional
liability and business interruption insurance.)

As always, we should step back and ask "when we add these tags, who will
use them, and why".  I see two points:

  some kind of overall statistics of types of businesses

  wanting to find a particular thing

In the case of office=insurance insurance=health, if that's what you
want, you can find it by searching for that just as well as searching
for office=health_insurance.

But if you  want to  ask "how many insurance offices are there and what
is the breakdown by type", it's much more natural to search one key and
switch on subtag, then to consult some information -- which we don't
really have a way to maintain -- that says office=insurance,
office=health_insurance and office=foo_insurance are all types of
insurance offices.

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


Re: [Tagging] building=public vs. building=civic

2020-04-08 Thread Greg Troxel
Martin Koppenhoefer  writes:

> While building=public seems defined, I have difficulties with building=civic, 
> which is according to the wiki

public building appears to have its origin as a legal term, and I don't
see it as a type of building at all.  In the US the term might be
"public accomodation" and an example might be the notion that if as part
of what you do the public comes to buy food, watch a play or anything
else like that -- even if it's private property and you charge them, and
could tell disagreeable people to leave -- then you have obligations to
provide access to disabled people.  But this doesn't mean that "public
accomodation" should be any kind of top-level tag; at best it's a minor
property saying if these sorts of rules apply.

> A building hosting any civic amenity (town hall, library, swimming pool).

My sense (en_US) is that this means "some kind of function that is 1)
broadly available to the public and 2) operated by the government".


> For example I’m asking myself whether structures like wastewater
> treatment or recycling centers would qualify as building=civic.

wastewater treatment, no - public is not welcome.  It is industrial.

recycling center; Probably.

> Or shopping malls? Cinemas? Private gyms?

No, all just random private things the public goes to.

> Power stations?

No, public unwelcome.  industrial

> Universities?

No.  Often not government, sometimes is, but it is a thing all by itself
and calling it civic is not helpful.

> Restaurants?

No.  Not government.  We have an amenity=restaurant tag.  Labeling the
building is not helpful.  Plus, often there are multiple things in a
building, and one tenant does not define the building in any useful
sense.

I think building=civic blurs use and government/not and shouldn't be
used *at all*.


To me, this is an example of people searching for tagging, disconnected
from an articulated purpose of how data consumers would use the tags.


> I’ve looked at random internet dictionaries, Cambridge doesn’t have a
> lemma for civic building and defines civic “ of or belonging to a city
> or citizen” (not very helpful I’d say)

It's not helpful.  (Civic also can be used as "civic duty" and "civics class".)

> IMHO the building=civic page should be discussed and improved, ideally
> by giving a definition rather than a list of examples

I think it should be withdrawn entirely.


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


Re: [Tagging] Can highway=cycleway be limited to MTB?

2020-04-02 Thread Greg Troxel
brad  writes:

> How many trails are there that are not shared use?

In my town, most of the town-owned conservation land has rules that say:

  trails shown on the official map may be used by hikers, bicycles and
  horses

  other trails may be used by hikers only


So there are a lot that are not shared use.

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


Re: [Tagging] Can highway=cycleway be limited to MTB?

2020-04-02 Thread Greg Troxel
Snusmumriken  writes:

> On Thu, 2020-04-02 at 22:24 +1100, Andrew Harvey wrote:
>> just usually only a certain kind of bicycle.
>
> Well, that's the problem, if one can't travel on a certain way with a
> general purpose bicycle, then it shouldn't be tagged highway=cycleway 

I agree, and I think this is the point.

We don't use "highway=unclassified" for a road that cannot be used by a
passenger car and is only passable with an extreme-high-clearance 4WD
vehicle.


As for path, I see

  highway=cycleway
and
  highway=path bicycle=designated

as equivalent.  And same for footway/foot=designated.

However, around me there is a convention that any
dirt/unimproved/in-the-woods sort of thing is path, and
in-town/paved/manicured sorts of are highway=footway.

Basically if you can walk on it in dress shoes, not get dirty, and not
get ticks, it is footway, and if you ought to have hiking shoes, it is
path.

I realize this is controversial, but it's another data point.


I am mildly curious how many places there are in mountain bike trails
that prohibit hikers.   Around me, every trail  that is open at all is
open to hiking, and some are open to bicycles and horses, some aren't.
(Additionally some are closed to bicyles and horses when wet.)

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


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

2020-03-29 Thread Greg Troxel
Martin Koppenhoefer  writes:

> Frankly, I am not really familiar with the situation in North America
> (besides some lessons about North American urbanism I have heard 20
> years ago). I am aware there are some developments that imitate 19th
> century architecture, so even if many or most of the traditional city
> centers have been razed in the sixties, I would still expect to find
> at least some squares in north america.

There are lots of things that are like many other things, as many came
from various places.

> If you have a look at the wikipedia article on Times Square, it also
> mentions its nature as a town square: “ Times Square functions as a
> town square”

Yes, but that says "functions as", not "meets the picky definition of
the osm tag place=square".  And if written by Americans, those words are
colored by their understanding of meaning.

> https://en.m.wikipedia.org/wiki/Times_Square
> It is also a model example in that it lies at the junction of import streets 
> and is emphasized by the adjacent architecture.

I never had the impression adjacent architecture mattered.

> The existence of squares is not a recent or European invention, for
> example you’ll find squares in arabic or Chinese cities as well
> (you’ll indeed find them almost everywhere), here’s a list of some
> famous squares worldwide:
> https://en.m.wikipedia.org/wiki/List_of_city_squares

What I meant is that there are many places with square in the name that
aren't, and I think we're leading to mistagging due to different
understandings of words.  I know the OSM tagging system says that tokens
in tag mean what they are defined, not what they seem to say, but
interpreting the tokens as words with national meaning is too easy.

> Supposedly we would not want to have different specific top level
> place tags for neighbourhoods, depending on name components, so using
> place=square for neighborhoods seems not a sensible interpretation of
> the tag, I guess we can agree on this?

Yes.  Except that "neighborhood" is probably even not quite right.   In
New England usage the indistinct extent of "Foo Square" is much smaller
than what one might call a neighhborhood.

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


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

2020-03-29 Thread Greg Troxel
Martin Koppenhoefer  writes:

> sent from a phone
>
>> On 29. Mar 2020, at 17:23, Greg Troxel  wrote:
>> 
>> Really it is a place=neighborhood
>> with an indistinct boundary, even if there is a bit of eurosquare there.
>
> the fact there is a neighborhood which takes its name from a square
> does not imply there cannot also be a square at the same time, likely
> with different boundaries.

Yes, but since the name refers to a (small) neighborhood, assigning that
same name to the hard-surfaced gathering place is wrong and making
things up to fit euro notions which do not apply.  Really, it seems like
you are trying to shoehorn european definitions into US naming when it
is just not the way it is.

> Although it could explain why people tag place=square to neighborhoods

I think people tag place=square because they have not been through this
discussion and they assume that place=square is a locality-type tag that
refers to an indistinct named region that is an intersection and the
things near it.  That's what speakers of en_US would assume, not having
read a detailed definition that says otherwise.

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


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

2020-03-29 Thread Greg Troxel
Paul Allen  writes:

> On Sun, 29 Mar 2020 at 00:55, Greg Troxel  wrote:
>
>> Paul Allen  writes:
>>
>> > 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.
>>
>> But is that a place=square?  That is simply an intersection which is
>> called square.  There is no hard-surfaced area for people separate frrom
>> the roads.
>
> The only pictures of it I've ever seen were all full of people standing
> around.  I'll take your word for it.

Probably that's during new year's eve when all the roads are shut down
and there are people in many more places than usual.

I did find a bit of a pedestrian area that fits the Euro definition of
square, on looking further.

But that area is not what is meant by "Foo Square" in the US.  Such
names refer to an indistinct area around the named intersection.
Joseph Eisenberg summed it up well in the Harvard Square case, and I
think the same applies here.

In OSM, there is a way in Times Square with place=square.  However, it
includes roads and bits of sidewalk in some places, so that is not
matching what has been discussed.  Really it is a place=neighborhood
with an indistinct boundary, even if there is a bit of eurosquare there.

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


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

2020-03-29 Thread Greg Troxel
Joseph Eisenberg  writes:

> "taking "Harvard Square" as an example,
> that refers to an area around the road junctions.  It includes the
> sidewalks, and it includes the businesses and buildings that are on the
> roads that border the center, and even includes things that are perhaps
> 50-100m down side roads, as long as they are sort of part of the same
> logical larger place."
>
> In that case use a place=neighbourhood node, since this is a named
> part of a larger settlement, aka "a neighbo(u)rhood"

That sounds right to me.

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


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

2020-03-28 Thread Greg Troxel
Paul Allen  writes:

> 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.

But is that a place=square?  That is simply an intersection which is
called square.  There is no hard-surfaced area for people separate frrom
the roads.

___
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 Greg Troxel
Martin Koppenhoefer  writes:

> Am Di., 24. März 2020 um 18:23 Uhr schrieb Greg Troxel :
>
>> So one definition is
>>
>>   a square is an area with an indistinct boundary that is known by a
>>   placename by most locals.
>
> I would rather say "distinct" boundaries".

This leads me to understand how we are not understanding each other!


I think you are saying that the open, typically hard-surfaced, typically
square area that is typically contained within roadways, is exactly the
square.  That one should draw a way around that area, such that no roads
are in the way, and typically no buildings, and then place=square should
be tagged on the way.  In other words, the square is only that area, not
the nearby roads, not the buildings that are across streets from the
square, and not buildings that are 50m down a side street from the
square.

For a US(New England) square, taking "Harvard Square" as an example,
that refers to an area around the road junctions.  It includes the
sidewalks, and it includes the businesses and buildings that are on the
roads that border the center, and even includes things that are perhaps
50-100m down side roads, as long as they are sort of part of the same
logical larger place.  This is what I mean by indistinct, as each shop
farther way is somewhat less "in Harvard Square" (and eventually
somewhat more "in Central Square" as you head towards Boston), but there
is no shop you can point to and say "this is the last shop in Harvard
Square on this side of Mass. Ave."  One would say that a store on one of
those streets is "in Harvard Square".  No one would use the phrase "on
Harvard Square".

So our square is a place, grown up around an intersection, and grounded
by name in that intersection.  Which i think amounts to "Things called
squares in New England are very rarely place=square in OSM, and
certainly having square in the name is not a presumption that it is
place=square."




>> Almost always there are multiple roads intersecting, and typically it
>> has some degree of importance (commerce, cultural, historical, or
>> other) that is locally notable.

> question of size. Small square will typically have less importance than
> bigger ones.

Agreed - just that there is some local in the math sense max of
notability, not that they are equal.

>>   There may or may not be an open area where people can gather.
>
> there must be an open area (a square _is_ an open area), but it may not
> always be possible for people to gather (in particular while the space is
> occupied by traffic, parked vehicles, lawn that is not accessible, a bus
> station, etc.), although in extreme situations (think riots, political
> demonstrations, ...) these spaces could probably be used to gather even if
> it wasn't possible under normal conditions.

I find the notion of an open area to gather being necessary, while it
being ok that they perhaps cannot gather to be very strange.   I think
you don't mean "people could stand in the middle of the street", in
which case every intersection is a square.

>> Typically the name is not primarily associated with the location as
>> a settlement, although almost always people live there.
>
> people will not live on a square, they might be living around the square,
> but you can also find squares in business districts where nobody lives. The
> definition is not about usage, but about spatial configuration.

See above about the polygon on the open space, vs the region.  I
understand you now.

>> To have this make sense, we really need a definition that one can read
>> while standing someplace and declare it to be a square or not a square.
>> I remain quite skeptical.
>
> squares are like streets, but unlike streets which are made to move,
> squares are made to stay.

I don't find that clear enough.  Streets were made for walking and for
horses, and now they are used by cars.

What about a grassy area surrounded by streets.  We call that "town
common" usually (even though people may not bring their animals to graze
on it), but we would not call it a square, almost always.  


I have concluded that we have very few squares in the US, so I am pretty
unconcerned, as long as it's clear that there is no basis for "Foo
Square" to be presumed to be an osm square.

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


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

2020-03-24 Thread Greg Troxel
[kind of a joke about NY and New England; there is quite the rivalrly]

What I take away from this exchange with you is that it is difficult to
know what "square" means, and this it is unlikely that people will
arrive at similar notions.

Around here, squares are not square.  (Oral tradition is that our roads
used to be cow paths.)   So one definition is

  a square is an area with an indistinct boundary that is known by a
  placename by most locals.  Almost always there are multiple roads
  intersecting, and typically it has some degree of importance
  (commerce, cultural, historical, or other) that is locally notable.
  There may or may not be an open area where people can gather.
  Typically the name is not primarily associated with the location as a
  settlement, although almost always people live there.

but by then it is so watered down, it might as well be place=locality.

To have this make sense, we really need a definition that one can read
while standing someplace and declare it to be a square or not a square.
I remain quite skeptical.



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


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

2020-03-23 Thread Greg Troxel
Martin Koppenhoefer  writes:

> Am Mo., 23. März 2020 um 18:47 Uhr schrieb Greg Troxel :
>
>> We need it for en_US, too, because in the US, at least in New England,
>> everybody knows what Square means and it is different from what this
>> thread is discussing.
>
> Think about pre-60ies urbanism. And "new urbanism", for example.

Sorry, too confusing!

> Here are some examples in New England (I do not know them from visiting,
> but they are obvious from looking at the map):
> https://www.openstreetmap.org/way/530038747

not tagged as place=square.  not in New England!  (seriously, New York
is not part of New England)

Yes, uses Square in name and fits the eurodef.

> https://www.openstreetmap.org/way/474864229

does not use sqaure in the name and is not place=square.

Not clear if it really functions as a eurodef-square.

> https://www.openstreetmap.org/way/474864229 Union Square

wrong link, but guessing you mean
https://osm.org/go/Zct8XcGSc--?layers=N then that seems like maybe it
fits and is named.

> Also this could be a square:
> https://www.openstreetmap.org/#map=19/39.29345/-76.60253

could be, but it could also just be a bit of grass.

> (sorry no time for more examples now)

That's fine, but the point is not that we have zero things in the US
that meet the Euro definition of square.  It is that we have many things
that have square in the name that do not, and therefore that inhabitants
of the US, or at least New England, do not relate at all to the EURO
definition of square.

Here is the most well known thing named square in New England (six
states):

  https://osm.org/go/ZfI4p0cT9--

and note the green area to the NE is not part of Harvard Square - it is
"Harvard Yard", which is a thing near Harvard Square.


Here's another example of someting with Square in the name that is not a
place=square

https://osm.org/go/ZfI6Neyh0--

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


Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

2020-03-23 Thread Greg Troxel
Tobias Wrede  writes:

> It seems I have a different understanding of the concept PO
> box. Around here if you have a PO box mail is delivered there and you
> go yourself pick it up, convenient for people who are rarely at home
> or get huge amounts of mail. In more rural areas I have seen letter
> boxes in one central point of a several km2 area or a box/bag at the
> next major road where mail is delivered to. Again you go there
> yourself to pick it up.

This is how it is in the US, too.

> I must admit I fail to understand your kind of PO box. One delivery
> company delivers to the PO box (which address/location is known) and
> then some other guys pick the mail up there and take it to your home
> which they don't know anything about? Sounds strange to me.

Also doesn't happen in the US.  PO boxes belong to the post office, and
only they deliver to them.  Most (all?) online ordering will only allow
shipment to a PO BOX if shipping is via the post office.

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


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

2020-03-23 Thread Greg Troxel
Joseph Eisenberg  writes:

> That is why we need an actual definition of place=square that isn't
> simply "a town square", because I need to be able to translate it into
> Indonesia, for people who have never seen a European town square. I
> suspect that Japanese and Korean will have the same problem, along
> with many other non-European languages.

We need it for en_US, too, because in the US, at least in New England,
everybody knows what Square means and it is different from what this
thread is discussing.

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


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

2020-03-22 Thread Greg Troxel
I just looked at this discussion and am a bit baffled.  We do have
notions in OSM that tags mean what they are defined, not what the words
might mean, but I think this situation is even more difficult.

I live in New England, and we have lots of place names "Foo Square".
Perhaps the biggest is "Harvard Square", and basically that's an area
surrounding the junction of some roads, and nearby is a rapid transit
rail ("subway", we call it in Boston) and a college that for some reason
is famous.

Less notably lots of towns have things called squares.   They are
essentially never square, and rarely associated with areas of grass or
other places for people to gather.

There are also lesser squares, basically intersections that didn't used
to be that notable and now have a "Corporal John Smith Memorial Square"
sign.

So my point is that if someone wants to communicate to normal people,
using "square" as a type of object in search is not going to work, at
least in my corner of the US.   Here, people simply map a name "Harvard
Square" to a place.  Someone hearing "Waverley Square" not konwing
anything about it would assume that 1) there are multiple roads and 2)
that whatever Waverley Square is, it is more interesting from some vague
shopping/commerce/civic/historic sense than the things that aren't quite
in it and 3) really they wouldn't assume much more.


So perhaps then if "place=square" is supposed to have some semantics,
then Harvard Square should be "place=locality" and maybe it is.  (Even
if people live there, the name as used doesn't really represent that.)

User interfaces will have to be careful to avoid users being confused
that Foo Square is a type of osm-square.


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


Re: [Tagging] Addresses with PO Box, and other delivery type addresses.

2020-03-21 Thread Greg Troxel
Joseph Eisenberg  writes:

> I agree with "addr:mail=*" as a tag to add to guesthouses, shops,
> farms and other businesses, as a way to send letters and perhaps small
> parcels, which might be delivered to a PO Box or some rural delivery
> system, rather than to the physical address of the shop, business or
> other public feature.

If a business *publishes* a mailing address, then that seems reasonable,
but it also seems to be veering into OSM as a database of businesses vs
a map.  But I can see the point that the mailing address of a business
is not so different from the website URL and phone number.

> But I would caution against adding this to private house features, due
> to privacy laws in some countries.

Agreed.  At best it would be highly rude, and I think it's important not
to have a general perception bythe world that OSM is rude.  Many people
seem to think that anything they can find out should be published, and I
think mappers need to ask themselves what should be published.

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


Re: [Tagging] Barbecue disposal bins

2020-03-18 Thread Greg Troxel
Graeme Fitzpatrick  writes:

> Is anyone as irritated as I am by the shortening to 'bbq'.
>
> Sorry, no - it's a standard term, at least around here! :-)

I am irritated by the misuse of barbecue to refer to large class of
anything to do with a grill.  Barbecue properly refers to cooking at low
heat for an extended period of time while drinking beer and issuing
cantankerous opinions, and is quite different from most uses of grills
and charcoal!

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


Re: [Tagging] Feature Proposal - RFC - survey_point:benchmark

2020-03-11 Thread Greg Troxel
"ITineris OSM"  writes:

> I need help in tagging a special kind of survey points: geodesic towers.

Are they called "geodetic" towers?

> These are tubular concrete structures, with usual steel triangulation tripods 
> on their top.

Wow, those are pretty big!

> They have the precise benchmark on the ground level, the tower is erected so 
> that its visible from far, being higher than the trees around.
> They form the base of the national reference grid.

I'm not sure if you mean "benchmark" as vertical control, or if you mean
the horizontal control mark and then the tower is basically over it, to
translate it up along the plumb line.


So the control point is man_made=survey_point.  Then there is a tower
which is physcially notable regardless, and the tourist bit.  OSM's
representation does not really admit multiple primary tags on objects,
except that sometimes they dno't conflict.

I'd put in man_made=survey_point as a node for the thing on the ground,
some survey_point:geodetic_tower=yes subtag on that (to inform those who
care about the survey aspect of that), maybe some kind of height tag,
and then draw a way around the tower and tag that as man_mde=tower
and/or tourism.

I don't think we should try to drag towerness and being an attraction
into the survey_point namespace; it seems easy enough to dneote multiple
properties separately.
[>


>  
>
> They could be tagging as  style="font-family:Courier 
> New,Courier,monospace;">man_made=survey_point because their 
> main purpose is being a geodesic reference point.
>
> However, they could be a  style="font-family:Courier 
> New,Courier,monospace;">man_made=tower, for being a tower 
> emerging from the surface - and to distinguish it from brackets, benchmarks 
> or pavement rivets.
>
> Furthermore, additional functions can be connected to the latter only:
>
> Some of them are tourist attractions, like this 
> https://hu.wikipedia.org/wiki/Cs%C3%B3v%C3%A1nyos#/media/F%C3%A1jl:Csovanyos2014_12.jpg.
>  It is a tower:type=observation.
>
> If its rigged with GSM and microwave antennae, its  style="color:#ff;">tower:type=communication.
>
>
>  
>
> (And of course you may add the  style="font-family: Courier New , Courier , 
> monospace;">triangulation_point=yes tagging.)
>
>  
>
> So how would you tag them?
>
>  
>
> Greets,
> kos
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
w

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


Re: [Tagging] Feature Proposal - RFC - survey_point:benchmark

2020-03-10 Thread Greg Troxel
Anne-Karoline Distel  writes:

> I've been surveying benchmarks for the past four months and I would like

I'm glad to hear that.

> to propose an alternative to benchmark=yes for survey points:
> https://wiki.openstreetmap.org/wiki/Proposed_features/survey_point:benchmark
> The reason being that I would like to also propose
> survey_point:hexagonal_bolt and survey_point:ground_bolt with it.

I think this is blurring two separate concepts: a particular logical
purpose of passive survey control mark, and the form of such a mark.

In the US, we use "benchmark" to refer to a passive mark for elevation,
essentially always by leveling.  We use "triangulation station" for
passive marks for horizontal controls, and I'm not sure but perhaps
ellipsoidal station for those which use GNSS to establish 3d coordinates
relative to the ellipsoid of a datum.

For all of these, the big point is that there's some reference that can
be recovered, and the exact physical form is not that important.

While the above words are guided by my understanding of US practice, the
historical separation of horizontal and vertical control networks and
the move to GNSS and ellipsoidal positions is I think pretty universal.

So I would suggest that there be tags for type/purpose, keeping in mind
that some physical marks were both horizontal and vertical controls.

It makes senes to have further tags for the physical type of mark.
>
> Definition: Ordnance survey point usually chiselled in stone with its
> typical horizontal bar and arrow below on vertical surfaces, dot with
> arrow below on horizontal surfaces. Now often replaced by hexagonal
> bolts in walls or bolts in the ground.

That sounds very UK specific.   In OSM I think we need to have
descriptions that people everywhere can interpret and make sense of.

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


Re: [Tagging] amenity=faculty?

2020-02-04 Thread Greg Troxel
Mateusz Konieczny via Tagging  writes:

> Universities may have faculties, that often deserved to be mapped separately.
>
> For example university may take a large area, possibly disjointed area across 
> the city
> but Faculty of dentistry, Faculty of forestry, Faculty of mathematics etc may 
> be
> possible to be mapped as an area/node.
>
> Currently typical way to do that is to either
> - map name on building
> - create fake amenity=university with amenity=university
>
> It seems to me that amenity=faculty would be useful.

Perhaps, but beware that in US English, this is bizarre usage.  Faculty
refers to the set of people that are professors, not a place, and not a
subdivision of a university.

As an example, one well-known University has within in
  School of Science
  School of Engineering
  School of Architecture of Planning
  School of Humanities, Arts, and Social Sciences.
  School of Management
and
  College of Computing

I'm sure other universities contain within them colleges, and I suspect
"school" is fairly common.

Really my point is that "Faculty of mathematics" is going to be
confusing to en_US speakers.  I have no idea if it's used in en_GB, but
I've never heard of it.


To your real point, it does seem make sense to have a tag for a
subdivision of a university.   But, often these sub-parts are
administrative and not physical.

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


Re: [Tagging] Disputed territory mapped as a country

2020-01-27 Thread Greg Troxel
Martin Koppenhoefer  writes:

> Mateusz, offlist deliberately.

While we're at it, could the list admins fix the BROKEN REPLY-TO?

___
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 Greg Troxel
Jmapb  writes:

> Hi all, just noticed this passage on the cycleway=* wiki page (
> https://wiki.openstreetmap.org/wiki/Key:cycleway ):
>
>> For mapping a separate path (on a separate way) dedicated to cycling
>> traffic use highway=cycleway. Foot traffic is restricted on these paths.
>>
>>   *  Do not use highway=cycleway on paths for both cyclist and foot
>> traffic (such as shared paths). Instead use highway=path with
>> bicycle=designated and foot=designated. Add also segregated=yes or
>> segregated=no) as applicable.
>>    * For paths where cycling is not permissible use highway=footway.
>> If cycling is permissible even if it is not signed but legally
>> permissible on a path, use highway=path (and a combination of the
>> segregated key and designated tag as applicable) and not highway=footway.
>
> (This was added by wiki user Aaronsta last May, with no change description.)
>
> Does anyone know if there was a discussion, here or elsewhere, that led
> to this change?

This smells like wikifiddling.

> My own impression over the years has been that mappers use
> highway=cycleway on anything that primarily for bicycle traffic, and add
> access keys for any other permitted traffic. Similarly for
> highway=footway. So "highway=cycleway + foot=yes" and "highway=footway +
> bicycle=designated" are quite common. Is there a general consensus that
> these are better mapped as highway=path?

Overall, I have come to believe that

  highway=cycleway

is *exactly* the same as

  highway=path bicycle=designated

and that any renderer or router that treats them differently is wrong.

However there is the messy issue of default surface values, avoidable by
tagging the surface.

> If so, we might want to consider standardizing the highway=cycleway and
> highway=footway wiki pages with this same rule. And also editing the
> highway=path page, which currently says it's not for use in urban
> situations.

The notion of urban vs not is messy.  I agree that's been part of the
evolving not-really-consensus over the last 10 years.

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


Re: [Tagging] What values of 'emergency=' should be on the main Map features page?

2020-01-19 Thread Greg Troxel
Joseph Eisenberg  writes:

> That tag is probably emergency=suction_point - seems much better to
> tag that rather than identifying the whole pond.
> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency%3Dsuction_point

Sounds basically reasonable to me.  The page does not make it clear if
this is just a place you can put a hose in, or if the piping is
pre-installed.  What I'm talking about is a red 3 or 4" pipe that runs
from under the middle to the edge with "FD Water Source #6" sign or some
such.   Maybe that's what

  emergency=fire_hydrant + fire_hydrant:type=suction_point - strange 
alternative tagging

is all about.

But I don't see getting that straightened out as a bar to what you want
to do.

> That's probably emergency=assembly_point -
> https://wiki.openstreetmap.org/wiki/Tag%3Aemergency=assembly_point

That's exactly the kind of thing I meant.  So no objections to your
plans here.

>>> ) =landing_site "Preselected flat area for a helicopter to land in an
>>> emergency" 2543 uses
>>> - Uncertain: the tag aeroway=helipad is more common, and the
>>> distinction  is unclear
>>
>> There is a difference between a helipad and a place for an emergency.
>> Around me helipads are fenced and have lights, and landing there is
>> within normal practice.
>>
>> There are also pre-planned sites for medical helicopters to land, and
>> these are definitely not helipads.  They are merely places that are hard
>> enough surface and open enough (no poles or wires) that a Medflight or
>> police helicopter pilot can safely land and take off from.   Almost
>> always some fire department equipement/people are sent to secure the
>> landing site and provide lighting / denote the center with headlights.
>
> Ok, that makes sense. I actually know of a number of these which I
> could map (I sometimes fly along with the local helicopter medevac
> service).

So sounds like you are not going to remove landing_site?

In addition to real helipads and merely planned places, I have also seen
a crazy-extra-wide turning circle at the end of a road to a ~mountain
hiking trail, with paint marks that are obviously about helicopters.
But I am 99% sure this is for medevac only -- I think they just expect to need
it more often given the trail steepness, and there wasn't anything
close, so they cleared and paved a 100' circle (and you can park around
the edge only, IIRC).

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


Re: [Tagging] What values of 'emergency=' should be on the main Map features page?

2020-01-18 Thread Greg Troxel
Joseph Eisenberg  writes:

> 2) =fire_water_pond " A man made or natural pond with water for a fire
> department." 2785 uses
> - Remove: This tag isn't verifiable, or else it could be added to any
> pond or small lake. It's not much used outside of Germany.

Around me, there are things that meet this definition, and have
standpipes installed.  So it's quite verifable.  However, if the pipe is
tagged as some kind of hydrant, and the water is tagged, that seems
sufficient.

> 3) =access_point "A sign number which can be used to define your
> current position in case of an emergency" -  uses
> - Remove: the similar tag 'highway=access_point" is much more common
> and was approved.

I have seen, in company parking lots "evacuation assembly point #6" or
signed for some floor/building.  These are for people, not  a highway
thing.   I think it makes sense to map them.  Do you think this usage is
what the tag is about?

> These 3 I don't know how to handle:
>
> ) =landing_site "Preselected flat area for a helicopter to land in an
> emergency" 2543 uses
> - Uncertain: the tag aeroway=helipad is more common, and the
> distinction  is unclear

There is a difference between a helipad and a place for an emergency.
Around me helipads are fenced and have lights, and landing there is
within normal practice.

There are also pre-planned sites for medical helicopters to land, and
these are definitely not helipads.  They are merely places that are hard
enough surface and open enough (no poles or wires) that a Medflight or
police helicopter pilot can safely land and take off from.   Almost
always some fire department equipement/people are sent to secure the
landing site and provide lighting / denote the center with headlights.

These are verifiable, by talking to the fire department people or
observing them being used.

Perhaps there should be some other tag, but the concept is entirely valid.


(I am unclear on map features vs key values.)

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


Re: [Tagging] Public WLAN boxes

2019-12-19 Thread Greg Troxel
Tom Pfeifer  writes:

> On 18.12.2019 16:26, Andy Townsend wrote:
>> On 18/12/2019 15:22, Tod Fitch wrote:
>>> In the U.S. it would be called wifi or wi-fi rather than
>>> wlan. Anyone know what the British English is?
>> In the UK it's also "wifi" or "wi-fi", but wlan is understood and
>> has considerable establishment in OSM:
>
> Wi-Fi vs WLAN is not AmE vs BrE,
> WLAN is the technical term, standing for Wireless Local Area Network.
> It is standardised in the IEEE 802.11 series, using "Wireless LAN" in the 
> title.
> Wi-Fi is a brand name, introduced by the Wi-Fi Alliance.
>
> OSM should therefore continue to focus on the standardised, generic term WLAN.

I'm glad I read the end of the thread before responding.  Tom has it
100% right.



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


Re: [Tagging] Rail segment in a bike route

2019-12-15 Thread Greg Troxel
Martin Koppenhoefer  writes:

> sent from a phone
>
>> On 14. Dec 2019, at 08:02, Francesco Ansanelli  wrote:
>> 
>> Thanks everybody for the feedback.
>> I've added the bicycle=dismount on the railway.
>
> if I saw this I would think I’d have to push the bike there, not take a train

It seems bicycle=no is in order.

I don't see the problem with a bicycle route having segments with
bicycle=no, which is a clue that you have to travel some other way over
it.

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


Re: [Tagging] disguised communication towers

2019-11-15 Thread Greg Troxel
Greg Troxel  writes:

> So for your strategy, I would say
>
>   1) convince mappers that this is important.   (Perhaps argue that it's
>   more important than the vertical_smoothness tag for peopel who ride
>   bicycles vertically on the tower -- and yes that's a bad joke.)
>
>   2) wait for a long time for others to adjust the tags, maybe 5 years
>
>   3) use the tagging scheme as you would like it to be

And I meant that to be rhetorical rather than nasty.   I am just trying
to say that you only get to process tags based on what most other people
think, and if you are on the leading edge of caring about something
(which I think you are), then it isn't going to work.

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


Re: [Tagging] disguised communication towers

2019-11-15 Thread Greg Troxel
Eric Theise  writes:

> From my morning reading it seems that entities tagged with
>
>   tower:type=communication
>   tower:construction=concealed
>
> and either man_made=mast or man_made=tower should cough up cellphone towers
> masquerading as cacti, palms, pines, flagpoles, and such. But apart from a
> note="pine tree" that jumped out at me I'm not finding much. I have to
> assume I'm barking up the wrong tree (sorry).

Around me, most cell towers (as we call them) are not disguised.  A few
are, and they look like fake pine trees, and are usually really
obviously fake.  People, including me, who add cell towers very likely
have no idea that anybody carees that they have fake branches on them,
and don't consider this all that interesting and don't bother to tag it.
The presence of fake branches simply means "the local Planning Board or
Zoning Board of Appeals required fake branches, and the cell company
decided that paying for fake branches was cheaper than arguing about
it".

So for your strategy, I would say

  1) convince mappers that this is important.   (Perhaps argue that it's
  more important than the vertical_smoothness tag for peopel who ride
  bicycles vertically on the tower -- and yes that's a bad joke.)

  2) wait for a long time for others to adjust the tags, maybe 5 years

  3) use the tagging scheme as you would like it to be
  

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


Re: [Tagging] emergency=ambulance_station vs amenity=fire_station

2019-11-10 Thread Greg Troxel
Jan Michel  writes:

> On 10.11.19 13:51, Dave F via Tagging wrote:
>> Hi
>>
>> Simple question (which I presume has been previously discussed) :
>>
>> Why the different key tags to describe what are essentially
>> synonymous entities?
>
> One of them takes care to put out fires, the other transports you to
> hospital. There are regions where the two are mostly combined, but in
> other places these are completly separate organizations.
>
> E.g. in Germany they are mostly combined in the larger cities, but
> usually separated in smaller towns. That's related to having
> professional fire fighters and stations that are always manned
> compared to volunteers who have to gather first.

The sometimes-together sometimes-separate notion is also true in the US.

Typically, a Fire Department (sometimes called Fire Rescue) will also
operate ambulances.  Often these are painted like fire trucks, and the
staff are qualified as both firefighters and EMTs, employed as
firefighers, and in the IAFF/etc.  Almost always the station that houses
an ambulance has other fire equipment and thus these are "fire
stations".  These ambulances operate on the FD radio frequencies and are
dispatched as fire units.

Sometimes, these ambulances are Advanced Life Support (ALS), also called
paramedics.  When operated by fire departments, staff are typically both
firefighers and EMT-P.

Fairly typically, there are separate non-transporting paramedic units,
basically 2 EMT-Ps with gear in an SUV.  These are often not operated by
fire departments, and the people are EMT-P but usually not trained as
firefighters (unless they have one job with a FD and one with an
ambulance company, not so unusual).

In some towns, the fire department does fire fighting and "heavy
rescue"/"technical rescue" but not ambulances and they arrange with
ambulance companies for ambulance and paramedic services.

Not that you brought this up, but there are also fire department units
called "Rescue" that are big trucks with specialized equipment for
jacking up cars to get people out from under them, cutting them out of
cars, ropes for high places, confined space rescue, etc.




In some places, and in my experience this is in larger cities only (e.g,
Boston), there is a separate "Emergency Medical Services" department
which staffs ambulances and paramedic units.  In NYC, it's a separate
part of the fire department.  The staff are not firefighters and wear
different uniforms.  In Worcester, it's run by a university-associated
hospital and acts like a city EMS department but technically is
contracted.  The place where those ambulances are staged would not be
called "fire station".


So I agree these tags should be kept separate.  As for emergency= and
amenity=, that's a historical artifact and doesn't matter.

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


[Tagging] the nature of large-scale paid edits (was Re: Service road)

2019-11-07 Thread Greg Troxel
Dave F via Tagging  writes:

> On 06/11/2019 18:04, Greg Troxel wrote:
>>
>> I think a shared driveway is still a driveway.
>
> This is the crux. The only distinguishing attribute from what we'd all
> tag as a driveway is that's it's shared.
> A driveway is designated as privately owned rather than by the local
> authority. It isn't defined by how many own it.
>
> As Greg pointed out no one gave it a specific name in this thread. All
> references were to it being a 'shared driveway'.

And I guess, if it's not service=driveway, how does one claim it it is
still highway=service?

>> If other people had tagged in driveway, and amazon removed it as part
>> of a large-scale paid edit, I think that's totally not ok.
>
> I'm unsure if this is a blanket policy of Amazon, I think it maybe
> just this one editor.

If it's just one editor, that's not a big deal.

>> I see large-scale paid edits as part way to mechanical edits, and think
>> they have to be more deferential than normal mappers.
>
> I really think OSM as a whole needs to steer away from considering
> edits based purely on their size as something to be fearful of. As
> long as the data is accurate & improves OSM's database quality then it
> should be welcomed.

Certainly; I didn't mean to suggest that edits that meet OSM's norms
should be unwelcome.

My point is that we have a lot of mappers and a set of norms (which are
pretty fuzzy and/or a bit contradictory).  We have rules about
mechanical edits (including imports), since they change things in a
large-scale systematic way.

When we have a very large set of edits that are under the common policy
direction of one entity, then that starts to have some of the
characteristics of mechanical edits.

We have had problems in Massachusetts with Amazon mappers removing
landuse=conservation (which has been deprecated world-wide by the
boundary=protected_area fans -- who *wrongly* think it has the same
semantics -- but landuse=conservation is very much in use in
Massachusetts, whose people are not vigorous wiki fiddlers).

So what I meant is that adding driveways that are actually there (which
by all accounts is what they are doing), tagging them as driveways, and
access=private, is all 100% great.

But, any removal of service=driveway from shared driveways, if under the
guidance of the organization, is not ok.  I am not aware of them
publishing their guidelines; perhaps someone in Amazon management will
speak up in this thread and point to where that is published.

> With Amazon specifically, the data is coming from their GPS recordings
> & is being gradually added. (Unsure whether the contributors being
> paid makes any difference). Overall I'd say their edits contain the
> same amount of errors as the average OSM contributor.

Being paid makes a difference because paid people do what they are told
by the people paying them.  So an edit with 1000 paid mappers has a very
significant aspect of a mecchanical edit.

When the the guidance is "add driveways that we know exist from GPS, and
tag them highway=service service=driveway access=private", then
everything is fvine, because that's what a normal mapper who had the GPS
data and the inclination to spend time on it would do.

So I'm not opposed to large-scale paid editing; i just think it needs
some caution and that the guidance to paid mapeprs needs to be
published to the OSM community.

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


Re: [Tagging] Service road - Can it be a driveway if serving multiple houses?

2019-11-06 Thread Greg Troxel
Dave F via Tagging  writes:

> In the UK, Amazon Logistics are adding useful data from their GPS'd
> delivery vehicles. Mainly highway=service as the last part of their
> journey to a destination.
>
> However, one of their contributors removed service=driveway from a
> highway=service road. In the changeset comments they said it was
> because it served multiple residential properties.
>
> https://www.openstreetmap.org/changeset/76576604#map=19/51.33398/-2.27945

I think a shared driveway is still a driveway.   That's why we call it
"shared dirveway".  The difference at some point between "shared
driveway" and "road in a subdivision" is perhaps in terms of the number
of houses, but in Massachusetts is very much about the land ownership
and the road being its own lot.

As for "signed as private", around me it is fairly unusual for
residential driveways, shared or not, to be signed "private" or "no
trespassing".  I'd guess 1 in 100, and maybe 1 in 20 of very long ones.
It's obvious to those who are paying attention what is a road and what
is a driveway, usually because width makes it clear, plus the lack of
road sign.  So I think mapping as access=private is appropriate even if
not signed, because on a driveway on private property the public does
not have a right of access, even if they aren't "trespassing after
notice".

If other people had tagged in driveway, and amazon removed it as part
of a large-scale paid edit, I think that's totally not ok.   If they are
just declining to add drvieway tags while putting in ways, that's fine.
I see large-scale paid edits as part way to mechanical edits, and think
they have to be more deferential than normal mappers.



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


Re: [Tagging] lit=yes/no threshold

2019-07-07 Thread Greg Troxel
Michael Patrick  writes:

> You'd probably be okay using the 10 lux indicated by the Illuminating
> Engineering Society. But considering that the illuminate area is uneven ( a
> notion also covered in the standard ) and usually fairly extensive, and
> illumination measurement is a technical skill, and it is a moving target
> because of the daily cycle and weather, it probably isn't practical o
> expect some member of the general public to collect the data.

Agreed that most mappers cannot measure this, and that all mappers
cannot measure it easily.

About IES and 10 lux: in my town that is considered very high, and in
parking lots beyond what is allowed.  A parking lot that ranges from 0.5
to 3 lux is considered lit.  Average illuminances tend to be 3-4ish, if
built according to our light polllution bylaw.  (I realize that typical
city notions of what is appropriate are different.)


So, saying that something under 10 lux is "lit=no" would not be ok.

I tend to leave the definition alone and not worry that people are
making judgements in marginal cases.  If there are fixtures installed to
light something, and they are doing what was more or less intended, then
it's lit=yes, even if the level is lower than somebody else might like.

To me, marginal cases include:

  there were lights installed but they are now not working well (but
  somewhat).  This is rare enough not to worry about.

  on a walkway in the city, where there are no fixtures intended to
  light the walkway, but due to ambient light from many nearby sources,
  there is a level of 1 lux or more

This second case could arguably be lit=no but it's also dark=no.

I like the suggestion of needing to use a flashlight.   I don't think we
should get too hung up on the edges of subjective.   A notion might be

  Do more than 50% of the users of the path either use a flashlight or
  wish they had one to use.

which is of course fuzzy, but people making that judgement in good faith
are unlikely to have serious arguments.  For cases right on the edge, it
doesn't really matter how they are tagged.

Beyond this, recording illuminance levels makes sense, even though
that's another can of worms.



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


Re: [Tagging] lanes = 0

2019-06-23 Thread Greg Troxel
Paul Johnson  writes:

>  In that example, I think it'd be better to just tag width=* instead of
> lanes=*.

Perhaps, but then data consumers have to figure how how many cars are
supposed to be side by side.  That number really is local convention;
one road I use is really not wide enough for 2, but people always do it.
So I favor using the lanes tag to specify how many lanes are actually
typically in use.  Then with width one can get the average width of
those.

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


Re: [Tagging] lanes = 0

2019-06-21 Thread Greg Troxel
Joseph Eisenberg  writes:

> This requirement is fine for Europe, but the presence of lane markings
> is not reliable in all of the world.
>
> In developing countries, such as here in Indonesia, the presence of
> painted lane markings is inconsistent. Often cheap pain is used
> instead of more durable thermoplastic, so the markings only last a
> year. After that the road still functions the same, even though the
> markings are no longer visible.

It is not just about developing countries.  In my part of the US, there
are many roads whicha have either no paint at all, or have white lines
at the edges (so you can see where the edges are at night).   Almost all
of these roads are wide enough for two cars to pass comfortably, but not
really wider than that.  This seems really obviously one lane in each
direction, and everybody who drives here gets that.  There is a legal
requirement to stay on the right of the imaginary center lane (absent a
reason such as passing a pedestrian); you can be cited for "operating
left of center" entire reasonably on a two-cars-wide road with no
markings -- but that will only happen if you are left of center
egregiously or on a blind curve or rise.


So that's a long way of saying that "lane markings" should not be
required for lanes=N; it is enough to observe the local conventions.

I agree that a finer-grained tag that says if there are markings or not
is sensible.  But the most important thing is to describe how traffic
actually behaves.

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


Re: [Tagging] Verifiability wiki page: "Geometry" section added

2019-04-28 Thread Greg Troxel
Paul Allen  writes:

> On Sun, 28 Apr 2019 at 21:23, Martin Koppenhoefer 
> wrote:
>
>> I cannot imagine houses that are several kilometers away being part
>> of a hamlet, in a settlement sense. Can you give an example please,
>> maybe this can occur in very low density areas?
>
> Remote farms have to be somewhere.  At least as far as the postal
> service goes.  Well, that's true of the UK, maybe not in other
> countries.  We don't have addresses like "Womble Cottage, Middle of
> Nowhere, UK," even if the cottage is, in fact, in the middle of
> nowhere.

We have multiple separate concepts:

  postal addresses (where what the post office says is your address is
  what it is)

  legal addresses (according to the government, and perhaps what shows
  up for 911/999 purposes; in my state it is legally required to display
  your house number)

  admin boundaries

  geography of populated places (hamlet, village, town, usually as
  points)

It can certainly make sense to draw fuzzy lines for the hierarchy of
populated places, but of course they remain fuzzy.  This is quite
separate from the other 3 things.

Presumably the addr:foo tags are about legal addresses.

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


Re: [Tagging] Avoid using place=locality - find more specific tags instead

2019-04-18 Thread Greg Troxel
Warin <61sundow...@gmail.com> writes:

> On 18/04/19 09:52, Joseph Eisenberg wrote:
>>
>>
>>
>> But if a locality represents only a historic location that has no
>> physical presence today, it is debatable if this is a “real and
>> current” feature that is appropriate for OSM rather than a
>> historical map.
>
> If the name is still in present use then it belongs in OSM, even if
> there is no physical presence on the ground people still use the name
> to define the place.

Agreed.  Around me, my impression is that most place=locality are place
names that people use.

Part of the core issue is the separation between our modern notion of
place as defined by administrative boundaries vs. the older notion of a
town/village center and things that are near it.  At least in the
northeast US, I think there's a been a vast shift in the past 200 years.

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


Re: [Tagging] what is the meaning of bicycle=yes on highway=path

2019-04-13 Thread Greg Troxel
Volker Schmidt  writes:

> Another thing:
> Greg writes:
> " "highway=footway" has exactly the same
> semantics as "highway=path foot=designated". ...Note that both leave
> bicycle and horse as
> implicit"
> I think this is wrong: highway=footway excludes bicycle, or at least the
> footway wiki page is misleading, as the photo shows clearly a footway with
> a traffic sign, that explicitly excludes all other types of traffic.

Perhaps in Europe there are rules like that.  In the US things labeled
footway often allow bicycles.

The real issue is that there are a lot of implicit rules for what values
tags should be assumed to have, and it is a combination of lore and
wiki.  It should be a machine-readable description that data consumers
can use.

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


Re: [Tagging] what is the meaning of bicycle=yes on highway=path

2019-04-12 Thread Greg Troxel
Richard Fairhurst  writes:

> Volker Schmidt wrote:
>> "highway=path" implies "bicycle=yes" (in most jurisdictions) - see the
>> proposed Default-Access-Restriction for all countries
>
> That's not a default that I feel enormously comfortable with. Whatever the
> wiki might say, "bare" highway=path (no other tags) is often used for little
> footpaths across city parks, sidewalks, and so on.
>
> cycle.travel errs on the side of caution and therefore doesn't route along
> highway=path unless there's an explicit access tag (or cycle route
> relation).
>
> Keeping bicycle=yes on bikes-allowed paths is useful information. If there's
> no bicycle= tag, yes, it could mean "bike access is implied by a default
> somewhere on the wiki" but it could also mean "this way is tagged
> incompletely". Deleting the tags would remove information and make it harder
> for routers to deliver real-world routing results. Please keep them.

Strongly seconded.  Richard has it 100% right here, and has explained it
very well.  I would consider removing bicycle=yes from highway=path to
be damaging and antisocial.

As far as path having some legal definition of access rules, I would say
that's very far off base in the US, as paths are usually on places where
the property owner (even if the government) can set rules, as opposed to
streets which are owned by the government where access is controlled by
statute, more or less.  It is very normal for paths in conservation land
in the forest to allow only foot travel, or also bicycle, or also horse
and bicycle both.

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


Re: [Tagging] what is the meaning of bicycle=yes on highway=path

2019-04-12 Thread Greg Troxel
Joseph Eisenberg  writes:

> "an armchair mapper should add access=unknown to the tagging"
>
> I certainly don't do this when mapping from aerial imagery, and
> neither of the editors that I've used (ID and JOSM) have suggest
> adding "access=unknown" to a newly mapped path.

I only add access=unknown when even when being local and visiting the
access situation is unclear.  I view it as a clue to other mappers that
work needs to be done.

> My understanding is that highway=path is rather problematic if there
> are no additional tags, because it's not clear if all paths are open
> to bicycles or horses. See

Well, it's certainly less precise than having horse/bicycle explicitly,
but I don't think people should refrain from adding a highway=path
because they don't know about horses or bicycles.  One always has to
view default access (for other than legal roads) with at least a tiny
bit of skepticism.

If you mean "given a highway=path without horse/bicycle tags, it is an
improvement to the map to add them, even if they are yes", I agree.

> And https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath says:
>
> "highway=path is a generic path, either multi-use or unspecified
> usage, open to all non-motorized vehicles and not intended for
> motorized vehicles unless tagged so separately. The path may have any
> type of surface."

I think the 'open to all' is a bit much.  I would read that as "unless
tagged explicitly, the default assumption is foot=yes bicycle=yes
horse=yes".  Which is also true on highway=tertiary, for example.  So
it's not so much an assertion that to be a path it must be open to all,
but a statement that when interpreting a path, if there are no access
tags for bicycle/horse, then a router should assume they are implicitly
yes.

> "This includes walking and hiking trails, bike trails and paths, horse
> and stock trails, mountain bike trails as well as combinations of the
> above."

sure

> "This tag is used for paths for which all and any of highway=footway,
> highway=cycleway and highway=bridleway would be inappropriate or
> inadequate (or simply not sufficient), but which are nonetheless
> usable for travel or navigation. They might be not intended for any
> particular use, or intended for several different uses. Intended uses
> can be indicated with the various access keys; e.g.,
> bicycle=designated and foot=designated."

This is where it gets to be a non-useful distinction with multiple
schools of thought.

One school of thought is that "highway=footway" has exactly the same
semantics as "highway=path foot=designated".  The default render more or
less works this way.  Note that both leave bicycle and horse as
implicit.  I think pretty much everybody agrees with this, even if they
disagree on which is preferred.

Another school of thought, while not disagreeing with the above, says
that highway=footway means in addition a city/town kind of path that is
typically paved.  This school says that a trail in the woods, or
anything that isn't super well maintained, should be highway=path.  (I
have had nearby mappers ask me to follow this distinction because there
are "trail maps" that include path but not footway, because we do not
have trail tags.  Or if we do, it's path!)

But all of this does not bear on the horse/bicycle issue.


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


Re: [Tagging] I have been tagging mosques wrong all along

2019-03-23 Thread Greg Troxel
Jean-Marc Liotier  writes:

> On 3/23/19 6:04 PM, Greg Troxel wrote:
>> I find the implicit rules really problematic, as we don't have a
>> machine-readable repository of them that can be used to processs tags as
>> they are to the full logical set of what they mean.
>
> So, should the amenity=place_of_worship complex have landuse=religious
> too ? I wouldn't mind - if a consensus here believes so.

My view is perhaps a bit extreme, which is that ideally everything that
has human use would have some landuse tag.  I prefer explicit
representation of landuse and landcover both, with a clear logical
separation between these two concepts.

So in a situation where there is a church building and parking lot
(carpark in en_GB) on a parcel (area of land under one ownership), I
would put landuse=religious.  Same for something larger with more
buildings.

And if there were two unrelated churches on two adjacent lots, I would
ideally put only one landuse=religious object (which might get into
relations), since landuse is not about per parcel or per object, but
about groups of them.


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


Re: [Tagging] I have been tagging mosques wrong all along

2019-03-23 Thread Greg Troxel
Jean-Marc Liotier  writes:

> On 3/23/19 5:28 PM, Greg Troxel wrote:
>> Jean-Marc Liotier  writes:
>>> So, no landuse=religious anymore at all and no building=mosque for the
>> I don't understand why you think landuse=religious shouldn't be
>> present. It seems that all land used for religious purposes should
>> have that tag
>
> Redundancy ? I have the same issue for shop=* (or even amenity=fuel)
> also tagged with landuse=retail - same sort of redundancy.
>
> To me, amenity=place of worship is implicitly landuse=religious and
> shop=* is implicitly landuse=retail... Am I alone in thinking that way?

You are surely not alone :-)

I see having landuse as consistency, so that data consumers
understanding landuse can do so, without having a vast array of implicit
rules.

As for shop/fuel, I prefer shop etc. tags on the individual places, and
landuse=retail on the entire land area that is in use for that sort of
thing (including parking - the whole group of parcels).  That extent of
area cannot be inferred from the other tags.

I find the implicit rules really problematic, as we don't have a
machine-readable repository of them that can be used to processs tags as
they are to the full logical set of what they mean.

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


Re: [Tagging] I have been tagging mosques wrong all along

2019-03-23 Thread Greg Troxel
Jean-Marc Liotier  writes:

> So, no landuse=religious anymore at all and no building=mosque for the

I don't understand why you think landuse=religious shouldn't be
present.It seems that all land used for religious purposes should
have that tag, whether it's a smallish lot that just contains a
building, or whether it's a larger campus, and regardless of which
religion.  I do not understand the concept of separate rules per
religion about landuse tags.

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


Re: [Tagging] leisure=common replacement for public areas with some trees

2019-03-05 Thread Greg Troxel
leisure=common seems wrong for two reasons:

  the original notion of town common was land that could be used by all
  and was owned by the town or somehow public.   A bit of land that is
  grass in an urban area does not fit this.

  town commons were about grazing or perhaps a meeting place; calling
  them leisure seems very odd

Agreed with others that if it's just grass then just use landcover.

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


Re: [Tagging] Fixing import

2019-03-01 Thread Greg Troxel
Paul Johnson  writes:

> Honestly wouldn't be a bad idea for highway=road to be the default type for
> bulk imports, especially after the TIGER fiasco.

Another view would be that if an import seems like it should be
highway=road, then it isn't good enough data to import.

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


Re: [Tagging] Clarification unclassified vs residential

2019-03-01 Thread Greg Troxel
Mateusz Konieczny  writes:

> Mar 1, 2019, 8:48 PM by ba...@ursamundi.org:
>
>> On Wed, Feb 27, 2019, 13:57 Mateusz Konieczny <> matkoni...@tutanota.com 
>> > > wrote:
>>
>>> Feb 27, 2019, 7:31 PM by >> ba...@ursamundi.org 
>>> >> :
>>>
 motor_vehicle=no would exclude most emergency vehicles.

>>> No, it would not. motor_vehicle=no is a legal limitation.
>>>
>>
>> And most emergency vehicles are motor vehicles.
>>
> And emergency vehicle are exempt from traffic laws.

More or less true.   But the question is when OSM data is used for
emergency vehicle routin, what should be done?   Some things are still a
very bad idea, and some are ok but irregular.   The real point is to
compute a metric for traveling a route, so that the best  actual route
in an emergency is the lowest-weight route in the metric.

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


Re: [Tagging] amenity=police

2019-03-01 Thread Greg Troxel
Sergio Manzi  writes:

> The typical roles of the Coast Guard (/or whatever is called in
> different countries/) is maritime borders control and maritime law
> enforcement.

This is why it's hard.   Border control is sort of military and law
enforcement is mostly police.

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


Re: [Tagging] amenity=police

2019-03-01 Thread Greg Troxel
Graeme Fitzpatrick  writes:

>> The Border Patrol and other immigration people I would
>> sort into police.  They arrest people, rather than treating them as
>> prisoners of war (Geneva convention again).
>
> So would a Border Patrol / Customs office be tagged as a Police station?

That's a hard call.  First, Border Patrol feels more like police, and
Customs, not military, and not really police, similar to how the
Inspector of Weights and Measures that checks the meters on the gas
pumps isn't police.

> I certainly expect some other countries to be harder.

Agreed.

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


Re: [Tagging] amenity=police

2019-03-01 Thread Greg Troxel
Martin Koppenhoefer  writes:

> I wonder what we call "police" in OSM.
>
> The wiki does not offer a lot of guidance (France aside): "A police station
> is a building where police officers and other staff work and are dispatched
> from, and where suspects and evidence are collected and processed."
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpolice
>
> Is this limited to civil police forces, or does it include military forces?
> The French seem to include the Gendarmerie (military force under the
> jurisdiction of the Ministry of the Interior), and similarly we include the
> Carabinieri in Italy (adding also landuse=military).

I think the issue is that the line between police and military is
basically fuzzy.

In the US, we have a rule that says the military cannot be used for
domestic law enforcement.  This is at least mostly true, but then there
are edge cases where the National Guard (military) is mobilized during
emergencies.  Of course it's overwhelmingly likely that the rule isn't
100% followed; I once met two guys with green unlabeled jumpsuits and a
very fancy helicopter with an unreadable tail number at a rural airport
-- they said they were "testing" it, and I'm skeptical.  But most people
who see a few soliders walking or on the Metro view them much like
somebody else with a job going about their business, not like police.

> What about coast guards?

In the US, I view the Coast Guard as a cross between a rescue service
and a military service.  While they have a counter-drug mission, that
only seems to come up with regard to vessels entering US waters from
outside, as opposed to people staying in the US.  And, the Coast Guard,
although part of the Department of Homeland Security rather than
Defense, is widely viewed as more military than police.  They have the
same retirement rules as the Army, and USCG people are in TriCare health
insurance, set up for Army/Navy/Air Force.

> Typically there will be many kind of "police", according to what you count
> in, and this might eventually differ between countries.

Totally agreed.

Another big deal between military vs police is rules of engagement in
terms of use of force.  And, adherence to the Geneva convention, which
prohibts hollowpoint ammunition.  Basically in the US all police have
expanding ammunition, while the military uses fully jacketed.

I think each country needs to sort the various entities into military vs
police, along some notion of "defending the country from outsiders" vs
"domestic law enforcement" and clues about adminstration and reporting.
That consensus should be documented on each country's wiki page.

> E.g. in Italy there are (list is probably not complete):
> polizia postale, forestale, carabinieri, guardia costiera, polizia locale,
> provinciale, municipale, di stato, guardia di finanza, carabinieri,
> penitenziaria, ...
>
> For example it may be a question (and it might also differ, depending on
> the competences and duties they have in the country, whom they are
> subordinate, etc.) whether we count customs service as police, or prison
> officers, coast guards, maybe "intelligence services" in some occasions,
> foresters, etc.

Agreed that this is messy.

In the US, prison guards are "corrections officers" and not police, as I
understand it.  The Border Patrol and other immigration people I would
sort into police.  They arrest people, rather than treating them as
prisoners of war (Geneva convention again).

Broadly, local police are under a chain of command that goes to the
local government, state police to the governor, and federal police to a
cabinet official other than Secretary of Defense (or USCG/DHS).

But here, there's a pretty wide gulf in what happens and uniforms, if
you leave out some of the things that are intentionally invisible, and
perhaps the Border Patrol.  So I'd expect the "is this particular group
police or military" to be almost entirely uncontroversial here.  I
certainly expect some other countries to be harder.


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


Re: [Tagging] Clarification unclassified vs residential

2019-02-23 Thread Greg Troxel
Peter Elderson  writes:

> I was thinking further about the idea that came up here: deduct road type
> from the landuse=residential. It's different than current usage, and I dont
> think it is feasable.

I did not mean "deduce road type".   What I meant is that if a road is
at the lowest level of the road network (level5, below ABC and U, to use
UK terms), then I don't see why we should split that into

  level5_residential
  level5_not_residential

as part of the fundamental road type.  Both are minor, not used to get
from here to there, and one has houses, and the other doesn't.  But we
don't have

  primary_residential
  primary_not_residential

even though in the US that makes just as much sense as
level5_residential and level5_not_residential.

I was merely suggesting that if landuse=residential is tagged, then
anybody who cared about "is this area residential" could get the
answer.  Not that we should somehow infer "this is highway=residential"
and render it differently.

Do you think that level5_residential and level5_not_residential should
be rendered differently?

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


Re: [Tagging] Clarification unclassified vs residential

2019-02-22 Thread Greg Troxel
Florian Lohoff  writes:

> https://wiki.openstreetmap.org/wiki/Tag:highway%3Dunclassified
>   "Public roads of low importance within town and cities that are not
>   residential may also be highway=unclassified."
>
> Residential roads are by definition:
>
> https://wiki.openstreetmap.org/wiki/Tag:highway=residential
>   "This tag is used for roads accessing or around residential areas."
>
> So - bringing this together - as soon as there is residential usage
> it cant be unclassified? Am i so wrong?

I think that is actually wrong...

In the UK, an unclassified road is signed with U and a number.  There
can be houses along them.  There can be houses along A roads.  In the
US, I know of a ighway=secondary which is a "state highway", one level
down from "US highway", the non-motorway national system.  There are
some businesses on it, but there are many houses.  This is totally
normal.  But it's not tagged residential because of houses - it's
secondary because that's the importance in the road network.

So saying "if there are hosues it must be residential" is wrong.

Really the notion of "unclassified" is odd, and it probably should be
"quaternary".  Arguably residential should then be highway=level5,
regardless of housing, and perhaps some tag on all highways about
residential or not - but as I said earlier, you can tell that from
landuse.

But, I don't really expect this to change other than by slow drift.

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


Re: [Tagging] Clarification unclassified vs residential

2019-02-22 Thread Greg Troxel
Jan S  writes:

> Am 22. Februar 2019 17:59:28 MEZ schrieb Paul Allen :
>>Residential areas, to me, are
>>named localities.
>
> That may be true in Western Europe, but in many places in other parts
> of the world there may be areas of residential use that are not named
> or only have, sometimes even several, unofficial denominations.

In the US, what's a named locality, and what has enough houses to merit
residential are not causally located.  Except that a large number of
houses probably has a name.

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


Re: [Tagging] Clarification unclassified vs residential

2019-02-20 Thread Greg Troxel
Sergio Manzi  writes:

> One thing I'm quite sure, anyway, is that "unclassified" should mean
> just that: "/it doesn't fall in any other classification OR we don't
> know cr.p about it (we know there is a road there, but we don't know
> how it is)/".

But it doesn't mean that in the UK.  It means "in the national road
system, with a number, but not A B or C".  So it really is a higher
class than a road which is not ABC and is not unclassified, at least as
I understand it and observed it.

In OSM we use words by their OSM defintions, not what they ought to mean
in English!

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


Re: [Tagging] Clarification unclassified vs residential

2019-02-20 Thread Greg Troxel
The real problem is that if unclassified is more important than
residential, what to do with roads that do not merit unclassified but do
not have primarily residential landuse?



As I see it, in the United States unclassified and residential are
equally important.  However, this is likely to be seen differently by
people especially from the UK, and the tagging scheme carries baggage
in terms of default assumptions about how the world is.

(Leaving out motorways entirely because they seem easy.)

In the UK, we hear about A, B and C roads, and that is encoded in
primary/secondary/tertiary.  We adapt that to roads in other countries
that do not have A/B/C signs.

In the UK, there are also roads that are actually signed as
unclassified, such as "U1274" (wrong number, but I remember an actual
road in Scotland).  There, it seemed there were villages (or towns - not
sure what they call them) that are compact (with 30 mph signs) and then
"not in town" (with circle/slash signs).   I have the impression,
perhaps incorrectly, that roads in villages are "residential" and roads
not in villages are unclassified as a default assumption.

In the US, while we do have more and less congested areas, the notion of
"is this road residential" is often fuzzy.

Then, there are urban roads that aren't particularly important but have
businesses rather than houses.

So all in all I'd say the entire unclassified/residential scheme doesn't
really fit the non-UK world exactly right.  (Really, it's remarkable we
have so little trouble in internationalizing tagging, but then again I
live in "New England", called that for a reason.)

Part of the difficulty is that in the US we use route designators much
more sparingly.  In Massachusetts, we have state highways, which are
sort of like B roads (vs US highway A roads), but we do not have
numbered county roads.  So many roads with merely names are tertiary
because they are how you go from one town to the next.  (Other states do
number county roads.)

One fix would be to declare unclassified more important in the road
network than residential but less than tertiary.  And to add a
road=minor that is exactly equal in important to residential but does
not imply that the preponderance of use is residential.

Or, we could retag residential to minor, as residential landuse can be
encoded with landuse polygons.

Or, use residential to mean minor and ignore the house bit.

Finally, I'd suggest in the US treating unclassified and residential as
exactly the same in importance, because we have no real notion of
unclassified roads like the UK.   That does mean renderers have to treat
them this way, at least in countries that go this way.   (Certainly a
renderer could treat an unclassied road with "ref=U1274" as more
important, as a general practice of emphasizing roads with refs.")





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


Re: [Tagging] StreetComplete 10 / foot=yes on residential

2019-02-15 Thread Greg Troxel
Tobias Wrede  writes:

> Think of all the residential roads in cities that get a higher class
> tagging because of their function in the road network. They are mostly
> not different from hw=residential in regards to foot=y/n. And also the
> many roads outside built-up areas have mostly no restrictions.

Agreed.

> Roads with separate foot/cycle ways or with sidewalks are the clear
> minority and still are often the only means of traveling by foot.

I don't follow what you mean.  In the US, we generally do not have rules
that say that if there is a sidewalk you cannot walk in the road.  (We
(MA anyway) do often have a rule that you cannot ride a bicycle on the
sidewalk in a central business district.)

Are you saying that if there is a sidewalk this is a clue that the road
might be properly tagged foot=no?  I don't think that's a good idea,
unless there really is a law like that in the local jurisdiction.

Part of the issue in general, and especially with editing apps that try
to be more accessible to normals, is that people often do not understand
what the rules are, even in places they live.  They just more or less
know what is typical.

Arguably a pedestrian router should prefer sidewalks/etc. to the road
anyway.  We should not be encoding preference in access restrictions.


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


Re: [Tagging] StreetComplete 10 / foot=yes on residential

2019-02-14 Thread Greg Troxel
Joseph Eisenberg  writes:

>> The question asked is "Is this street accessible for pedestrians here?".
>> It doesn't ask for the user's opinion on how safe it is.
>>
>
> I believe this is the wrong question. It should be “Are pedestrians legally
> prohibited from walking along this road?”

Agreed.  The tag is about legal access and therefore a question intended
to set the tag must be phrased that way, clearly enough that app users
who *do not understand the tagging rules* will answer correctly.

FWIW, around me pedestrians may walk on almost any road except
Interstate Highways, and perhaps a few other roads that feel like that
(which would then be tagged individually as foot=no, bicycle=no,
horse=no, and perhaps the not really existing farm_equipment=no).  Not
long ago I saw a bicyclist on the side of a road that is clearly trunk:
2 lanes each way, divided, traffic lights every 1.5 miles or so, posted
45 mph with typical speeds 65 mph.   Very unsuual, but not prohibited.
And Paul has a good point that riding on that road on the right side of
the breakdown lane is arguably safer than on a lower-class road that's
far narrower.  A bicycle example, but applies equally to pedestrians.

I can see that there might be a frustration about OSM not having tags
that represent "would a prudent person think it's scary to walk here",
but the usual OSM response is to look for an existing tag and if not
define one.

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


Re: [Tagging] The actual use of the level tag

2019-01-20 Thread Greg Troxel
Here's a perhaps-radical set of comments and suggestion:

  in any building, there is a set of names (which often but not always
  look like numbers) for levels.  These are evident in the elevators
  (buttons inside, matching values outside) and in things painted on
  walls, on room numbers. etc

  In the US, you'll typically find something like B/G/2/3, corresponding
  to level -1, 0, 1, 2.   Presumably in the UK that's B/G/1/2.

  (probably not relevant) In the US, there is a star in the elevator
  next to the floor which is considered ground.  This is purely about
  how to get out of the building.  Basically, when you get in an
  elevator, if you wish to get outside, push the button with the star,
  and then follow exit signs.  Almost always, this is "G".

  In the US, you'll often find 12 and then 14, just because people who
  number floors think other people don't want to be on a floor numbered
  13.

  M (for mezzanine) is often in between G and 2, and often but not
  always has some notion of being less than a proper full floor

  some buildings have two different floors that are both at-grade in
  different parts of the building.

  therefore, floor numbering is not something that can be mapped to a
  number.  Instead, it is a set of names, which often look like
  sequential numbers.

  So,

 there should be a tag with a list of names in order, something like
 "B2 B G 2 3" (for a building with a sub-basement below the
 basement), and

 floor values should take on one of those names, and

 there should be a tag that denotes the floor that is most
 considered the ground floor, in the above case "G".

 probably do not try to think about buildings that have different
 ground floors in different places

This totally blows up the notion of numeric levels, but given the above
ordered list of floor names, one can compute an n-floors-above
relationship from any two floor names in the list.


Another example is a building I've been in with floor names

  P6 P5 P4 P3 P2 P1 G 1 2 3 4 5 6 7 8 9

yes, that is six levels of below-grade parking.  It might actually have
a B between P1 and G - I don't remember.  It had two sets of elevators,
one set P6-G, and one set G-9.

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


Re: [Tagging] Highway=*_link roads at Y-junctions and roundabouts?

2018-12-16 Thread Greg Troxel
Joseph Eisenberg  writes:

> While checking the rendering of highway link roads (eg motorway_link,
> primary_link, tertiary_link), I noticed that in some cases these tags
> are used when a road splits in a Y-junction, for example before a
> traffic circle / roundabout. In some areas these are the most common
> forms of _link for less major roads, eg secondary_link and
> tertiary_link.
>
> On the wiki there was some debate about whether it was correct to tag
> a Y-junction as leading into link roads, or if these should only be
> used for slip lanes and on-ramps which merge off of or onto the
> through-lanes of another road:
> https://wiki.openstreetmap.org/wiki/Talk:Highway_link

It seems that the Y roads should not be link.  link is about a
connecting road used when changing roads, and the last few feet entering
a rotary, especially when there is no other choice, does not fit that.

In particular, if a road wouldn't be tagged differently at a rotary, but
happens to be divided (dual carriageway) the last 50m, then it's fine to
make two ways, but not to change the way type.

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


Re: [Tagging] [Talk-us] Population during mandatory evacuations

2018-11-12 Thread Greg Troxel
Minh Nguyen  writes:

> (Crossposted to the talk-us and tagging lists.)
>
> Due to the ongoing Camp Fire in Northern California [1], the place POI
> for the town of Paradise got tagged with population=0 before the
> change was reverted. Following some discussion about this changeset in
> OSMUS Slack [2], I started a discussion on the wiki about preferring
> more stable population figures over supposition about temporary
> circumstances. [3]

That's really unreasonable that somebody would do that.

Obviously population is the number of people whose residence is in a
place, or something like that, not how many people are there this
minute.

It does get tricky for communities that have year-rounders and summer
people, where "residence" is blurry.  But everybody leaving for a week
does not change the population, just as people showing up for a parade
for 6 hours does not etiher.

On top of that, the idea that it's 0, between emergency people and
non-compliant people, does not in general seem credible, and if the
person making the edit was not actually there and able to judge this,
they're out of line on that basis too.


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


Re: [Tagging] New rag to draw node name with rotate angle

2018-11-10 Thread Greg Troxel
Dave F  writes:

> On 10/11/2018 14:46, Greg Troxel wrote:
>> Dave F  writes:
>>
>>> Every tag is for the renderer, otherwise all maps would be black lines
>>> & dots. As your link clearly states:
>>> /"Don't deliberately enter data *incorrectly* for the renderer"
>>> /
>>>
>>> The tag 'layer' is purely to aid renderings.
>> That's not true.  It represents things being above and below each other,
>
> And is used solely by renders to distinguish what you said. However
> 'Layer' provides no real world interpretation of height distance
> between objects.

It does not provide height, but it provides ordering.  Which is still
real world data, just less granularity.

>> In the case of tag saying what angle to draw something, that's a
>> specific drawing instruction, and I don't think it belongs.
>
> Along with an angle, a position tag for the label would be useful to
> avoid annoyances where it renders outside the perimeter of
> irregular.shaped polygons.

So would saying that a particular object should be green.  Once you add
specific drawing instructions, I don't see how to draw the line.

Can this really not be computed by renderers?   It just seems like an
optimization problem.

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


Re: [Tagging] New rag to draw node name with rotate angle

2018-11-10 Thread Greg Troxel

Dave F  writes:

> Every tag is for the renderer, otherwise all maps would be black lines
> & dots. As your link clearly states:

> /"Don't deliberately enter data *incorrectly* for the renderer"
> /
>
> The tag 'layer' is purely to aid renderings.

That's not true.  It represents things being above and below each other,
which is useful for more than drawing.

In the case of tag saying what angle to draw something, that's a
specific drawing instruction, and I don't think it belongs.  The right
angle depends on the map designer's intent and a lot of other things.
It seems far better for renderers to decide 1) if they want angled text
at all -- which is a major design choice and 2) hwo to choose the angle.


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


Re: [Tagging] mast / tower / communication_tower (again)

2018-10-26 Thread Greg Troxel
Martin Koppenhoefer  writes:

> sent from a phone
>
>> On 26. Oct 2018, at 01:57, Greg Troxel  wrote:
>> 
>> for all things which are not buildings and basically exist to support
>> antennas, and avoid the tower/mast word choice, which is pretty clearly
>> contentious and/or confusing.
>
> what about this: 
> https://upload.wikimedia.org/wikipedia/commons/1/11/Killesberg_Tower.jpg

That does not have as the almost entire purpose to support antennas.
There is substantial effort/expense to make it suitable for people in a
touristy way.  So I would definitely not call that
"antenna_support_structure".  And it's tall (that's the point) and not a
building, so calling in man_made=tower seems right.

> this is not a building, neither by the German nor by the English
> definition, but at least for Germans it is a tower.  I would not
> require for towers to be a building (which at a minimum should provide
> some enclosed space).

fair enough.  And I'm fine with this being tower in a world where
antenna supports are something else.

So where I think we are is:

  there is almost zero support for the notion that guy wires or not is
  critical and therefore these must not be part of definitions.  (Maybe
  just Graeme.)

  There are really multiple sorts of things we are talking about:

A) towers that are more than for antennas, like Tokyo, Killesberg,
Eiffel, and other similar things that aren't really buildings but
which have a significant purpose beyond holding an antenna up high

B) things that support antennas that are big enough that a person --
almost certainly a professional antenna repairer/installer or tower
maintainer -- can climb up inside of, or stand on some top platform.
Usually lattice or some sort of >1.5m diameter tube.

C) things that support antennas that have lattice or foot platforms
and can be climbed by people externally, sort of like a ladder, with
a climbing harness, again only by trained people for repair/install.
Like Rohn 65.  Probably includes 30cm tubes that have climbing
protrusions.

D) things that support antennas that are small enough that no person
can climb the outside.  Ranging from 2cm diamater to maybe 20cm.

In my usage
  A is a kind of tower

  B and C are "antenna tower" (separate from the A type tower) in the
  US.  I gather in the UK B is tower and C is mast.

  D is a mast in the US

I realize many here call A and B tower, and C and D mast.

B and C are often different only in scale.  For example, B coudl be
triangular lattic that's 1.2m on a side, and C could be 0.5m on a side.
Once you can climb inside, one you can't.  But they are almost the same
thing.

Perhaps the C tubes/steps belong in D.  It is arbitrary.

With respect to guys, I would expect A and B to be almost never guyed,
and C sometimes guyed (especially as it gets tall), sometimes not.  D I
would expect to be often short and not guyed, or taller and guyed.

So how we want to group and label these is really arbitrary.   But it
would be good if we agree on the 4 groups of reality and then group
them, and stop saying that guyed/not is critically important.

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


Re: [Tagging] mast / tower / communication_tower (again)

2018-10-26 Thread Greg Troxel

SelfishSeahorse  writes:

>> For an example of something used in communications (an American thing,
>> but totally normal and other countries surely have equivalent things
>> with the same characteristics):
>>
>>   http://www.rohnnet.com/rohn-65g-tower
>>
>> which says right there can be up to 500 feet when guyed and 80 feet not
>> guyed.  But it's the same thing in both cases -- it just needs more
>> support when taller where the forces get bigger.
>
> I'd call this is a -- either guyed or not guyed -- mast (because there
> is no internal access).

I'm ok with that, as long as we realize that we are defining words to
not line up with US usage.  That's fairly normal, but we should be clear
that we are doing it.

>> As I said earlier, things that are maybe 10cm in diameter are usually
>> called masts.  These are very minor and not really used in
>> telecom/broadcasting.
>
> Do you call this [1] a mast in the USA?
>
> [1]: https://commons.wikimedia.org/wiki/File:LeifersexTimZentrum.jpg

Yes.  I (a ham radio operator) would call that a mast, because it isn't
lattice (like Rohn 65).  But it's on the large/strong end of mast, vs a
2" / 5 cm tubing section.  The general public would call that "cell
tower", but then again they would refer to cell antennas bolted onto the
top floor of a building "cell tower" also - for them, it's a functional
term.  But most amateur radio people would call it tower or mast if just
asked "what's that", and almost all that said tower if you then said
"but really, is it a tower or a mast", would say "well, good point, it's
just a mast, but it's on the upper edge of mast ".

>> So maybe we just need
>>
>>   man_made=antenna_support_structure
>>
>> for all things which are not buildings and basically exist to support
>> antennas, and avoid the tower/mast word choice, which is pretty clearly
>> contentious and/or confusing.
>
> I'm not very convinced because that would mean that everything from
> this tiny mast on a roof [1] to the Tokyo Tower [2] would be tagged
> man_made=antenna_support_structure.
>
> [2]: https://en.wikipedia.org/wiki/Tokyo_Tower

I really mean things that have almost no other purpose.  That structure
is also a tourist attraction, and it seems to have been built for that.
So I would not call it antenna_support_structure.

Here's a photo of something near me for TV, with no other purpose (other
than other communication stuff also put on it).

http://gallery.bostonradio.org/2003-05/needham-towers/100-01179-med.html

This is definitely antenna_support_structure.

But I don't really expect people to like this proposal.

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


Re: [Tagging] mast / tower / communication_tower (again)

2018-10-25 Thread Greg Troxel

Graeme Fitzpatrick  writes:

> A mast is a tall, slim structure supported by guys, usually with external
> access only

This reliance on guys does not align with engineering reality.  guys are
needed depending on forces/loading, and there can be unguyed masts, that
are exactly like guyed masts but a bit shorter.

> A tower is a tall, slim free-standing structure, usually with internal
> access. (Possible include from wiki: "Towers are specifically distinguished
> from "buildings " in that they are
> not built to be habitable but to serve other functions.")

again towers can need guys if they are really tall (300m), even if they
are the same construction that would not need guys if only somewhat tall
(30m).   Guy wires do not make a tower not a tower, in the language of
antenna support structure.

Perhaps this is a UK vs US English thing, or a lay vs radio engineering
thing.  But your definitions (to a US engineering type) seem seriously
wrong.

Now, if you're coming at this from "tower is building that's mostly used
to get something high, and not for inhabitation" and "mast is an
antenna support structure that is not a building.  Note that things that
engineers call towers, such as structures made out of lattice like Rohn
65, are called masts in OSM because they are not buildings"  then I can
see that.  But in that case, there is no requirement for a mast to be
guyed.  I can certainly see a "guyed means not tower" in that world,
because buildings don't have guy wires.

For an example of something used in communications (an American thing,
but totally normal and other countries surely have equivalent things
with the same characteristics):

  http://www.rohnnet.com/rohn-65g-tower

which says right there can be up to 500 feet when guyed and 80 feet not
guyed.  But it's the same thing in both cases -- it just needs more
support when taller where the forces get bigger.

Around me, antenna support structures for cellular (mobile phones) are
typically 30' and I have never seen one guyed.  Some are tube-like
(because planning boards require that) and some are lattice.  But they
are not buildings -- they are antenna support structures that *maybe*
one person could climb inside of, but maybe not.  There are also antenna
support structures for TV, which are typically lattice and 300m tall,
and always guyed.  Everyone calls these towers.   To call the 30m ones
towers because they are not guyed and the 300m ones masts because they
are guyed makes zero sense in US English usage, either for the general
public or for engineers.

As I said earlier, things that are maybe 10cm in diameter are usually
called masts.  These are very minor and not really used in
telecom/broadcasting.

So maybe we just need

  man_made=antenna_support_structure

for all things which are not buildings and basically exist to support
antennas, and avoid the tower/mast word choice, which is pretty clearly
contentious and/or confusing.

> Do we need to worry about height for rendering purposes? (which is what
> this original discussion started from!) If so, would a simple break-down
> into height >30 (m), 30-150, 150+ work?

I don't know why you are proposing classes of height. It seems like
speed limits and road width that we should have a height tag and people
should make their best estimate, and renderers can do what they think
sensible.  Adding some sort of bins for heights in the tagging scheme
seems like unnecessary complexity that brings no value.


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


Re: [Tagging] Power=cable for low voltage lines?

2018-10-19 Thread Greg Troxel

marc marc  writes:

> Le 18. 10. 18 à 15:01, Greg Troxel a écrit :
>> the idea that people that don't understand the
>> power system can tell the difference doesn't really seem right to me.
>
> so how can my wife add a "this electrical cable" despite she has
> no idea what it means transmission <> distribution nor his voltage ?
> she chooses at random between line or minor_line with an error
> rate of 50% ?
> or should non-experts be forbidden to inform where a cable exist ?
> François' idea of structuring information by "layer" of detail from 
> basic to advanced info is full of common sense, damage too often reads 
> the argument "the value is widely used and I'm able to choice the good 
> tag so we keep the imperfection".

I think you are saying that power=line/minor_line/cable as a top-level
tag is wrong, and there shoudl be power=line with (optional) subtags for
the various things, like bare/covered/insulated,
disttibution/transmission, and voltage.

If so, I agree, but it's been explained that this fight happened a while
ago and what we have now is the outcome.

It seems in this case the OSM way is just to use power=line, don't
worry, and let others fix it up if necessary.

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


Re: [Tagging] Power=cable for low voltage lines?

2018-10-18 Thread Greg Troxel
François Lacombe  writes:

> Le mar. 16 oct. 2018 à 00:20, Greg Troxel  a écrit :
>
>> So I don't see how we can make "insulated" a big deal in tagging,
>> defining the top-level tag, rather than being a detail to add when
>> known.
>
> I agree with both of you Greg and Marc
> Nevertheless, this was a debate in 2013 and I was in favor to merge line,
> cable and minor_line
> https://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement#power.3Dminor_line_and_power.3Dminor_cable_replacement
>
> Due to power=cable and power=line usage in OSM, many contributors didn't
> want to mass retag power=cable.
> Then we all agreed on line/cable distinction in late 2014 or 2015.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Power_paths_refinement#Integrated_power.3Dcable

I guess that's how it is then :-(

> Note that insulation is also a draft proposal
> https://wiki.openstreetmap.org/wiki/Proposed_features/Insulation_proposal

That seems really difficult to deal with.  In particular, distribution
lines around me have a coating to provide mechcanicla protection but
which is not insulation in the electrical sense.  Even people with
engineering degrees cannot reliably tell this when looking at it from
several feet away.

> I'm still opposed to minor_line since in merge several different concept in
> one value, and is only useful for rendering.

If we morph it to distribution vs transmission, and say it means that,
it seems recoverable.

>> That said, I fully support your notion of tagging voltage, so that
>> low-voltage lines can be rendered only at extreme zooms, and to
>> assume a line is low voltage (240V seems like a reasonable default
>> assumption in terms of controlling rendering) if not tagged.
>
> Great, should we open an issue on carto github to propose to lower the
> rendering of cables without voltage?

I think you should go ahead and do that.  Basically power=cable or
power=line that lacks voltage should be treated as power=minor_line
voltage=250V.

In general I think it's good to have mistagged/undertagged things
rendered less, so that people will tag them to render, rather than
having to tag to unrender.

It would be intereresting to analyze the voltage tags on minor_line.
Probably there are none > 45 kV and few above 13.8 kV ish.

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


Re: [Tagging] Power=cable for low voltage lines?

2018-10-18 Thread Greg Troxel
Mateusz Konieczny  writes:

> In my case I am interested in differentiating major power lines and
> minor power lines without further details.
>
> Given power=liner and power=minor_line scheme existed before I joined
> OSM and is really popular I guess that I am not alone.

I find the wiki sort of unclear, and I'm also not sure that other
countries' power systems are the same as the US.

Is it fair to say

  power=line is for transmission (among generating stations and
  substations, including to dedicated substations for industrial
  customers that would be called "transmission-connected" in the US)

  power=minor_line is for distribtion (from substations to customers)

I find 45 kV as a limit odd; in my part of the US (and I think the rest)
distribution is normally at 13.8 kV, and if I encountered 45 kV I would
expect it to be very old transmission, not distribution.  Modern
transmission here is 115 kV (plus higher, which I'm ignoring), and
there's a fair bit of 69 kV around.

So if we think of minor_line as encoding distribution vs transmission,
then it makes sense.  But the idea that people that don't understand the
power system can tell the difference doesn't really seem right to me.

so questions:

  - Does this transmission/distribution dichotomy exist in substantially
all of the world?

  - Are there really distribution voltages much higher than 13.8 kV in
use?

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


Re: [Tagging] Power=cable for low voltage lines?

2018-10-15 Thread Greg Troxel
François Lacombe  writes:

> Basically in power language, a line is not insulated while a cable actually
> is.

A difficulty here is that mappers cannot tell a protective covering from
insulation.  I was at an open house of my power company recently and
they had a mockup of a distribution line, of 8 kV phase to ground (as
part of 13.8 kV 3-phase), connected to a transformer, and then 120/240
from the transformer to the meter - all very normal in the US.

However, I was told that the protective covering on the 8 kV line is NOT
insulation, even though it looks much like it.  It's there for abrasion
resistance to slow corrosion, and perhaps for added mechanical strength,
but it does not meet insulation specs.

So I don't see how we can make "insulated" a big deal in tagging,
defining the top-level tag, rather than being a detail to add when
known.

That said, I fully support your notion of tagging voltage, so that
low-voltage lines can be rendered only at extreme zooms, and to assume a
line is low voltage (240V seems like a reasonable default assumption in
terms of controlling rendering) if not tagged.

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


Re: [Tagging] mast / tower / communication_tower (again)

2018-10-09 Thread Greg Troxel
Graeme Fitzpatrick  writes:

> On Tue, 9 Oct 2018 at 03:58, SelfishSeahorse 
> wrote:
>
>> There is a risk that towers and masts are defined differently in
>> English, but perhaps Martin's idea to combine the two definitions
>> would make sense nevertheless.

Part of the issue is UK English vs US English, and usage common in
professional or amateur radio language vs public usage.

The same thing will be:

UK: Mobile phone mast
US: cell tower

> So, how about we clean up the various mixtures of definitions, &
> conflicting photos, to:
>
> man_made=mast: a vertical structure, supported by external guys and
> anchors. (Possibly also include: Has no internal access, can only be
> climbed by ladder?)

> man_made=tower: a tall, slim, freestanding vertical structure with internal
> access

The guy wires or not is made into the main thing here, but it's really a
detail.  In amateur radio, the same kind of tower (e.g. Rohn 45
sections, which are lattice) can sometimes be freestanding and sometimes
guyed.  Adding guy wires does not make them a mast.   There is a TV
antenna structure near me that might be 300m tall, is lattice, and it
has guys.  It is definitely "tower" by US usage.

In US amateur usage, mast often refers to something that is up to maybe
4" in diameter (and thus basically not climbable).  Often guyed, but not
always.  Basically, you add guy wires when you need to, which is a
function of material strength, height, wind loading of antennas on top,
and the wind levels you want the thing to survive.

In US cellular infrastructure, there are big lattice things that look
like someone obviously could climb them.  There are also things that are
several feet in diameter and round.  For all I know, these are the same
towers inside with a fairing to make them look better, and some may be
climbable internally.   But they are big, and function the same way, so
I would call them tower.

> man_made=communications_tower: to be deprecated (but also create a new
> tower:type=multipurpose for the massive 150m+ combined communication /
> observation / tourist attraction buildings)
>
> man-made=pole: (currently not defined) a usually vertical column used as a
> support for overhead utilities such as cables or antennae (Do we need a
> height reference eg a pole is <15m - if it's 15m+, it becomes a tower?)

So what's the difference between a pole and a mast?
A pole is used for power, and is usually wood, and a mast for antennas,
usually metal?

The world has a variety of shades of these things and there are going to
be edge cases.  The question is what we are trying to represent and why.
Arguably having a height tag is the most important thing for renderers.

So I would say of tall thin things to hold other things up high (which
leaves out arguing about vertical antennas):

  tower: anything lattice, anything > 1m diameter, anything > 50m high.
  ok to be guyed or not.  (so a 4m triangular lattice with 0.3m edges is
  still a tower, but that's ok with me)

  pole: anything not a tower, probably cannot be guyed, and either wood
  or > 0.25m diameter, such as is typically used for power lines (wood
  in distribution, and big wood or steel tubular in transmission (which
  also uses lattice).

  mast: anyhing not a tower or a pole.  ok to be guyed or not.
  Typically <= 0.1m diamater, but anything up to 0.25m is ok.

This definition proposal admits that these are all subtypes of the same
thing, and that things that people call towers are more substantial than
things called masts.

Really what I suggest is not so far from what you suggested, except that
I am de-emphasizing guying and calling anything that is big/substantial
by any of several metrics a tower.

I would probably also call broadcast antennas around 1 MHz "tower", even
though there the point is not to hold up something but the structure is
the antenna.  We could do the same for something used as an antenna that
is otherwise a mast.   Map users after all usually want to use these as
navigation references - at least that's why there are shown on
traditional nautical charts.

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


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

2018-09-19 Thread Greg Troxel

Philip Barnes  writes:

> And if the default actually applies, or has it been overriden by local 
> signage.
>
> I am not convinced that a default limit helps, if no speed limit has been 
> surveyed I would prefer that box not to be displayed in my app.
> a. It will not give me wrong and possibly costly information.
> b. It makes it obvious that I should survey and map the limit.
>
> Phil (trigpoint) 

Seconded.  It's actively harmful to display an incorrect limit.
Defaults will inevitably lead to it.

Using them for routing is ok.

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


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

2018-09-19 Thread Greg Troxel
Colin Smale  writes:

> A "maximum" speed does not mean an "advised" speed. If you are driving
> at an unsuitable speed, below the posted maximum, in Europe you will not
> get a ticket for "speeding" as such but you may get one for "dangerous
> driving" or something similar. The obligation to drive in a safe way
> overrides all other more specific limitations. Think of overtaking -
> just because it's not prohibited, doesn't make it safe (reasonable and
> prudent). 

Mostly agreed, but in the US you can get a speeding citation in this
case.  But usually you won't.

> There is no point in trying to reflect this "reasonable and prudent"
> stuff in OSM. We should stick to the objective limits, by virtue of
> signposting and/or statutes.

Certainly I agree that trying to encode reaasonable and prudent is
crazy.

From my US driving, I would agree that encoding the actual posted or
legal limit as maxspeed is entirely satisfactory for the purpose of
communicating limits to drivers.  For routing, it's necessary to know
that sometimes typical speeds are faster, in order to get good routes
(e.g. 45 mph posted, traffic normally 65, vs another road posted 40 mph,
traffic normally 43 mph).  Needing to use a slower prudent speed for
routing happens very rarely (around me).

In the UK, I found that the default 60 mph out-of-town limit was often
faster than I considered safe, and there a lower maxspeed:practical for
routing is in order.   US-only drivers will find this surprising.


Finally, I wonder how much of this is all about streetcomplete users
being asked to input limits when there aren't signs but there are laws.
OSM's notion of verifiability has in my mind (generally, not this
discussion) been expressed too strictly; looking up the law and noting
lack of signs is entirely adequate as verification for entering limits.



Overall, I think my most useful point is that maxspeed about the law and
speeds for routing are separate issues.

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


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

2018-09-19 Thread Greg Troxel
Tod Fitch  writes:

>> 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”.

I am not aware of *unposted* default limits in the US being different by
an entity smaller than state.   In Massachusetts, there are default
limits in state statutes, in particularly 30 mph in "thickly settled"
areas (also defined in statute).  Some towns have adopted 25 mph in
thickly settled areas, and they have signs at the town borders.

It's an interesting question at what level to tag individual roads and
when to have some way of expressing rules and therefore to expect all
data consumers to evaluate the rules.  My quick reaction is that
publishing rules for regions smaller than states is going to be too
messy, vs just tagging the ways.

With respect to maxspeed:default:residential, that's totally unworkable
in Massachusetts.  The law does not talk about roads or even define them
as residential or not.   The question for 30 (vs 40) is whether the road
is "thickly settled", which is

  built up with structures devoted to business, or the territory
  contiguous to any way where the dwelling houses are situated at such
  distances as will average less than two hundred feet between them for
  a distance of a quarter of a mile or over.

So there are many roads that are properly tagged "residential" but are
not subject to the lower speed.

In Mass, we have speed limit tags on almost all legal roads.  To me,
that seems like the most straightforward approach, even if there are
also defaults.

If the general defaults are intended for routing, that seems more or
less ok.  If they are intended to actually provide speed limit guidance
to drivers, I'm opposed, at least in jurisdictions where they aren't
strictly reliable.

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


Re: [Tagging] Slow vehicle turnouts

2018-09-12 Thread 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.


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


Re: [Tagging] Slow vehicle turnouts

2018-09-12 Thread Greg Troxel

Dave Swarthout  writes:

> Same here. I don't have any objections to either the abbreviation or the
> longer form. "smv" just seemed to fit well with the other abbreviations
> already in heavy use.
>
> Does anybody else have input on this?

I have significant discomfort with smv and a bit with slow_vehicle,
because hgv is a in OSM is defined as a vehicle with an allowable gross
weight (GVWR in US terms) over 3500 kg (that's not a bus or a passenger
car).  So a given vehicle is or isn't an hgv, and it doesn't change.

A slow vehicle, on the other hand, is any vehicle, regardless of actual
and permitted weight, that is driving below the prevailing speed in the
right lane, or is about to be because of a hill.  A vehicle that could
be driven at an adequate speed, piloted by someone who chooses not to,
is still a slow vehicle, and an empty truck might well not be.

So I would call it "climbing_lane", although I suppose there might be
such lanes not on hills.  A tag of "slow_vehicle" seems ok, because it
doesn't imply parallel structure with hgv.

I have seen roads that are often 1 lane and have a 5 mile section of 2
lanes.  But those are not really the same thing.


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


Re: [Tagging] delivery areas?

2018-08-24 Thread Greg Troxel

seirra  writes:

> I was thinking more to the tune of specific things like charity shops
> or smaller stores where it may not be standard

I think this doesn't belong in the OSM database.

If you could get shops to publish an API endpoint with a geojson of
their delivery area, we could add that URL, but putting in areas is
going to make editing painful and the likelihood of it being accurate
and usable seems very low compared to the pain.


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


Re: [Tagging] residents only after hours

2018-08-22 Thread Greg Troxel

Martin Koppenhoefer  writes:

> sent from a phone
>
>> On 21. Aug 2018, at 19:31, Greg Troxel  wrote:
>> 
>> If it's private, then access=yes is arguably not right, as permission is
>> granted to the public, vs the public having a right of access.
>
>
> “private” (not the osm key) is about private ownership. This doesn’t
> exclude a public right of access/way (the osm tag is about
> access). access=yes can be right for a publicly owned way (not for all
> of them of course, but it depends on the legal situation)

True; I was getting at public right of way vs permissive, separately
from ownership.

In this case, given the explanation that there's an agreement between
the owner and the city to permit public access at certain times, that
certainly meets the public right of way test.

In the US, there are a vast number of places where the public goes (at
normal hours), and they are not in fact public rights of way.  A typical
supermarket or other shopping area has parking lots, and footpaths, etc.
In OSM we typically don't have access tags on them.   But if we did,
access=permissive is more likely right than access=yes.





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


Re: [Tagging] residents only after hours

2018-08-21 Thread Greg Troxel

Jmapb  writes:

> access=yes
> access:conditional=destination @ (Oct-Apr: 20:00-07:00; May-Sep:
> 22:30-07:00)

(ignoring foot/bicycle as that's not the point)

If it's private, then access=yes is arguably not right, as permission is
granted to the public, vs the public having a right of access.

So I would use

access=permissive

instead of yes.  But this is a far larger issue than this one place; it
arguably applies to all paths on private land (that aren't a public
right-of-way of course) where it's basically ok for the public to go.

See 'yes' and 'permissive':

https://wiki.openstreetmap.org/wiki/Key:access


However, it seems the definition of permissive has drifted from what I
remember.  It used to be "no real permission is granted, but the owner
has declined to object".  Now, it seems to have a notion that permission
has actually been granted somehow.

I'm curious about this, and particularly from the English perspective,
where I've seen signed "permissive paths".  As opposed to the US, where
there are unmarked paths in the woods on private property, and for some
of those, locals know that it's basically ok to walk on them.


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


Re: [Tagging] highway=service // public road?

2018-05-26 Thread Greg Troxel

Martin Koppenhoefer  writes:

> sent from a phone
>
>> On 26. May 2018, at 10:41, Martin Koppenhoefer  
>> wrote:
>> 
>> I don’t mind, but it isn’t necessary for tag consistency (only if you want 
>> service to be private)
>
>
> the highway page sees service roads as part of the road network btw:
> https://wiki.openstreetmap.org/wiki/Key:highway
> no mention it should be used for private roads only.
>
> the service page reads: 
> v · d · e highway = service

My point about "real road" vs "paved place you can drive that isn't a
real road" is not really about access=yes/private, which is a separate
issue.  But, my point may be more local than I think it is.

And to answer "how do you tell"?  Well, you have to look at a lot of
things, sometimes including town property data, and various clues, and
make your best guess, and fix it later if you realize you are wrong.  A
big clue is a street sign put up by the same authority that puts up
regular road signs.

I certainly do not change keys at property boundaries for driveways off
public roads.  I use highway=service service=driveway for the entire
length of the way, even the end part that is within the government-owned
road parcel.


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


Re: [Tagging] highway=service // public road?

2018-05-25 Thread Greg Troxel

Martin Koppenhoefer  writes:

>> and track (for - due to history - public accessible rural driveways) is 
>> simply driven by reality.
>
> track is about agricultural and forestry usage, I did not know it required 
> public accessibility, does it?

In my usage (and US norms), tracks in agricultural/forestry usage, and
similar do not imply public accessibility.

I think the root of the problem, besides overloading too many concepts
into tags, is that service has two subtypes:

  things that are not public/legal roads, like driveways (and some alleys)

  public alleys, which are legal rights of way, usually with a sign
  "Public Alley 4309", but are too small to seem like a regular road.
  But legally they are like a regular road.

The fix is to add highway=alley, for things that are too small but
nevertheless fit the legal definition of a road, and then have service
be for "place you can drive that is not a legal road".

An alternative is to document that highway=service service=alley is a
legal road, and special among service.


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


Re: [Tagging] highway=service // public road?

2018-05-23 Thread Greg Troxel
Florian Lohoff  writes:

> I now see increasing usage of service roads as a category below
> unclassified. People tagging "smaller roads" in the countryside
> as a service roads. 

I think this is basically wrong tagging.

> I find this a little disturbing and now got into an argument whereas
> my position is the above - broken down into my more strict language:
>
> - If the public has a right of way
> - The road is build/run by public authorities
> - Its not something obvious like a parking space
> - It cant be service
>
> It might not fit 100% everywhere, but no rule without its exception.

Broadly agreed with your concerns.

A very important characteristic of a place you can drive is

  - it is legally a road, where more or less anyone has a right to
drive (and this can be public ownership or private).  Typically this
means that the ground on which it is built is carved out as a
separate lot for ownership (or government owned).  This can be
government, or it can be a road in a subdivision which is in the US
marked "private way" meaning that it is legally a road but privately
owned.  You can still get a speeding ticket on it, because the road
use rules apply to private ways, but do not apply to what you do in
your farm field.

Whether they apply in a shopping center is an interesting question.
I'd say: yes, you will be cited, and probably that does not hold
up.  But in some places (north carolina), the property owner can put
up signs that the traffic laws apply anyway - I saw these at the
biltmore estate.   Basically "this is private but the unwashed
public is here and we want the police to be able to bust them" :-)

  - not legally a road, in that there is no right of access, traffic
laws do not necessarily apply, and there is no separate parcel for
it

This is basically
"highway=primary/secondary/tertiary/unclassified/residential" vs
"highway=service/track".

It would be goo to have this be 


> The Argument of the usage is:
> - It only serves as access to a single house/company/farm.

Mostly agreed, but that's not quite right.  It's "a legal road" vs "a
place you can drive on someone's property".  If the pavement (assume
paved, but that's not the point) is on land owned and maintained by the
government, even if it only goes to one house, it's a road, not a
driveway.

> IMHO It should be driveway (Where there is no right of way and no name)
> when its not in public ownership, or unclassified with all the
> bells and whistles like a name, maxspeed etc.

I don't quite follow - but agreed that if no right of way it's service/driveway.

> To find those roads in my QA tools i dump/highlight roads which
> are highway=service and carry a name. The argument behind this is that
> at least in Germany only official public roads get names in a process
> called "Widmung" 1) - So if it carries a name, either the name has
> been copied (E.g. people copying the residentials name to all driveways)
> or somebody has "downgraded" a public road to a service.

That's a clue, but having a name on a service road is not proof of it
not being service.   My town has an airport access road which sort of
has a name, but is on a private lot and really a service/driveway.

> So i am asking where my misconception is:>

> - Is service a street category below unclassified/residential?

no, it's special - not a legal road, and typically should not be used
for through routing.

> - Does a service road typically have a right of way for the public?

typically not, maybe almost never.

> - Is service usage "just because there is only one house/company/farm"
>   valid? 

typically yes, but it's not exactly the right test.  I've seen a
residential legal road with more or less one house, but a separate land
area for the road, just like roads with more than one house.


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


Re: [Tagging] Is it possible to have highway=unclassified with ref tag?

2018-05-07 Thread Greg Troxel
Dave Swarthout  writes:

> But when a highway has an officially assigned ref doesn't that define it as
> "classified"? I don't have a large stake in this discussion but it would

You would think.  But no.

In the UK, there is a notion of A/B/C roads, and then unclassified.  I
gather this means they are part of the network but not declared one of
A/B/C.

I was in Scotland (in the highlands just off Skye) in 2016, and saw a
road that was U, and signed as U (a real number, but I don't
remember it).  It was even more minor than the nearby C road.

> seem to me that any road so ranked by the authorities should not be tagged
> as unclassified.

If you think of it as A/B/C/D where A is the most important
(non-Interstate) roads and D the least, where D roads are just barely
worthy of being numbered, but that we call D as U instead because that's
what they do in the UK, I think you are not that far off.

Around me, unclassified is typically used for roads that are somewhat
more important than others, but not to the level of being numbered.

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


  1   2   3   4   >