date:20221012




sent from a phone

> On 11 Oct 2022, at 15:37, martianfreeloader  
> wrote:
> 
> Do you have a suggestion how to fix this?


it is not broken, unless your proposal gets approved 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic

sent from a phone

> On 11 Oct 2022, at 17:32, martianfreeloader  
> wrote:
> 
> Nobody commented during RFC and then everybody voted against; which is not 
> nice. I was one of them.

particularly because the no vote didn’t offer any meaningful contribution, the 
only reason given was a formality (because the “historic” key is not formally 
approved). 

> 
> I'm happy to hand over the historic proposal to maintained by someone else! 
> Anyone interested?

we do not need the historic key to be “approved”, it is already there, any 
definition we put in the wiki should reflect how the tags are actually used. 
Approving a definition that would make current tagging an “error” if it is 
completely introduced with many established and undisputed values, is just 
wasting everybody’s time, even more if the result would lead to “deprecation” 
of these established tags https://taginfo.openstreetmap.org/keys/historic#values

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

Re: [Tagging] Feature Proposal - RFC - Historic

sent from a phone

> On 12 Oct 2022, at 04:39, Graeme Fitzpatrick  wrote:
> 
> I would love to be able to move the vast majority of military= to 
> historic=military, as they are no longer military installations.
> 
> Yes, they certainly were, but they aren't any more.

are all military tags about current use by the military, or maybe they can also 
be used for military installations that aren’t used currently? Is a military 
base that is now abandoned still a military base? Or a bunker?What are the 
criteria? Surely there is some cutoff, we do not tag medieval castles as 
military, although they once were. Tagging some stuff as historic, even 
archaeological site in some case, makes sense (and is what we already do).

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

Re: [Tagging] Lyft and nameless sectioning in OSM

sent from a phone

> On 12 Oct 2022, at 07:11, Evan Carroll  wrote:
> 
> Let's say you're in an industrial zone: do you tag as such 
> (landuse=industrial) if half of the buildings have been converted to lofts?

I would see landuse=residential on the parcels where people live and 
landuse=industrial on parcels with industrial landuse. 

> It would go both ways. But only if it's automated can we get an indicator of 
> the agreement between the macro-level landuse and the buildings contained.

if there are industrial and residential buildings, they should not go into the 
same landuse. 

Cheers Martin 

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

Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-12 Thread Peter Neale via Tagging

>That could also be an option, but would that stop them rendering as current 
>military features?
One could argue that, if they are no longer military featuers, they should not 
be tagged as mililtary features.  "historic=battlefield" does this and we are 
probably not mapping any current / modern / non-historic battlefields, so ther 
is not any real conflict.  My problem with the whole key of  "historic=" is 
that some other objects, such as memorials, houses, dairies might be 
historic, but might not.  So I feel that we should tag the identity and main 
characteristics of an object and then use "historic=yes" to indicate that it is 
historic, but not current (If that is the case).
In the case of your historic military features, I would assume (I do not run a 
renderer) that the renderer could (fairly easily ?) have one symbol for a 
current object and another for an historic one (perhaps the same symbol, but in 
a different colour?)
My point is that beíng historic is an attribute of an object that IS something 
else (battlefield, memorial, house, dairy...).  "historic" is an adjective, not 
a noun. 
Regards,Peter(PeterPan99)

On Wednesday, 12 October 2022 at 03:36:32 BST, Graeme Fitzpatrick 
 wrote:  

On Tue, 11 Oct 2022 at 23:28, Mateusz Konieczny via Tagging 
 wrote:

Maybe there would be value in deapproving historic=battlefield

I would love to be able to move the vast majority of military= to 
historic=military, as they are no longer military installations.
Yes, they certainly were, but they aren't any more.

On Wed, 12 Oct 2022 at 00:07, Peter Neale via Tagging 
 wrote:

Many ruins and memorials are "of historic interest" it is true, but that could 
be tagged as a property ("historic=yes") of the object "man_made=" 
.

That could also be an option, but would that stop them rendering as current 
military features?
Thanks
Graeme
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

>
> if there are industrial and residential buildings, they should not go into
> the same landuse.
>

This would make more sense then the current state of affairs as at least
then I could use the data for _something_ other than highlighting a map,
but alas that's not the case,

> The landuse tag is mostly used for larger areas and not at parcel
granularity; as described above, a single shop in a residential area might
not always warrant an extra "commercial" landuse.

So you can see a residential isn't always _exclusively_ residential. And
likewise for industrial, attention to "most"

> This tag should only be used for land which is primarily used for
industrial purposes. It should not be used sweepingly for larger areas
containing industrial infrastructure at different places but most of the
area as a whole not being used industrially (rather be more detailed and
add industrial landuse to these parts only).

Just to be clear, I only bring this up because an automated method can be
utilized to do all this work and it can tell you exactly how much "most"
is. Or if you want to only allow it to create an area with 100% saturation
of the same building type, that can also be done. But expecting humans to
do this is rather silly. I still don't get the point though. At the point
that we acknowledge that, 100% of landuse for "developed land" can be
inferred/calculated from the aggregate buildings/ways it covers, the next
question seems to be,

* Should OSM do this?
* Is this a function of a "map", or is it to ease app creation for
consumers?

The only use case we have know that was mentioned was to emphasize
non-residential and de-emphacize residential. If so, it's only being used
to style the map as it exists. If so, then if we can better calculate this
with a nice PostGIS query (which I know we can do), the question is whether
or not we should do it?

-- 
In the event this email pertains to Real Estate, Texas law

requires all license holders provide to prospective clients the following
forms: Information About Brokerage Services
, Consumer Protection
Notice
.
My TREC
license number is 610570

and my sponsoring broker is NB Elite Realty LLC.

--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011 <+1-281-901-0011>

On Wed, Oct 12, 2022 at 2:51 AM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > On 12 Oct 2022, at 07:11, Evan Carroll  wrote:
> >
> > Let's say you're in an industrial zone: do you tag as such
> (landuse=industrial) if half of the buildings have been converted to lofts?
>
>
> I would see landuse=residential on the parcels where people live and
> landuse=industrial on parcels with industrial landuse.
>
>
> > It would go both ways. But only if it's automated can we get an
> indicator of the agreement between the macro-level landuse and the
> buildings contained.
>
>
> if there are industrial and residential buildings, they should not go into
> the same landuse.
>
> Cheers Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

-- 
In the event this email pertains to Real Estate, Texas law

requires all license holders provide to prospective clients the following
forms: Information About Brokerage Services
, Consumer Protection
Notice
.
My TREC
license number is 610570

and my sponsoring broker is NB Elite Realty LLC.

--
Evan Carroll - m...@evancarroll.com
System Lord of the Internets
web: http://www.evancarroll.com
ph: 281.901.0011 <+1-281-901-0011>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

*FOLLOW UP HYPOTHETICAL: *
I've been thinking about this a lot. I'm arguing here that,

* Landuse for developed land can be better automatically generated when
there isn't a named polygon.
* If automatically generated, we can achieve perfect accuracy or quantify
the margins of errors (the degree to which a buildings adhere to the
landuse that contains them).

I think not everyone grasps this. Let me put forward an alternative to
illustrate this.

Let us create a new landuse-esque tag called "density"
Let density come in three flavors, "density=high", "density=low",
"density=medium"

* Low Density is where you have mostly single story buildings
* Medium Density is where your buildings average to five or fewer levels.
* High Density is where most of your buildings have more than 5 levels

What would be ideal: (a) to have users create these polygons in OSM, or (b)
to automatically calculate density as a function of the buildings in the
polygon by referring to building:levels? This is a direct analogy to how I
see unnamed landuse for developed land. There is an application for
landuse, and for density. However, I don't understand why these are better
left to users rather than automatically generated. If we want to support
landuse for developed land moving forward, I highly suggest automatically
inferring it from the contents of polygons created in the method outlined
in my reply to Joseph Eisenberg. =)



On Tue, Oct 11, 2022 at 1:34 PM Evan Carroll  wrote:

> Lyft has been adding thousands of Polygons around Houston for Retail and
> Residential and Industrial Areas. I'm just wondering what the motivation
> here is for Lyft's behavior, especially in Texas. It seems like a lot of
> bloat on OSM. IMHO, these polygons don't add any value: they're not
> describing  what things are, and they're frequently incorrect. Houston
> doesn't have zoning: stating what something is today as if it was a zone is
> problematic anywhere (as at best it's only ever administrative where there
> is zoning) but even more so in Houston where with enough money you can buy
> the property and put an industrial plant there (assuming the property has
> no bylaws). Sure that's just routine maintenance but what is the value with
> that maintenance?
>
> If we know what every individual building is (which is the ideal), what
> information is conveyed by telling me that 80% or some unquantified
> inexplicit percentage of buildings in a grouping are of type Industrial?
>
> And a lot of these polygons cover _only_ one property. Which it seems
> isn't permitted by the wiki, but that also doesn't add any utility over the
> building itself.
>
> Some examples of these nameless sections are,
>
> * w1101484647 by A_Prokopova_lyft
>
> Across the street from that one is three identical polygons by Emey_lyft
> in the same place
>
> * w1101205150
> * w1101204670
> * w1101392713
>
> In case you think that's unique, right below it Emey_lyft did it again
> with three identical polygons.
>
> * w1101205149
> * w1101204669
> * w1101392712
>
> I'm assuming the triplicating is an innocent mistake, and not an attempt
> to inflate a quota. But, I just want to understand what is the use case for
> highlighting *everything on the border of every major highway and primary
> road* with "Retail Area" even without triplicating.
>
> Moreover, with polygons like w1096234140, how is that useful when you lump
> in one motel and three buildings which OSM has *no information about* as a
> "Commercial Area"? Likewise, how is w1096234140 a "Retail Area" it covers
> 12 buildings and we only know one is a Post Office, the other is a Dunken
> Donuts, and "Houston Skate and Dance" exists somewhere inside it?
>
> None of this is relevant to any areas WITH names: I'm all for these. IE,
> "Braeswood Squre", or "Meyer Park". Those "Areas" have a name which is
> useful to the community and the sign is visible for the retail campus, but
> seems most of Lyft's contributions are nameless (all of the ones I've seen)
> .They seem to be outsourcing what could otherwise be done more correctly
> with better data, automatically: if we know what each business is inside
> the polygon, we can create effective "Areas" using spatial clustering.
>
> Should we better define when these areas should be used and not used? Can
> Lyft tell us what the business case is for funding these contributions to
> OSM? How are they used to create value to our users?
>
> (This is not a call out, and I want no part of any corrective action on
> the two people mentioned. I'm only looking to provide concrete examples so
> we can better draft policy.)
>
> --
> In the event this email pertains to Real Estate, Texas law
> 
> requires all license holders provide to prospective clients the following
> forms: Information About Brokerage Services
>

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-12 Thread Enno Hermann

You seem to imply this is trivial, so feel free to build a prototype of
this to see how accurate it is (note that you will need to judge the
automated method against manual mapping, not the other way around). But
most areas are probably not mapped in enough detail yet for this to work.
For example, in the Houston area you shared most buildings are only tagged
with building=yes or not even mapped at all, how will you be able to
automatically infer the landuse from that? But someone can manually
identify and map a residential area even if they don't want to map all the
houses there yet (https://www.openstreetmap.org/relation/7916453).

Even if you have an area mapped in high detail, I don't expect this to be
that easy. In this case landuse will also generally have been accurately
mapped a long time ago.

-Enno (eginhard)

On Tue, Oct 11, 2022 at 10:55 PM Evan Carroll  wrote:

> Thanks  Joseph Eisenberg! That's exactly what I'm looking for. Good
> answer. So basically the primary use case of an **unnamed** residential,
> commercial, industrial, and retail "Zones" is not to convey (additional)
> information but to serve as a good-enough styling solution about what the
> zone conveys? As I suspected, it is solving a spatial clustering problem
> manually to achieve a good-enough different visual style. I guess you can
> see here in the landcover.
>
>
> https://github.com/gravitystorm/openstreetmap-carto/blob/cae2309efd4ee0338fcdf9f201e92f20b338426c/style/landcover.mss#L16
>
> The next question is can this be defined such that this can be automated?
> It would seem to me like if we,
>
> 1. Take a bounding box.
> 2. From that, subtract out the landuse polygons for named zones, LEAVING
> ONLY "unnamed zones, and land not in a zone."
> 3. From that, subtract out the landuse polygons for zones NOT of type
> "common landuse key values - developed land", per the wiki
> https://wiki.openstreetmap.org/wiki/Key:landuse LEAVING ONLY "unnamed
> zones of developed land, and land not in a zone."
> 4. Subtract out by key:highway lines LEAVING ONLY "unnamed zones of
> developed land and land not in a zone that does NOT intersect a highway."
> 5. Extract "unnamed zones of developed land and land not in a zone that
> does NOT intersect a highway" into a zone set.
> 6. Infer from the contents of the polygon what type of developed land the
> zone is.
>
> This would allow us to be precise and objective and determine what kind of
> "developed land" an unnamed zone was, as well as to provide a gauge of the
> accuracy of the zone.
>
> If this was done, do you think this would satisfy all use cases of unnamed
> landuse zones for developed land like commercial, retail,
> residential, educational?
>
> (I said in the above "unnamed zone" for simplicity, and unnamed zone can
> still have an operator, and in every case when I said unnamed zone, I meant
> a zone without a name or an operator).
>
> --
> In the event this email pertains to Real Estate, Texas law
> 
> requires all license holders provide to prospective clients the following
> forms: Information About Brokerage Services
> , Consumer Protection
> Notice
> .
> My TREC license number is 610570
> 
> and my sponsoring broker is NB Elite Realty LLC.
>
> --
> Evan Carroll - m...@evancarroll.com
> System Lord of the Internets
> web: http://www.evancarroll.com
> ph: 281.901.0011 <+1-281-901-0011>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] RFC - More sensible values for fountain=*

2022-10-12 Thread Warin



On 11/10/22 23:35, Martin Koppenhoefer wrote:


sent from a phone


On 11 Oct 2022, at 13:30, Davidoskky via Tagging  
wrote:

How would you tag this fountain I photographed the other day?

The water is not potable, the stream of water cannot be interrupted and 
definitely is not a decorative fountain.

https://commons.wikimedia.org/wiki/File:Water_fountain_without_tap_near_Santiago_de_Compostela.jpg


it is a historic fountain


Historic? I think 'old' is the only thing that can be determined from 
the photo?




that IMHO clearly is decorative, that stuff in the background doesn’t seem to 
be there by incident. Maybe it is also a historic watering place (seems small 
for this)? Not knowing the context I cannot tell you for sure what it is. 
amenity=fountain doesn’t seem off. Many “decorative” fountains also had utility.



I don't think the stream of water is the most useful feature .. it is 
the water in the trough for animals to drink from .. horses, donkeys .. 
etc.. I am assuming the lower structure contains some level of water 
simply by its shape.



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

Re: [Tagging] RFC - More sensible values for fountain=*

2022-10-12 Thread Warin



On 11/10/22 22:38, Marc_marc wrote:

Le 11.10.22 à 11:23, Davidoskky via Tagging a écrit :

On 11/10/22 10:22, Marc_marc wrote:
you do not need to have the use of a key "approved for fountains" 
that would respect the meaning of the approved tag.
however it would be useful to discuss/approve the most relevant 
values to describe the known cases 
We would need to approve that certain keys are moved from fountain=* 
to model=* 


on this point: yes
and I think this should be a fairly simple proposal and likely to be 
accepted since it avoids multiple meanings of fountain=* (function <> 
style <> ...)






fountain=* is not specific enough without further explanation.

Why not fountain:style=* and fountain:function=*? Could save some 
misunderstandings and ease migration?




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

Re: [Tagging] camp sites in Haiti

2022-10-12 Thread Warin



On 12/10/22 02:05, Joseph Eisenberg wrote:
> Would it be possible to re-tag those refugee camps in an automated 
edit? … I'm not even sure if they all still exist 12 years later.


It would not be possible, because we do not know if they still exist.



So you leave them with an incorrect tag?

I'd re-tag them.. but only after looking at imagery to see if they are 
refugee sites.


And I'd try to find the most upto date imagery to confirm there 
existence ..





However a local mapper or someone who has visited the area could 
re-tag them, after confirming that they still exist and are in fact 
refugee sites



A local mapper or visitor can also confirm or delete them after they 
have been retagged by a remote mapper.


And after 212 years of inactivity the change may prompt a local to think 
about these sites.




-Joseph Eisenberg

On Tue, Oct 11, 2022 at 4:20 AM Anne-Karoline Distel 
 wrote:


Hello,

I noticed that many of the refugee camps in Haiti are tagged as
tourism=camp_site which made me uneasy. Turns out there is the tag
amenity=refugee_site. Would it be possible to re-tag those refugee
camps
in an automated edit? There are about 60 or 70 mapped. I'm not
even sure
if they all still exist 12 years later.

Anne


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


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

Re: [Tagging] Re: Lyft and nameless sectioning in OSM

2022-10-12 Thread Anne- Karoline Distel

 There is such a thing as mixed use with our local authorities, residential+commercial. I wouldn't think residential and industrial mixes because of noise and pollution, at least in theory.Anne--Sent from my Android phone with WEB.DE Mail. Please excuse my brevity.On 12/10/2022, 08:53 Martin Koppenhoefer  wrote:

   sent from a phone

   > On 12 Oct 2022, at 07:11, Evan Carroll  wrote:
   >
   > Let's say you're in an industrial zone: do you tag as such (landuse=industrial) if half of the buildings have been converted to lofts?

   I would see landuse=residential on the parcels where people live and landuse=industrial on parcels with industrial landuse.

   > It would go both ways. But only if it's automated can we get an indicator of the agreement between the macro-level landuse and the buildings contained.

   if there are industrial and residential buildings, they should not go into the same landuse.

   Cheers Martin

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

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

Re: [Tagging] camp sites in Haiti

2022-10-12 Thread Illia Marchenko

I think that amenity=refugee_site & fixme=Review may be solution, it isn't
the ideal, but are better then leave "as is".

ср, 12 окт. 2022 г., 11:54 Warin <61sundow...@gmail.com>:

>
> On 12/10/22 02:05, Joseph Eisenberg wrote:
>
> > Would it be possible to re-tag those refugee camps in an automated
> edit? … I'm not even sure if they all still exist 12 years later.
>
> It would not be possible, because we do not know if they still exist.
>
>
> So you leave them with an incorrect tag?
>
> I'd re-tag them.. but only after looking at imagery to see if they are
> refugee sites.
>
> And I'd try to find the most upto date imagery to confirm there existence
> ..
>
>
>
>
> However a local mapper or someone who has visited the area could re-tag
> them, after confirming that they still exist and are in fact refugee sites
>
>
> A local mapper or visitor can also confirm or delete them after they have
> been retagged by a remote mapper.
>
> And after 212 years of inactivity the change may prompt a local to think
> about these sites.
>
>
> -Joseph Eisenberg
>
> On Tue, Oct 11, 2022 at 4:20 AM Anne-Karoline Distel 
> wrote:
>
>> Hello,
>>
>> I noticed that many of the refugee camps in Haiti are tagged as
>> tourism=camp_site which made me uneasy. Turns out there is the tag
>> amenity=refugee_site. Would it be possible to re-tag those refugee camps
>> in an automated edit? There are about 60 or 70 mapped. I'm not even sure
>> if they all still exist 12 years later.
>>
>> Anne
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-12 Thread martianfreeloader




On 12/10/2022 09:34, Martin Koppenhoefer wrote:

we do not need the historic key to be “approved”, it is already there, 
any definition we put in the wiki should reflect how the tags are 
actually used. Approving a definition that would make current tagging an 
“error” if it is completely introduced with many established and 
undisputed values, is just wasting everybody’s time, even more if the 
result would lead to “deprecation” of these established tags 
https://taginfo.openstreetmap.org/keys/historic#values 



So then what's the point of approving tags anyways?




Cheers Martin

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


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

Re: [Tagging] camp sites in Haiti

2022-10-12 Thread Anne-Karoline Distel


I left 3 fixmes, even tried one in French, just in case.

Anne

On 12/10/2022 10:51, Illia Marchenko wrote:

I think that amenity=refugee_site & fixme=Review may be solution, it
isn't the ideal, but are better then leave "as is".

ср, 12 окт. 2022 г., 11:54 Warin <61sundow...@gmail.com>:


On 12/10/22 02:05, Joseph Eisenberg wrote:

> Would it be possible to re-tag those refugee camps in an
automated edit? … I'm not even sure if they all still exist 12
years later.

It would not be possible, because we do not know if they still
exist.



So you leave them with an incorrect tag?

I'd re-tag them.. but only after looking at imagery to see if they
are refugee sites.

And I'd try to find the most upto date imagery to confirm there
existence ..




However a local mapper or someone who has visited the area could
re-tag them, after confirming that they still exist and are in
fact refugee sites



A local mapper or visitor can also confirm or delete them after
they have been retagged by a remote mapper.

And after 212 years of inactivity the change may prompt a local to
think about these sites.



-Joseph Eisenberg

On Tue, Oct 11, 2022 at 4:20 AM Anne-Karoline Distel
 wrote:

Hello,

I noticed that many of the refugee camps in Haiti are tagged as
tourism=camp_site which made me uneasy. Turns out there is
the tag
amenity=refugee_site. Would it be possible to re-tag those
refugee camps
in an automated edit? There are about 60 or 70 mapped. I'm
not even sure
if they all still exist 12 years later.

Anne


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


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

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


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

Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-12 Thread Sebastian Martin Dicke

In Germany I found at least one battlefield from the mid of the last 
century which is tagged as historic=battlefield. Both in English and in 
German the mid of the last century is included in that what is modern. 
In Germany the modern period is often considered as a time span from the 
beginning of the twentieth century either until today or until to a 
subsequent era, which is called postmodern. The question if the modern 
age already ended or not is not important. But if we consider the modern 
age as the century (1900 – 1999) and we would agree not to tag any 
modern battlefield as historic=battlefield, which other tag should we 
use for them?


The definition of the historic=battlefield tag raises an interesting 
question concerning the key discussed in that thread: What means 
historic in the context of OSM? According to the wiki page the tag is 
properly for: „The site of a battle or military skirmish in the past. 
This could be on land or at sea.“ Okay, we could consider battles and 
skirmishes as ended if there is no soldiers or working military robots 
anymore. If they ended they are in the past. That is an easy point, I 
hope. But to be historic means to pertain history as far as I understand 
it and history is, I would define it, and many other would agree I 
assume, not simply everything in the past. History is some kind of 
narration, may created by a community through it tales, may a 
reconstruction (attempt) of forgone events by historians.


Should we define are limit of what should be tagged as historic? Do we 
need a barrier (ten years out of use, for example) or is the key 
properly for everything what is now out of use? If there is an aircraft 
standing on an airstrip which has been decommissioned yesterday (or 
thirty minutes ago), is it considered properly to tag them as 
historic=aircraft?



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

Re: [Tagging] camp sites in Haiti

I think that retagging confirmed to be existing refugee sites and
deleting clearly invalid data would be better than turning it into more 
camouflaged
suspect data.

Oct 12, 2022, 11:59 by annekadis...@web.de:

>
> I left 3 fixmes, even tried one in French, just in case.
>
>
> Anne
>
> On 12/10/2022 10:51, Illia Marchenko  wrote:
>
>> I think that amenity=refugee_site & fixme=Review may be  solution, 
>> it isn't the ideal, but are better then leave "as  is". 
>>  
>>  
>> ср, 12 окт. 2022 г., 11:54  Warin <>> 61sundow...@gmail.com>> >:
>>
>>>
>>>
>>>
>>> On 12/10/22 02:05, Joseph Eisenberg wrote:
>>>
 >  Would it be possible to re-tag those refugee camps  
 > i n an  automated edit? … 
 > I'm not even sure  if  they all still exist 12 
 > years later.

 It  would not be possible, because we do not know if   
they still exist. 

>>>
>>>
>>>
>>>
>>> So you leave them with an incorrect tag? 
>>>
>>>
>>> I'd re-tag them.. but only after looking at imagery  to see 
>>> if they are refugee sites. 
>>>
>>>
>>> And I'd try to find the most upto date imagery to  confirm 
>>> there existence .. 
>>>
>>>
>>>  
>>>
>>>

 However  a local mapper or someone who has visited the 
 area  could re-tag them, after confirming that they
   still exist and are in fact refugee sites

>>>
>>>
>>>
>>>
>>> A local mapper or visitor can also confirm or delete  them 
>>> after they have been retagged by a remote mapper. 
>>>
>>>
>>> And after 212 years of inactivity the change may  prompt a 
>>> local to think about these sites. 
>>>
>>>

 -Joseph  Eisenberg 

 On Tue, Oct 11,2022 at 4:20 AM Anne-Karoline 
 Distel < annekadis...@web.de >wrote:

> Hello,
>  
>  I noticed that many of the refugee camps inHaiti 
> are tagged as
>  tourism=camp_site which made me uneasy. Turnsout 
> there is the tag
>  amenity=refugee_site. Would it be possible to
> re-tag those refugee camps
>  in an automated edit? There are about 60 or 70
> mapped. I'm not even sure
>  if they all still exist 12 years later.
>  
>  Anne
>  
>  
>  ___
>  Tagging mailing list
>  > Tagging@openstreetmap.org
>  > https://lists.openstreetmap.org/listinfo/tagging
>

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

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

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

Re: [Tagging] Feature Proposal - RFC - Historic




Oct 12, 2022, 11:59 by martianfreeloa...@posteo.net:

>
>
> On 12/10/2022 09:34, Martin Koppenhoefer wrote:
>
>> we do not need the historic key to be “approved”, it is already there, any 
>> definition we put in the wiki should reflect how the tags are actually used. 
>> Approving a definition that would make current tagging an “error” if it is 
>> completely introduced with many established and undisputed values, is just 
>> wasting everybody’s time, even more if the result would lead to 
>> “deprecation” of these established tags 
>> https://taginfo.openstreetmap.org/keys/historic#values 
>> 
>>
>
> So then what's the point of approving tags anyways?
>
main point would be review of tagging that can be still redefined as
only few objects were mapped
this benefit is lost for tags already widely used which cannot be redefined

another benefit is confirming that some specific tagging is liked by
community - but for very popular tags this is pointless

whether deprecations are beneficial and how helpful are proposals here
is an interesting topic, but it anyway does not apply here
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] camp sites in Haiti


Le 12.10.22 à 11:51, Illia Marchenko a écrit :

fixme=Review


I dislike the idea to add fixme for stuff that doesnn't
require to be fixed but are old (and old items should be
rechecked from time to time)!

if someone want to express the survey date, let's use survey:date
if someone want to express imagery_used:date or source:date, do it also 
(if possible onn changeset tag)

if someone want to warn that a changeset is a "tag fix only",
some mapper use the changeset tag type=fix (i dislike the type=*
for that usage, but previous thread about it doesn't find
a better_/consensual tag for it)

if a tool want to warn user for objets not seen recently
or whose source is old, fine.

but let's everyone able to see the real fixme (sb detected
an error but couldn't fix it) separately from the "resurvey
or found a more recent source to check if it's still current".



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

Re: [Tagging] Feature Proposal - RFC - Historic


Le 12.10.22 à 09:55, Peter Neale via Tagging a écrit :

historic is an attribute of an object that IS something else


what's "something else" is a historic=archaeological_site ?
and a historic=ruins ?



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

Re: [Tagging] Feature Proposal - RFC - Historic


On 12/10/2022 09:34, Martin Koppenhoefer wrote:


we do not need the historic key to be “approved”,


you don't need please do not speak for others,
you are not a spokesperson :) :)


Approving a definition that would make current tagging an “error”


approving that "historic=* is about "with historical significance"
doesn't change anything about already existing historic=value
without historical significance. existing tags always remain
unless someone has the courage to try to make progress on the issue
and depreciated a specific tag is a completely different matter
from approving a key.

it will simply help the creation of the next historic=value
to be done with the right key instead of believing that it is
positive to have a mess in the historic key



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

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-12 Thread Greg Troxel

Evan Carroll  writes:

> *FOLLOW UP HYPOTHETICAL: *
> I've been thinking about this a lot. I'm arguing here that,
>
> * Landuse for developed land can be better automatically generated when
> there isn't a named polygon.
> * If automatically generated, we can achieve perfect accuracy or quantify
> the margins of errors (the degree to which a buildings adhere to the
> landuse that contains them).

I do not understand 'automatically generated'.  Landuse is about the
primary human use of the land, and that's something that has to be
obeserved, or come from another dataset (as an import) where it was
observed.

> Let us create a new landuse-esque tag called "density"
> Let density come in three flavors, "density=high", "density=low",
> "density=medium"
>
> * Low Density is where you have mostly single story buildings
> * Medium Density is where your buildings average to five or fewer levels.
> * High Density is where most of your buildings have more than 5 levels

That's not landuse in the traditional geography sense; you can have
hi-rise residential and hi-rise office and one is residential and the
other commercial.

And, if the buildings are on the map and labeled with levels, then
there is no need to tag what you are proposing.

> What would be ideal: (a) to have users create these polygons in OSM, or (b)
> to automatically calculate density as a function of the buildings in the
> polygon by referring to building:levels? This is a direct analogy to how I
> see unnamed landuse for developed land.

For density, it seem a, but for landuse it is perfectly reasonable for a
mapper to observe that an area is filled with shops and add a
landuse=retail polygon.  It may be that a building or so within that is
commercial not retail, but that's ok.

>  There is an application for
> landuse, and for density. However, I don't understand why these are better
> left to users rather than automatically generated. If we want to support
> landuse for developed land moving forward, I highly suggest automatically
> inferring it from the contents of polygons created in the method outlined
> in my reply to Joseph Eisenberg. =)

Part of the issue is that landuse should more or less follow property
lines, unless there is some reason why not.  a several-acre parcel with
a house and some trees is still landuse=residential on all of it, absent
farming or some side industrial business.

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

Re: [Tagging] Feature Proposal - RFC - Historic


Le 12.10.22 à 13:15, Sebastian Martin Dicke a écrit :
If there is an aircraft standing on an airstrip which has been 
decommissioned yesterday (or thirty minutes ago), is it considered 
properly to tag them as historic=aircraft?


I think it depends on the history of the object :

if the last Concorde [1] had been treated in this way, I think
it would have been possible to consider it as historical from the
first minute of its immobilisation, a page of history is turned
after years of supersonic commercial flight, it is history.

On the other hand, a single aircraft with no history other than "we 
don't need it anymore" is not historic, neither now nor in 10 years,

it is at best a decoration

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



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

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-12 Thread Dave F via Tagging


On 11/10/2022 19:34, Evan Carroll wrote:


Some examples of these nameless sections are,

* w1101484647 by A_Prokopova_lyft


Not looked at all your examples, but i can't see a problem with your first.
It covers a large area of no just a building but car parking etc, and is 
surround by landuse of another type.


These landuse areas are useful for rendering.
Rendering individual items when zoomed out clutters the map & slows down 
rendering speeds (such as on GPSs), however it's still useful to 
indicated that it is an urbanised area of some description.




None of this is relevant to any areas WITH names: I'm all for these. 
IE, "Braeswood Squre", or "Meyer Park".


Landuse areas such as residential, commercial, retail etc shouldn't have 
names as location names are rarely of one landuse type. Much better to 
add a separate node which can be specifically placed near the centre 
where it can be rendered accurately.


Suburb names include school, parks, shopping areas etc so shouldn't be 
placed on residential areas.


Cheers
DaveF

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

Re: [Tagging] Lyft and nameless sectioning in OSM


Le 11.10.22 à 20:48, Andy Townsend a écrit :

That was added in https://www.openstreetmap.org/changeset/127101982 , 


I am surprised that no one is concerned about the compatibility
between its proprietary source and osm



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

Re: [Tagging] Lyft and nameless sectioning in OSM


Le 12.10.22 à 07:04, Evan Carroll a écrit :
is it better to have a computer make an objective statement and tell how 
you accurately the landuse tag fits?


I read your algorithm a bit quickly but I don't see how a computer is 
going to be able to tell where the boundary is between residential and 
commercial landuse when there are only buildings in osm.


I did this at the beginning of the mapping in a poor area: survey to add 
the commercial area.

it was only afterwards that i added the occupants of the commercial area
even today i still use this zone from time to time to take a building 
that has no occupant in osm and go back to survey to add information, 
something i don't do systematically in the residential part since there, 
they are almost exclusively housing-

this is another use case of those that have been given



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

Re: [Tagging] Lyft and nameless sectioning in OSM

> I do not understand 'automatically generated'.  Landuse is about the
primary human use of the land, and that's something that has to be
obeserved, or come from another dataset (as an import) where it was
observed.

This is true if the landuse conveys _additional_ information, like a
name. But for unnamed landuse on developed land this is not true: the
dataset is OSM. If you an area with 100% detached residences inside,
it's a residential. Right? Always. No exceptions, it follows from the
detached residences inside. The same is true is commercial if it has
commercial buildings. Or Retail if it's shops. Computers can group
this just fine without further human observation. In fact, humans
can't really see "landuse" either. They infer it from whatever is on
the land. Some neighborhoods have signs with names, which is great
because you can add value with the name. But if you find yourself on a
cul de sac and can only see detached homes, you know the landuse is
residential.

> That's not landuse in the traditional geography sense; you can have
> hi-rise residential and hi-rise office and one is residential and the
> other commercial.

That's why it's a hypothetical, and not the actual thing I'm talking
about in the OT. The point is to show you another way to group
properties which can be entirely inferred.

> but for landuse it is perfectly reasonable for a
> mapper to observe that an area is filled with shops and add a
> landuse=retail polygon.  It may be that a building or so within that is
> commercial not retail, but that's ok.

Right, but they can have one building, two buildings or 49% of
buildings. You'll never know. Computers can also see the majority of
buildings are of a specific, they can also generate a label for the
group, and they can tell you to the degree the label is accurate! As
in: tag:landuse=residential; tag:computed_average=0.85.

> Part of the issue is that landuse should more or less follow property
> lines, unless there is some reason why not.  a several-acre parcel with
> a house and some trees is still landuse=residential on all of it, absent
> farming or some side industrial business.

Property lines isn't mentioned anywhere in the wiki. Land Use crosses
properties lines and groups buildings on different pieces of property.
If anything, ideally it's delineated by roads (which is explicitly
mentioned in the wiki). That's how the algorithm I provided works, it
looks for polygons that remain after you subtract out named landuse,
and roads.

--
Evan Carroll - m...@evancarroll.com

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

Re: [Tagging] Lyft and nameless sectioning in OSM

> There is such a thing as mixed use with our local authorities, 
> residential+commercial. I wouldn't think residential and industrial mixes 
> because of noise and pollution, at least in theory.

Landuse has nothing to do with local authorities or zoning. I've
argued it would have _more_ value if it did because then I would not
be able to compute better polygons for it. However, as-is unnamed
developed landuse is a function of the buildings inside.

For an example of mixed residential+industrial:
https://en.wikipedia.org/wiki/Loft#Industrial/hard_loft

--
Evan Carroll - m...@evancarroll.com

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

Re: [Tagging] Lyft and nameless sectioning in OSM


Le 12.10.22 à 17:39, Evan Carroll a écrit :

If you an area with 100% detached residences inside,
it's a residential. Right? Always. No exceptions, 


no :)
if you have x number of detached residences occupied by offices,
it is not a landuse=residential


it follows from the detached residences inside


if all plots have fences or hedges entered in osm, or if
the buildings touch each other, an algorithm allows you to build
the landuse=* of each building and merge the identical landuses
but sometimes you don't have enough info to find the value
of the landuse, so you don't have the info to create anything
other than a landuse=yes around each building 8or a place=plot)

but this is not reality... plot boundaries can be absent from osm...
or a large enough plot can have commercial activity on one side
and residential activity on the other -> 2 landuse=* in osm

take a location that is not too dense in information in osm
and draw what your algo could produce as landuse=*
I think this will shed some light on the number of times the information 
is not detailed enough in osm to do what you would have wanted.
or maybe come back with an interesting example that will motivate 
someone to do something with it (assisted contribhtion for landuse

or rendering or whatever)



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

Re: [Tagging] Lyft and nameless sectioning in OSM

>
> if you have x number of detached residences occupied by offices,
> it is not a landuse=residential
>

Then it's mistakenly tagged. You do not use `building=detached` for shops
and offices. Per the wiki,
https://wiki.openstreetmap.org/wiki/Tag:building%3Ddetached

> A detached house is a free-standing residential building usually housing
a single family. Known as a *single-family home* in the United States,
a *single-detached
dwelling* in Canada, a *separate house* in New Zealand and *Maison
individuelle* in France.

It includes the _function_ of the building.

> it follows from the detached residences inside
>
> if all plots have fences or hedges entered in osm, or if
> the buildings touch each other, an algorithm allows you to build
> the landuse=* of each building and merge the identical landuses
> but sometimes you don't have enough info to find the value
> of the landuse, so you don't have the info to create anything
> other than a landuse=yes around each building 8or a place=plot)
>

It's not about coverage: humans tagging landuse do not have to have any
specific quantity of info. They can infer from the landuse of an entire
suburb by a specific street. And the same is true about a strip mall. If I
I have one building with 25 offices inside and that's all that's in OSM,
it's commercial. If a building has 25 shops inside and that's all that's in
OSM it's retail. Seems pretty basic. Now let's assume you have 24 retail
shops in a building and the owner is living upstairs on the second floor:
that's a 24:1 ratio. A computer can store that calculation on the landuse.
Currently the mapper just says "good enough" and the consumer is left to
wonder how accurate the mapper was.


> but this is not reality... plot boundaries can be absent from osm...
> or a large enough plot can have commercial activity on one side
> and residential activity on the other -> 2 landuse=* in osm
>

I haven't seen a single plot in Houston. I have no idea why these matter.
Lift isn't mapping out plots before they map out unnamed landuse. I don't
see how these are factoring into the conversation. Humans can't typically
observe plots. Landuse is being mapped on the basis of the buildings
contained.


> --
Evan Carroll - m...@evancarroll.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic


Vào lúc 07:16 2022-10-12, Marc_marc đã viết:

approving that "historic=* is about "with historical significance"
doesn't change anything about already existing historic=value
without historical significance. existing tags always remain
unless someone has the courage to try to make progress on the issue
and depreciated a specific tag is a completely different matter
from approving a key.

it will simply help the creation of the next historic=value
to be done with the right key instead of believing that it is
positive to have a mess in the historic key


Keys that go through the feature proposal process are usually either 
freeform keys, accepting arbitrary values like human-readable text or 
numbers, or allow a fixed, coherent set of values.


In the latter case, there may be an escape hatch for "user-defined 
values", but I don't think the implication is normally that every future 
value is automatically covered by the same proposal. The approved key 
proposal can inform us about whether the value fits with the rest of the 
key's values -- just as an unapproved but well-written key description 
page can -- but the value still needs to be considered on its own merits.


As far as I can tell, the proposal is to ratify the existing contents of 
the key description page. I don't get the impression that, compared to 
the status quo, approving this proposal would meaningfully change the 
decision tree for someone coining a new value, or someone building an 
editor or renderer for that matter. It would be a different story if 
there's a controversy surrounding what tthe key description page says, 
or if the proposal changes the key's scope somehow, for example to 
better accommodate the everything-is-history approach of 
OpenHistoricalMap. [1]


[1] 
https://community.openstreetmap.org/t/feature-proposal-rfc-historic/3910/10


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-12 Thread Greg Troxel


Evan Carroll  writes:

>> Part of the issue is that landuse should more or less follow property
>> lines, unless there is some reason why not.  a several-acre parcel with
>> a house and some trees is still landuse=residential on all of it, absent
>> farming or some side industrial business.
>
> Property lines isn't mentioned anywhere in the wiki. Land Use crosses

The wiki is often incomplete or wrong.You are proposing a massive
change in OSM, essentially to deprecated the concept of landuse, and I
think very few people share that view.


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

Re: [Tagging] Lyft and nameless sectioning in OSM


Vào lúc 07:58 2022-10-12, Marc_marc đã viết:

Le 11.10.22 à 20:48, Andy Townsend a écrit :

That was added in https://www.openstreetmap.org/changeset/127101982 , 


I am surprised that no one is concerned about the compatibility
between its proprietary source and osm


Lyft's policy lead has clarified to the U.S. community and in various 
changeset comments that the proprietary sources consist street-level 
imagery collected by their drivers, plus aerial imagery they've licensed 
from a vendor for the purpose of mapping in OSM. [1][2] They're 
asserting that they already have the requisite rights to contribute this 
data to OSM. Personally I've been satisfied about the licensing aspect, 
but IANAL.


Verifiability is another matter, but then again, I've lost count of the 
times I've justified my own edits on the basis of "survey" or "local 
knowledge". From what I've seen, whenever another mapper contests an 
edit on the basis of publicly available imagery, Lyft does provide 
access to the specific street-level image that they used. [3][4] This 
has actually convinced me to retain more of my field surveying notes and 
photos, whereas previously I often deleted them after uploading the 
changes to OSM.


[1] 
https://osmus.slack.com/archives/C029HV951/p1631799042255700?thread_ts=1630357887.047200&cid=C029HV951
[2] 
https://osmus.slack.com/archives/CCJ2P6KCH/p1640163087244900?thread_ts=1640129896.237000&cid=CCJ2P6KCH

[3] https://www.openstreetmap.org/changeset/110957115
[4] https://www.openstreetmap.org/changeset/121425257

--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Lyft and nameless sectioning in OSM


Vào lúc 09:12 2022-10-12, Evan Carroll đã viết:

if you have x number of detached residences occupied by offices,
it is not a landuse=residential


Then it's mistakenly tagged. You do not use `building=detached` for 
shops and offices. Per the wiki, 
https://wiki.openstreetmap.org/wiki/Tag:building%3Ddetached 



 > A detached house is a free-standing residential building usually 
housing a single family. Known as a/single-family home/in the United 
States, a/single-detached dwelling/in Canada, a/separate house/in New 
Zealand and/Maison individuelle/in France.


It includes the _function_ of the building.


Strictly speaking, building=* is about the building's original function 
inasmuch as it influenced the building's construction, whereas 
building:use=*, a much less common key, closely reflects the building's 
current occupants. A building=detached could very well be functioning as 
a nonresidential dentist's office or insurance agency.


This distinction is not very evenly applied in practice. For example, 
many modern American church buildings are architecturally 
indistinguishable from commercial buildings or retail storefronts, but 
many get tagged as building=church anyways, because there's so much 
variety in religious architecture anyways. Some renderers like osm-carto 
infer prominence from building=church, befitting a boxy Texas megachurch 
without a steeple that nonetheless dominates the surrounding neighborhood.


Similarly, a layperson may find it difficult to discern that a detached 
house was long ago converted from a firehouse, so they tag it as 
building=detached instead of building=fire_station. But in some places, 
mappers have been more rigorous about respecting each building's 
architectural origins.


--
m...@nguyen.cincinnati.oh.us




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

Re: [Tagging] Lyft and nameless sectioning in OSM

>
>
> The wiki is often incomplete or wrong.You are proposing a massive
> change in OSM, essentially to deprecated the concept of landuse, and I
> think very few people share that view.
>


I don't see it like that. Why do you? Nothing in the wiki on landuse
mentions property lines.  That's not how they're used. I asked what the
value was, I was told to emphasize and de-emphasize areas on maps. They're
currently being mapped as a collection of buildings,  ie., a group of
residential buildings sits on landuse that is residential. Lyft is doing
this remotely, without ever having a foot on the ground. That's what this
topic is about. I don't see the value: but I'm saying I can do it
automatically and more accurately then Lyft, and then we can keep it in
sync rather than creating a maintenance burden. All while continuing to
deliver the same value that people see.

For reference, I disagree with tag:landuse in OSM, but this suggestion is
precisely because as OSM is currently using unnamed landuse of
developed land, the process can be automated internally and I believe we
can make everything better. What difference would be though if I
demonstrate it can be done automatically oblivious to property lines, or
Lyft continues to fund gaggles of workers to do it (oblivious to property
lines)?

Lastly, the wiki is editable. And this is the list to have a conversation
about property lines and landuse. This whole thread was because I did not
understand landuse. Now as it's been explained and as I understand it, I
have a different model of it then you do. This is problematic for everyone.
You should post on this thread about how to reform the tag:landuse:* to
mention property lines if you feel that's how the tag should be used (or is
used currently). You're the first person to bring it up as far as I see.

--
Evan Carroll - m...@evancarroll.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

>
> But in some places,
> mappers have been more rigorous about respecting each building's
> architectural origins.


This is all 100% new to me.  Where is it documented that a "shop" in a
detached house should be mapped as a detached house, and not a shop? Where
is the notion of "architectural origins" documented. I thought we could
treat the wiki as authoritative and everything else not in the wiki as a
wrong or mistaken, or unsupported?

--
Evan Carroll - m...@evancarroll.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

>
> Verifiability is another matter


That's the matter I want to cover. I'm not concerned with the legal side of
it. My method is verifiability based on our data set. It can be proven and
can be quantified to internal consistency. How does their data set which
"consists of street-level imagery collected by their drivers, plus aerial
imagery they've licensed from a vendor for the purpose of mapping in OSM"
provide more value to Landuse tagging?

iD has bing aerial imagery integration, and Mapillary/Bing street-level
imagery. As I see it, this data can be used to map all physical attributes
relevant to a determination on landuse automatically. How is this data
useful aside from that process? I can see residential/retail buildings as I
know them, and I map them very frequently from that data. After they're in
OSM what _more_ information does this data offer to a determination for
unnamed landuse of developed land? I would analyze both datasets the same
way.

Is this area delineated by roads dominated with single family detached
homes? If it is, regardless of the areal imagery, f4map, or osm-carto: it's
enough to establish residential land use? (Assuming the other point about
"architectural origins" doesn't hold, as it's not documented in the wiki).
If we in fact have a system where we support mapping shops as detached
single-value houses because mappers functioning as historians viewed that
it was likely their role a hundred years prior, then all of this is a fools
errand and the data really has much less value then I take it for.

--
Evan Carroll - m...@evancarroll.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Lyft and nameless sectioning in OSM

Vào lúc 10:56 2022-10-12, Evan Carroll đã viết:

But in some places,
mappers have been more rigorous about respecting each building's
architectural origins.

This is all 100% new to me. Where is it documented that a "shop" in a
detached house should be mapped as a detached house, and not a shop?
Where is the notion of "architectural origins" documented. I thought we
could treat the wiki as authoritative and everything else not in the
wiki as a wrong or mistaken, or unsupported?

To be clear, I'm not saying the building shouldn't be dual-tagged as a
shop or that a separate shop=* node shouldn't be mapped within it. This
is only about building classification. For example, some mappers would
tag a house converted into a barbershop as:

building=detached
building:use=retail
shop=hairdresser

Various parts of the wiki do mention this distinction in passing
[1][2][3], but I'm not surprised that you came to the opposite
conclusion when looking at other wiki pages. The wiki has a lot of
inconsistencies. That fact alone should dissuade you from treating any
one wiki page as authoritative.

I would caution against interpreting the wiki overall as a binding
document. Many tag description pages are the product of a formal feature
proposal process, but many more are created ad hoc with the intention of
describing prevailing usage. Sometimes that effort falls short or veers
into advocacy. It is useful to point out discrepancies between the wiki,
actual usage, and software support. These discussions can lead to
harmonization, but the starting point should be first principles like
end user expectations or legal distinctions, not the mere fact that a
wiki without an enforcement mechanism documented something a certain way
many years ago.

Personally, I find the distinction between building=* and building:use=*
to be pretty fussy. It's hard enough to get mappers to include a
building=* tag at all when mapping a retail building as a shop=*. But I
recognize that at least it helps 3D renderers choose a somewhat
believable model to represent a building when minutiae like roof shapes,
windows, and doors haven't been mapped.

[1] https://wiki.openstreetmap.org/wiki/Special:PermanentLink/2418589
[2]
https://wiki.openstreetmap.org/wiki/Special:PermanentLink/2357589#Tagging
[3]
https://wiki.openstreetmap.org/wiki/Special:PermanentLink/2411986#Converted_buildings_used_as_apartments

--
m...@nguyen.cincinnati.oh.us

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

Re: [Tagging] Lyft and nameless sectioning in OSM


Le 12.10.22 à 19:56, Evan Carroll a écrit :
Where is it documented that a "shop" in a detached house  
should be mapped as a detached house, and not a shop?


you should have both :
the building
the user = the shop
it's documented in "one feature = one element" :)


Where is the notion of "architectural origins" documented


https://wiki.openstreetmap.org/wiki/Key%3Abuilding%3Ause
The building:use=* key describes what kind of function a building=* 
serves. This tag can be handy when the form or original purpose of a 
building differs from its present use.




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

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-12 Thread Andy Townsend


On 12/10/2022 18:56, Evan Carroll wrote:


But in some places,
mappers have been more rigorous about respecting each building's
architectural origins.


This is all 100% new to me.  Where is it documented that a "shop" in a 
detached house should be mapped as a detached house, and not a shop? 
Where is the notion of "architectural origins" documented.


https://wiki.openstreetmap.org/wiki/Buildings

(which is the first page that I got when I searched the wiki for 
"building") has a prominent example "Tenement house containing a church, 
it is still building=apartments not building=church" (one of the 
pictures on the right; the one below it is the opposite situation).



I thought we could treat the wiki as authoritative and everything else 
not in the wiki as a wrong or mistaken, or unsupported?


No.  The wiki is maintained by volunteered on a "best efforts" basis, by 
human beings who may not have the same vision of what keys are used 
for.  That's why you'll see discussion on this list and other places 
saying things like "someone has changed wiki page X to say Y, which is 
wrong".


Sometimes there are long threads discussing exactly what people in 
different places mean by a certain form of tagging - 
https://community.openstreetmap.org/t/use-of-bicycle-designated-vs-bicycle-yes-outside-of-germany/3230 
is a recent example.  No-one there is "wrong", because they're 
explaining how they use that tag and how other people use it locally to 
them.


Best Regards,

Andy

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

Re: [Tagging] Lyft and nameless sectioning in OSM




Oct 12, 2022, 19:56 by m...@evancarroll.com:

>> But in some places,
>> mappers have been more rigorous about respecting each building's
>> architectural origins.
>>
>
> This is all 100% new to me.  Where is it documented that a "shop" in a 
> detached house should be mapped as a detached house, and not a shop? Where is 
> the notion of "architectural origins" documented. 
>
https://wiki.openstreetmap.org/wiki/Key:building

> I thought we could treat the wiki as authoritative and everything else not in 
> the wiki as a wrong or mistaken, or unsupported?
>
definitely no, wiki is full of missing info, outdated info, runaway advocacy, 
confusion, misinformation and useful info

--signed, person with enormous amount of OSM Wiki activity
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Historic


Oct 12, 2022, 16:23 by marc_m...@mailo.com:

> Le 12.10.22 à 13:15, Sebastian Martin Dicke a écrit :
>
>> If there is an aircraft standing on an airstrip which has been 
>> decommissioned yesterday (or thirty minutes ago), is it considered properly 
>> to tag them as historic=aircraft?
>>
>
> I think it depends on the history of the object :
>
> if the last Concorde [1] had been treated in this way, I think
> it would have been possible to consider it as historical from the
> first minute of its immobilisation, a page of history is turned
> after years of supersonic commercial flight, it is history.
>
> On the other hand, a single aircraft with no history other than "we don't 
> need it anymore" is not historic, neither now nor in 10 years,
> it is at best a decoration
>
> [1] https://en.wikipedia.org/wiki/Concorde
>
note that in actual mapping any such decommissioned vehicle
gets historic=vehicle (or historic=tank or similar)

Yes, that goes contrary to theoretical definition of historic=* key
desired by some. 

And it does not really seem incorrect to tag all old tanks as historic=*
(the same goes for locomotives, planes and so on).

If someone really dislikes it they can start using/promoting
https://taginfo.openstreetmap.org/tags/man_made=vehicle
or maybe https://taginfo.openstreetmap.org/tags/man_made=tank 

(and cleanup cases where it was used for man_made=storage_tank)
or maybe other tag.
Or accept current tagging as survivable.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] advices about multiple values have inaccuracies , between several pages

2022-10-12 Thread Sebastian Gürtler




Am 11.10.22 um 14:17 schrieb Marc_marc:

Hello,

I find that advices about multiple values have inaccuracies
between several pages :

https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_values

Properties can have a large number of possible values
my reading : key=yes/no value aren't a propertie, it's the value for
another key (for ex asia=yes/no is not a good idea, it's a value for
cuisine=asia




2) Properties can have a large number of possible values
key with only =yes/no value aren't a propertie, it's the value
for another key


Just want to emphasize that boolean values are really useful and
necessary - and in use without being questioned. If you have a property
that has the character of a set of features out of a quite small finite
set, which exist simultaneously, then you have two possibilities: Using
property=feat1;feat3;feat4;feat9

or split that into feat1=yes; feat3=yes; feat4=yes; feat9=yes.

Depending on defaults you could simplify in the second method: if
feat1,2,3 are yes by default, the tagging could be: feat2=no; feat9=yes.

This is the theory, in reality you have it for example in: bicycle=yes
and foot=yes and so on.

I think the first method is more error prone and more difficult to
maintain. If I check an object just for some aspects it's easier to edit
just these aspects. And the evaluation can focus on the features of
interest instead of parsing through more complicated tags. (Still
computers work on 0s and 1s!).

If you look at the sometimes complicated discussions about the access=*
tags, you can clarify things in cases of doubt easily with additional
boolean tags without checking wikipages (often with conflicting
definitions in different languages) for the default meanings.

It depends very much on the things you want to describe (and the clarity
of the main tag), which tagging scheme you choose. (bicycle=yes is clear
for highway=*, but very unclear for e.g. tourism=artwork,
artwork_type=sculpture, even if the sculpture is a bicycle).

Cheers, Sebastian


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

Re: [Tagging] Feature Proposal - RFC - Historic

2022-10-12 Thread Peter Neale via Tagging

Well, I have not seen the object in question, so I don't know what it is.
Perhaps it is a "barrier=wall; historic=yes"or an "abandonned:building=house; 
historic=yes;"or abandonned:place=village; historic=yes"
all, possibly with "ruins=yes"

Regards,Peter(PeterPan99)
On Wednesday, 12 October 2022 at 15:15:20 BST, Marc_marc 
 wrote:  
 
 Le 12.10.22 à 09:55, Peter Neale via Tagging a écrit :
> historic is an attribute of an object that IS something else

what's "something else" is a historic=archaeological_site ?
and a historic=ruins ?



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

Re: [Tagging] Lyft and nameless sectioning in OSM

2022-10-12 Thread Nick Santos

> You seem to imply this is trivial, so feel free to build a prototype of
this to see how accurate it is (note that you will need to judge the
automated method against manual mapping, not the other way around). But
most areas are probably not mapped in enough detail yet for this to work.
For example, in the Houston area you shared most buildings are only tagged
with building=yes or not even mapped at all, how will you be able to
automatically infer the landuse from that? But someone can manually
identify and map a residential area even if they don't want to map all the
houses there yet (https://www.openstreetmap.org/relation/7916453).

> Even if you have an area mapped in high detail, I don't expect this to be
that easy. In this case landuse will also generally have been accurately
mapped a long time ago.

I want to highlight this point from Enno.

I'd say if you think it's going to work, build it and show the community
examples of where it works well and where it doesn't. Discussing the
hypothetical makes us all revert to our own assumptions rather than looking
at a real comparison. I'm personally skeptical that a model will work very
well, because right now, land use tagging appears to fill in for when we're
missing more detail in the DB already, which suggests to me that to take
the more detailed data and try to infer the general case is something the
dataset isn't ready for except, maybe, in some areas.

I'd also say, as someone who writes spatial analysis models for a living,
computer models are not objective. We imbue them with our assumptions, we
set thresholds, we define data sources, and more. I'd suggest that the
model will be a subjective model that encodes how its author would
categorize land use. It will just do it at a different scale (and create a
different set of challenges for verification).

But again, I'm not saying don't build it - just expect serious scrutiny of
its outputs. I also don't think the existence of a hypothetical better
method is a reason for others to stop doing it their own way, assuming both
result in acceptable data - OSM is a project of people adding the edits
they're willing and able to edit. The methodology is only of concern if the
result is bad, and I shared my opinion on that above.

-Nick
http://nicksantos.com


On Wed, Oct 12, 2022 at 1:31 AM Enno Hermann  wrote:

> You seem to imply this is trivial, so feel free to build a prototype of
> this to see how accurate it is (note that you will need to judge the
> automated method against manual mapping, not the other way around). But
> most areas are probably not mapped in enough detail yet for this to work.
> For example, in the Houston area you shared most buildings are only tagged
> with building=yes or not even mapped at all, how will you be able to
> automatically infer the landuse from that? But someone can manually
> identify and map a residential area even if they don't want to map all the
> houses there yet (https://www.openstreetmap.org/relation/7916453).
>
> Even if you have an area mapped in high detail, I don't expect this to be
> that easy. In this case landuse will also generally have been accurately
> mapped a long time ago.
>
> -Enno (eginhard)
>
> On Tue, Oct 11, 2022 at 10:55 PM Evan Carroll  wrote:
>
>> Thanks  Joseph Eisenberg! That's exactly what I'm looking for. Good
>> answer. So basically the primary use case of an **unnamed** residential,
>> commercial, industrial, and retail "Zones" is not to convey (additional)
>> information but to serve as a good-enough styling solution about what the
>> zone conveys? As I suspected, it is solving a spatial clustering problem
>> manually to achieve a good-enough different visual style. I guess you can
>> see here in the landcover.
>>
>>
>> https://github.com/gravitystorm/openstreetmap-carto/blob/cae2309efd4ee0338fcdf9f201e92f20b338426c/style/landcover.mss#L16
>>
>> The next question is can this be defined such that this can be automated?
>> It would seem to me like if we,
>>
>> 1. Take a bounding box.
>> 2. From that, subtract out the landuse polygons for named zones, LEAVING
>> ONLY "unnamed zones, and land not in a zone."
>> 3. From that, subtract out the landuse polygons for zones NOT of type
>> "common landuse key values - developed land", per the wiki
>> https://wiki.openstreetmap.org/wiki/Key:landuse LEAVING ONLY "unnamed
>> zones of developed land, and land not in a zone."
>> 4. Subtract out by key:highway lines LEAVING ONLY "unnamed zones of
>> developed land and land not in a zone that does NOT intersect a highway."
>> 5. Extract "unnamed zones of developed land and land not in a zone that
>> does NOT intersect a highway" into a zone set.
>> 6. Infer from the contents of the polygon what type of developed land the
>> zone is.
>>
>> This would allow us to be precise and objective and determine what kind
>> of "developed land" an unnamed zone was, as well as to provide a gauge of
>> the accuracy of the zone.
>>
>> If this was done, do you think th

Re: [Tagging] Apparently bubblers emitting jet of water on buton press are water taps