Re: [Talk-us] Washington DC place node cleanup

[Mateusz Konieczny via Talk-us]

I posted a changeset comment in https://www.openstreetmap.org/changeset/76520412


Dec 6, 2020, 08:00 by m...@nguyen.cincinnati.oh.us:

> Vào lúc 03:01 2020-12-04, Frederik Ramm đã viết:
>
>> Hi,
>>
>> when reverting an edit this morning I noticed that the node for
>> Washington (https://www.openstreetmap.org/node/158368533) has myriad
>> name:xx tags, many of which seem to be some variant of "Washington D.C."
>> (with or without commas or dots), whereas the "local" name seems to be
>> just Washington, without the D.C.
>>
>> As a native speaker of German I can assure you that we don't call the US
>> capital "Washington D.C." as the name:de tag claims; I would assume that
>> it is similar for most other languages. The German-language OSM map at
>> https://www.openstreetmap.de/karte.html?zoom=10&lat=38.70174&lon=-76.93764
>> has a mechanism where it displays the German name and then, if the local
>> name is different, the local name below; since the German name
>> "Washington D.C." and the local name "Washington" are different, this
>> leads to a somewhat funny display (whereas the logic works ok for other
>> US cities).
>>
>> I could of course fix the German name but I think that it might need a
>> more thorough review and I don't feel competent for that.
>>
>> Two name tags (and this is checking only those that use Roman letters)
>> look like they might be entirely wrong and refer to the District of
>> Columbia only:
>>
>> name:lfn=Distrito de Columbia
>> name:mi=Takiwā o Columbia
>>
>
> Most of these localized names were added in changeset 76520412 [1] based on 
> labels on the associated Wikidata item. [2] So this time it was not a case of 
> promoting a particular minority language. In fact, I don't think much 
> attention was paid to the names being added, or perhaps the Tajik name 
> would've remained to the effect of "Washington District of Columbia" instead 
> of being changed to "Washington (city)".
>
> This same changeset changed the name of the District of Columbia relation to 
> "Washington, D.C." in many languages, including English. [3] This results in 
> Nominatim returning results like "Washington, D.C., Washington, D.C." I think 
> it was inappropriate to rename the district this way. I think it was another 
> oversight on the part of the changeset's author, because Wikidata has a 
> distinct entity for the district. [4]
>
> [1] https://www.openstreetmap.org/changeset/76520412
> [2] https://www.wikidata.org/entity/Q61
> [3] https://www.openstreetmap.org/relation/162069
> [4] https://www.wikidata.org/wiki/Q3551781
>
>> Then again, I've heard people say "I was in D.C." and mean the city, so
>> perhaps that *is* a legitimate name for the city? Maybe someone in the
>> US community wants to have a look and do this right.
>>
>> It is a bit of a conundrum in OSM - we usually say that local knowledge
>> tops everything, but then again for many of the languages there might
>> not even *be* a local Washington mapper in OSM ;)
>>
>
> As others have pointed out, a local would refer to the city as "D.C." even 
> while acknowledging that the city's formal written name is "Washington" or 
> "Washington, D.C." I think common sense would require us to relegate "D.C." 
> to loc_name or short_name, just as a general-purpose, global map would only 
> shorten San Francisco to the local shorthand "S.F." and Salt Lake City to 
> "SLC" when space is at a premium.
>
> Thanks in part to the D.C.-based Voice of America, I'm sure you could find a 
> local to get the translated name of Washington, D.C., for many languages, but 
> I'm not confident they would choose the same names as Wikidata.
>
> For example, both VOA and the local Vietnamese media still generally call the 
> city "Hoa Thịnh Đốn", a relic of the early 20th century when Vietnamese still 
> borrowed Chinese characters for world-class cities. "Hoa Thịnh Đốn" is easy 
> for a Vietnamese speaker to pronounce, but it only kind of sounds like 
> "Washington" in the way that an eggcorn sounds like its original phrase. It's 
> archaic and probably unknown to the younger generation in Vietnam. The 
> Vietnamese government prefers the phonetic respelling "Oa-sinh-tơn", which 
> conversely is unknown to older Vietnamese Americans.
>
> When I originally tagged the D.C. node with Vietnamese names in changeset 
> 5439052, I intended for the fallback to be "Washington", as a compromise 
> between the traditional and more modern names. But I hesitated to explicitly 
> tag name:vi=Washington because it's incompatible with the Vietnamese 
> alphabet. I guess I should've added it as a bulwark against armchair 
> linguistics. Changeset 76520412 set name:vi to "Washington, D.C.", which to a 
> Vietnamese speaker is rather like labeling New Orleans as "New Orleans, LA" 
> on a map.
>
> Long story short, I find changeset 76520412 to be problematic in the 
> languages I know, let alone the many languages I don't. Thanks for bringing 
> it to our attention.
>
> -- 
> m...@nguye

Re: [Talk-us] Washington DC place node cleanup

[Mateusz Konieczny via Talk-us]

Dec 4, 2020, 12:43 by frede...@remote.org:

> I have often argued for just dropping name:X if it is the name as name,
> because I would assume that every language-specific map or other use
> case would revert to the name tag if no language-specific name was present.
>
> The counter-argument was usually that if Washington has a
> name:de=Washington then you positively know that this is the name used
> in Germany, whereas if it doesn't have a name:de tag it might just be
> "not yet mapped".
>
Also, with explicit language tags you can do fallback to other languages
(as described in detail in other posting).

This way you can do "I prefer name:pl, use name:de otherwise, if neither is
present use name:en, if nothing is available, use name tag".
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Washington DC place node cleanup

[Mateusz Konieczny via Talk-us]

name:pl tag is fortunately correct


Dec 4, 2020, 12:33 by mikel.ma...@gmail.com:

> Hi
>
> In DC, we just say DC usually. Across the states, it's Washington DC to 
> distinguish from Washington state.
>
> I'm not sure what the "name" tag should be, but I am wondering what the point 
> of the translations are which simply duplicate the default name. Is it like a 
> marker to say "don't try calling this place anything else"? Is that common, 
> seems unneccesary?
>

It may be useful. For example lets say that I want to display names with labels
in Polish, with English labels as fallback.

After all, some location in China or Japan may have specified name:en, but not 
name:pl

So name:pl value would be taken as the first one, name:en if name:pl is missing
and name tag if both are missing.

But what happens when some object has Polish name[1], tagged in name and 
different
name tagged in name:en?

Then name:en would be displayed, what would be avoided if name tag would be 
repeated
in name:pl tag.


[1](maybe because it is city in Poland,
maybe because it is shop in USA selling primarily to Polish-speaking people, 
maybe
it is a school for children of emigrants)



(this is based on actual project, both from my own experience and someone else 
from Poland
run independently in the same issue)

PS: No, region-based rules are not working fully even for languages that are 
nearly completely
dominating in a given region and are nearly not present elsewhere, due to 
"nearly" part.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Please unsubscribe me.

[Mateusz Konieczny via Talk-us]

I triggered unsubscription for natf...@gmail.com

You still need to confirm this action, as explained in email
that should be send to you


Nov 23, 2020, 22:06 by ian.d...@gmail.com:

> Hi Nathan,
>
> You need to unsubscribe yourself. Please follow the instructions here: > 
> https://lists.openstreetmap.org/listinfo/talk-us
>
> On Mon, Nov 23, 2020 at 3:05 PM Natfoot <> natf...@gmail.com> > wrote:
>
>> Please unsubscribe me I am done with OSM for a while. 
>>
>> Nathan P
>> email: >> natf...@gmail.com
>> ___
>>  Talk-us mailing list
>>  >> Talk-us@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk-us
>>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Tagging] Extremely long Amtrak route relations / coastline v. water

[Mateusz Konieczny via Talk-us]

Nov 22, 2020, 17:08 by tagg...@openstreetmap.org:

> Likewise we need to stop software developers from expectingcontributors 
> to add data purely because they can't be bothered/notcompetent enough to 
> write a few lines of code. (OSM-carto demandingboundaries on ways)
>
[citation needed] for OSM-carto demandingboundaries on ways

Also [citation needed] for OSM-Carto support for boundary relations being 
extremely easy to implement

>  & numerous routers expecting multiplefoodways to criss-cross pedestrian 
> areas, are just two examples) 
>
Also [citation needed] for that reason is
"can't be bothered/notcompetent enough to write a few lines of code" 

>  If developers are offended at receiving suggestions on how toimprove 
> their software, or even have it criticized, then they shouldrescind it. 
>
If you insult others, claim that something is trivial to implement (it is not),
while something you demand is implemented already and suggest that
anyone offended by your comments should stop releasing software

I would say that it is quite poor way to encourage volunteer
contributors to implement what you want.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Import licensing waiver

[Mateusz Konieczny via Talk-us]

It was a correct one - you were aware about it and learned about another
one that may be more useful :)


Oct 9, 2020, 20:05 by lobstereat...@airmail.cc:

> Ok, thank you for the guidance. I will forward to legal-talk, and I
> apologize if this wasn't the correct mailing list.
>
> On Fri, 2020-10-09 at 15:44 +0200, Mateusz Konieczny wrote:
>
>> AFAIK "makes no claim as to the usefulness, accuracy or completeness"
>> is not a problem, whoever is doing imports must do this part anyway.
>>
>> But what is the license of the data?
>> Maybe "Syracuse-Onondaga County Planning Agency has no objections"
>> is sufficient (I am not a lawyer) - but only  if that agency holds
>> full rights to the dataset
>>
>> As usual, legal-talk has greater chance to get response with someone
>> with greater
>> legal knowledge.
>>
>> Oct 9, 2020, 14:38 by lobstereat...@airmail.cc:
>> > Hello,
>> > 
>> > I have been in contact with the Syracuse-Onondaga County Planning
>> > Agency (SOCPA), an Onondaga County NY agency, about the licensing
>> > of a
>> > building footprint layer they have. My intention was to import this
>> > layer after further review by the OSM community and myself. After
>> > contacting the agency head about a possible waiver for OSM use (
>> > along
>> > the lines of
>> > https://wiki.openstreetmap.org/wiki/Import/Getting_permission#Letter_Template_1
>> > ), I received this response:
>> > 
>> > The Syracuse-Onondaga County Planning Agency has no objections to
>> > geodata derived in part from the "Onondaga County Building
>> > Footprints"
>> > layer being incorporated into the OpenStreetMap project geodata
>> > database and displayed publicly on the map. By using the data,
>> > however, the OpenStreetMap project agrees that Onondaga County
>> > makes no
>> > claim as to the usefulness, accuracy or completeness of the
>> > county's
>> > building footprint file, and the county will not be held
>> > responsible
>> > for any omissions or inaccuracies. This data is provided as is and
>> > there is no guarantee that it is suitable for any particular
>> > purpose. 
>> > Your use of the data is at your own risk. 
>> > 
>> > Is this licensing favorable for use by the OSM community?
>> > 
>> > 
>> > ___
>> > Talk-us mailing list
>> > Talk-us@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-us
>>
>>  
>>
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Import licensing waiver

[Mateusz Konieczny via Talk-us]

AFAIK "makes no claim as to the usefulness, accuracy or completeness"is not a 
problem, whoever is doing imports must do this part anyway.

But what is the license of the data?
Maybe "Syracuse-Onondaga County Planning Agency has no objections"
is sufficient (I am not a lawyer) - but only  if that agency holds full rights 
to the dataset

As usual, legal-talk has greater chance to get response with someone with 
greater
legal knowledge.

Oct 9, 2020, 14:38 by lobstereat...@airmail.cc:

> Hello,
>
> I have been in contact with the Syracuse-Onondaga County Planning
> Agency (SOCPA), an Onondaga County NY agency, about the licensing of a
> building footprint layer they have. My intention was to import this
> layer after further review by the OSM community and myself. After
> contacting the agency head about a possible waiver for OSM use ( along
> the lines of
> https://wiki.openstreetmap.org/wiki/Import/Getting_permission#Letter_Template_1
> ), I received this response:
>
> The Syracuse-Onondaga County Planning Agency has no objections to
> geodata derived in part from the "Onondaga County Building Footprints"
> layer being incorporated into the OpenStreetMap project geodata
> database and displayed publicly on the map.  By using the data,
> however, the OpenStreetMap project agrees that Onondaga County makes no
> claim as to the usefulness, accuracy or completeness of the county's
> building footprint file, and the county will not be held responsible
> for any omissions or inaccuracies. This data is provided as is and
> there is no guarantee that it is suitable for any particular purpose. 
> Your use of the data is at your own risk. 
>
> Is this licensing favorable for use by the OSM community?
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

[Mateusz Konieczny via Talk-us]

Sep 29, 2020, 11:15 by burke...@gmail.com:

> On Tue, Sep 29, 2020 at 2:35 AM Mateusz Konieczny via Talk-us
>  wrote:
>
>>
>> 29 wrz 2020, 02:02 od b...@mapwise.com:
>>
>> An example unhelpful comment:
>>
>>  "YES GEORGIA IS BADLY-TAGGED TRUNK FREE! Control is provided by 
>> floridaeditor; i.e., if anybody tries to change one back I will review the 
>> edit and keep/revert as needed."
>>
>> WTF
>>
>> Brian aka grouper
>>
>> Can you link to changeset where it happened?
>>
>> This alone is enough to involve DWG
>> and I would expect at least 0-time block
>> (message displayed on login).
>>
>
> Mateusz,
>
> The specific one that Brian quoted is here:
> https://www.openstreetmap.org/changeset/87987046
>
Thanks! It is quite old and I see that at that time DWG already contacted
that person, so for now I just left a message asking to
cease making such comments .

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Recent Trunk road edits

[Mateusz Konieczny via Talk-us]

29 wrz 2020, 02:02 od b...@mapwise.com:
> An example unhelpful comment:
>
>     "> YES GEORGIA IS BADLY-TAGGED TRUNKFREE! Control is provided 
> by floridaeditor; i.e., if anybodytries to change one back I will 
> review the edit and keep/revertas needed."
>
> WTF
>
> Brian aka grouper
>
Can you link to changeset where it happened?

This alone is enough to involve DWG
and I would expect at least 0-time block
(message displayed on login).___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Large fire perimeter tagging?

[Mateusz Konieczny via Talk-us]

I am a bit dubious about value of updating fire=perimeter

It is something that changes extremely quickly, we should
not encourage people to survey perimeter of ACTIVE fire,
OSM is doomed to be strictly worse source of fire perimeter
than alternative sources

> fire has absolutely enormous impact to what we do and might map here,
both present and future.  The aftermath of this fire (>85,000 acres this fire 
alone)
will last for decades, and for OSM to not reflect this in the map

Obviously, we should (try to) update map where situation changed.

Delete building that will not be rebuild (mark them as destroyed:building=*
until aerial imagery will update)
[deleting buildings and remapping them as they get reconstructed may
be viable in cases of heavy mapper presence]

Delete other permanently destroyed objects and so on.

> Do we have landcover tags which could replace landuse=forest
or natural=wood with something like natural=fire_scarred?

AFAIK nothing established, see
https://lists.openstreetmap.org/pipermail/tagging/2018-March/035435.html
for related discussion about wind damage.

Sep 24, 2020, 23:30 by stevea...@softworkers.com:

> I didn't get a single reply on this (see below), which I find surprising, 
> especially as there are currently even larger fires that are more widespread 
> all across the Western United States.
>
> I now ask if there are additional, appropriate polygons with tags I'm not 
> familiar with regarding landcover that might be added to the map (as 
> "landuse=forest" might be strictly true now only in a 'zoning' sense, as many 
> of the actual trees that MAKE these forests have sadly burned down, or 
> substantially so).
>
> Considering that there are literally millions and millions of acres of 
> (newly) burned areas (forest, scrub, grassland, residential, commercial, 
> industrial, public, private...), I'm surprised that OSM doesn't have some 
> well-pondered and actual tags that reflect this situation.  My initial 
> tagging of this (simply tagged, but enormous) polygon as "fire=perimeter" was 
> coined on my part, but as I search wiki, taginfo and Overpass Turbo queries 
> for similar data in the map, I come up empty.
>
> First, do others think it is important that we map these?  I say yes, as this 
> fire has absolutely enormous impact to what we do and might map here, both 
> present and future.  The aftermath of this fire (>85,000 acres this fire 
> alone) will last for decades, and for OSM to not reflect this in the map 
> (somehow, better bolstered than a simple, though huge, polygon tagged with 
> fire=perimeter, start_date and end_date) seems OSM "cartographically misses 
> something."  I know that HOT mappers map the "present- and aftermath-" of 
> humanitarian disasters, I've HOT-participated myself.  So, considering the 
> thousands of structures that burned (most of them homes), tens of thousands 
> of acres which are burn-scarred and distinctly different than their 
> landcover, millions of trees (yes, really) and even landuse is now currently 
> tagged, I look for guidance — beyond the simple tag of fire=perimeter on a 
> large polygon.
>
> Second, if we do choose to "better" map these incidents and results (they are 
> life- and planet-altering on a grand scale) how might we choose to do that?  
> Do we have landcover tags which could replace landuse=forest or natural=wood 
> with something like natural=fire_scarred?  (I'm making that up, but it or 
> something like it could work).  How and when might we replace these with 
> something less severe?  On the other hand, if it isn't appropriate that we 
> map any of this, please say so.
>
> Thank you, especially any guidance offered from HOT contributors who have 
> worked on post-fire humanitarian disasters,
>
> SteveA
> California (who has returned home after evacuation, relatively safe now that 
> this fire is 100% contained)
>
>
> On Aug 29, 2020, at 7:20 PM, stevea  wrote:
>
>> Not sure if crossposting to talk-us is correct, but it is a "home list" for 
>> me.
>>
>> I've created a large fire perimeter in OSM from public sources, 
>> http://www.osm.org/way/842280873 .  This is a huge fire (sadly, there are 
>> larger ones right now, too), over 130 square miles, and caused the 
>> evacuation of every third person in my county (yes).  There are hundreds, 
>> perhaps thousands of structures, mostly residential homes, which have burned 
>> down and the event has "completely changed" giant redwoods in and the 
>> character of California's oldest state park (Big Basin).
>>
>> This perimeter significantly affects landuse, landcover and human patterns 
>> of movement and activity in this part of the world for a significant time to 
>> come.  It is a "major disaster."  I'm curious how HOT teams might delineate 
>> such a thing (and I've participated in a HOT fire team, mapping barns, water 
>> sources for helicopter dips and other human structures during a large fire 
>> near me), I've simply made a polygon tagged f

Re: [Talk-us] [Tagging] Large fire perimeter tagging?

[Mateusz Konieczny via Talk-us]

landuse=forest is used to tag tree covered area, not for how land is used

It is also basically universally interpreted this way by various data consumers.

Sep 25, 2020, 00:05 by cliff...@snowandsnow.us:

> Steve,
> Just a reminder, landuse is to tag what the land is used for. landuse=forest 
> is for areas that have harvestable wood products, ie trees. Just because 
> there was a fire doesn't mean the landuse changes. Landcover is a better tag 
> for burnt areas as well as areas just clearcut. 
>
>
>
> On Thu, Sep 24, 2020 at 2:31 PM stevea <> stevea...@softworkers.com> > wrote:
>
>> I didn't get a single reply on this (see below), which I find surprising, 
>> especially as there are currently even larger fires that are more widespread 
>> all across the Western United States.
>>  
>>  I now ask if there are additional, appropriate polygons with tags I'm not 
>> familiar with regarding landcover that might be added to the map (as 
>> "landuse=forest" might be strictly true now only in a 'zoning' sense, as 
>> many of the actual trees that MAKE these forests have sadly burned down, or 
>> substantially so).
>>  
>>  Considering that there are literally millions and millions of acres of 
>> (newly) burned areas (forest, scrub, grassland, residential, commercial, 
>> industrial, public, private...), I'm surprised that OSM doesn't have some 
>> well-pondered and actual tags that reflect this situation.  My initial 
>> tagging of this (simply tagged, but enormous) polygon as "fire=perimeter" 
>> was coined on my part, but as I search wiki, taginfo and Overpass Turbo 
>> queries for similar data in the map, I come up empty.
>>  
>>  First, do others think it is important that we map these?  I say yes, as 
>> this fire has absolutely enormous impact to what we do and might map here, 
>> both present and future.  The aftermath of this fire (>85,000 acres this 
>> fire alone) will last for decades, and for OSM to not reflect this in the 
>> map (somehow, better bolstered than a simple, though huge, polygon tagged 
>> with fire=perimeter, start_date and end_date) seems OSM "cartographically 
>> misses something."  I know that HOT mappers map the "present- and 
>> aftermath-" of humanitarian disasters, I've HOT-participated myself.  So, 
>> considering the thousands of structures that burned (most of them homes), 
>> tens of thousands of acres which are burn-scarred and distinctly different 
>> than their landcover, millions of trees (yes, really) and even landuse is 
>> now currently tagged, I look for guidance — beyond the simple tag of 
>> fire=perimeter on a large polygon.
>>  
>>  Second, if we do choose to "better" map these incidents and results (they 
>> are life- and planet-altering on a grand scale) how might we choose to do 
>> that?  Do we have landcover tags which could replace landuse=forest or 
>> natural=wood with something like natural=fire_scarred?  (I'm making that up, 
>> but it or something like it could work).  How and when might we replace 
>> these with something less severe?  On the other hand, if it isn't 
>> appropriate that we map any of this, please say so.
>>  
>>  Thank you, especially any guidance offered from HOT contributors who have 
>> worked on post-fire humanitarian disasters,
>>  
>>  SteveA
>>  California (who has returned home after evacuation, relatively safe now 
>> that this fire is 100% contained)
>>  
>>  
>>  On Aug 29, 2020, at 7:20 PM, stevea <>> stevea...@softworkers.com>> > wrote:
>>  > Not sure if crossposting to talk-us is correct, but it is a "home list" 
>> for me.
>>  > 
>>  > I've created a large fire perimeter in OSM from public sources, >> 
>> http://www.osm.org/way/842280873>>  .  This is a huge fire (sadly, there are 
>> larger ones right now, too), over 130 square miles, and caused the 
>> evacuation of every third person in my county (yes).  There are hundreds, 
>> perhaps thousands of structures, mostly residential homes, which have burned 
>> down and the event has "completely changed" giant redwoods in and the 
>> character of California's oldest state park (Big Basin).
>>  > 
>>  > This perimeter significantly affects landuse, landcover and human 
>> patterns of movement and activity in this part of the world for a 
>> significant time to come.  It is a "major disaster."  I'm curious how HOT 
>> teams might delineate such a thing (and I've participated in a HOT fire 
>> team, mapping barns, water sources for helicopter dips and other human 
>> structures during a large fire near me), I've simply made a polygon tagged 
>> fire=perimeter, a name=* tag and a start_date.  I don't expect rendering, 
>> it's meant to be an "up to right about here" (inside the polygon is/was a 
>> burning fire, outside was no fire).  I wouldn't say it is more accurate than 
>> 20 to 50 meters on any edge, an "across a wide street" distance to be "off" 
>> is OK with me, considering this fire's size, but if a slight skew jiggles 
>> the whole thing into place better, feel f

Re: [Talk-us] While we're fixing things in iterations

[Mateusz Konieczny via Talk-us]

Sep 23, 2020, 23:37 by stevea...@softworkers.com:

> Paul Johnson  wrote:
>
>> Can we finally fix two other longstanding problems, then?
>>
>> 1. The wiki being incorrect about not counting bicycle lanes.  That's not 
>> reflective of how validators deal with lanes, how data consumers like Osmand 
>> or Magic Earth deal with lanes, or how ground truth works.  The whole "but 
>> you can't fit a motor vehicle down it" argument is facile, that's what 
>> access:lanes=* and width:lanes=* is for.
>>
>
> If it truly is the wiki that needs fixing, I'm all for fixing the wiki here.  
> Is there some reason the relatively low bar of making a change to the wiki 
> hasn't been done yet?
>
>> 2. Tagging route information on ways.  It's about a decade too long at this 
>> point for ref=* on a way to be completely disconnected from the entity the 
>> tag applies to:  That's why route relations exist.  Biggest problem child on 
>> this at the moment:  OSM's own tilesets.  Let's drop rendering for ref=* on 
>> ways and just render the route relations already, this and multipolygons are 
>> why relations came to exist in the first place.
>>
>
> Yes, 100% agreement.  I think this is simply pure inertia (the kind that says 
> "broken process") on the part of renderers.
>
> Can anybody (renderer authors included, maybe even especially) are welcome to 
> offer reasons why "the old machinery" remains in place?
>
in case of OSM Carto: see 
https://github.com/gravitystorm/openstreetmap-carto/issues/596 - 
no one implemented it

(if you are unable to implement it, feel free to upvote original report to 
express desire for it,
but please do not make "+1"/"implement pls" on the issue tracker)  

> While I still find murky and mysterious exactly "how" to effect change in 
> renderers (who you gonna call?), 
>
The most effective  way is to implement them (I wanted names of bus stops, I 
proposed it
in https://github.com/gravitystorm/openstreetmap-carto/issues/195 and 
implemented it
after it was clear that it would be accepted - now since 2014 bus stops in 
default map style are
displaying names, I did similar with rendering of bridge areas and other issues 
then I become
inactive after fixing all thing that were important to me and relatively easy 
compared to their
importance).

You can also test submitted pull requests ( 
https://github.com/gravitystorm/openstreetmap-carto/pulls )
and express your opinions about this new changes.

You can also comment on new tickets, especially if some ideas are problematic.

You can also report issues or upvote reported issues, though it has smaller 
impact.

You can also implement your own rendering style and run it.

You can also hire someone to do stuff listed above (not sure whatever it ever 
happened,
it should be probably disclosed if someone is getting paid to make some 
specific pull
requests and there is no guarantee that change would be accepted by maintainers)

> my two best efforts along these lines are to "tag well" and "wiki well."  
> (And that can include a great deal of discussion and consensus building on 
> its own, no doubt).  Eventually, (and I've discovered it can take years), 
> renderers do catch up.
>
And also this - say man_made=bridge rendering was possible because there
was substantial use and good tagging proposal. It would not be added otherwise.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] While we're fixing things in iterations

[Mateusz Konieczny via Talk-us]

Sep 24, 2020, 01:00 by ba...@ursamundi.org:

>
>
> On Wed, Sep 23, 2020 at 5:56 PM Andy Townsend <> ajt1...@gmail.com> > wrote:
>
>>
>>
>>
>> On 23/09/2020 23:01, Paul Johnson  wrote:
>>
>>>
>>>
>>> On Wed, Sep 23, 2020 at 4:37PM stevea <>>> 
>>> stevea...@softworkers.com>>> >wrote:
>>>
 Paul Johnson < ba...@ursamundi.org > wrote: 

 > 2. Tagging route information on ways.  It's about adecade 
 > too long at this point for ref=* on a way to becompletely 
 > disconnected from the entity the tag applies to: That's why 
 > route relations exist.  Biggest problem child onthis at the 
 > moment:  OSM's own tilesets.  Let's droprendering for ref=* 
 > on ways and just render the routerelations already, this and 
 > multipolygons are why relationscame to exist in the first 
 > place.
  
  Yes, 100% agreement.  I think this is simply pure inertia(the 
 kind that says "broken process") on the part ofrenderers.
  
  Can anybody (renderer authors included, maybe evenespecially) 
 are welcome to offer reasons why "the oldmachinery" remains in 
 place?  Are there legacy use casesthat remain unclear to the 
 wider community?  Please tell ushere, if so.

>>
>> The US is unusual in that it doesn't have a single ref per  section of 
>> road.  Most places in OSM map what they see on the  ground, and the 
>> current OSM Carto rendering works just fine for  them
>>
>>
> Right up until there's more than one kind of route on the way. 
>
???

As far as I can see it also works fine, 
see say https://www.openstreetmap.org/#map=17/50.08717/19.80950 
with ref=A4;7 and ref=S52;7

And in places where this rendering breaks due to large number of refs, rendering
from relations would also break

Rendering from ref on road and ref from relation would be displayed in exactly 
the same way,
so if current display is bad it would not be fixed by changing to rendering 
from relations


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

[Mateusz Konieczny via Talk-us]

31 Aug 2020, 05:38 by stevea...@softworkers.com:

> On Aug 30, 2020, at 5:50 PM, Brian Stromberg  
> wrote:
>
>> I would argue that maps can only show the world as the mapmaker wants it to 
>> be shown, and OSM should probably not be encouraging people (in any way) to 
>> be visiting sites that are clearly marked as illegal to visit. This seems 
>> like a bad precedent to set. I would include the bunker but not mark it as 
>> tourism. People will find it if they want to, whatever OSM tags it as, so it 
>> doesn't seem necessary to participate/encourage in whatever degree of 
>> illegality the access entails.
>>
>
> And here is where some disagree:  OSM does not "encourage."  OSM is data.  It 
> simply says "this is" and "these are."  OSM does not encourage people (in any 
> way) to visit a site or trespass.  It is a collection of data (of "what is") 
> expressed as a map.  Full stop.
>
At the same time we know that viewpoint
data can be used, is used and it's typical 
use is to display interesting locations
worth visiting.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

[Mateusz Konieczny via Talk-us]

31 Aug 2020, 10:12 by frede...@remote.org:
> And @Mateusz, I am not convinced that "there are great views from here"
> is sufficient for tourism=viewpoint because it is too subjective. With
> that reasoning, someone with a personal low bar for "great views" could
> plaster the map with tourism=viewpoint.
>
It is the same as with highway=tertiary/
secondary/primary.

Someone with too low bar may plaster
map with highway=primary.

Both cases happened, both were noticed
and spurious objects 
downgraded/removed.

"Only places signed as viewpoint"
would remove valuable data in Poland,
and solving problem that AFAIK is not
existing. At least in places where I visited
(except rare cases).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

[Mateusz Konieczny via Talk-us]

Aug 31, 2020, 00:17 by frede...@remote.org:

> Hi,
>
> On 8/30/20 22:08, Mateusz Konieczny via Talk-us wrote:
>
>> Though I wonder what should be done with viewpoint itself.
>>
>
> In my mind, a viewpoint is not just something from where you have a nice
> view; it needs to be signposted or called a viewpoint. This, while
> enjoying some "destination" or perhaps even "attraction" status, is not
> what I would call a viewpoint. And even a tourist attraction, I think,
> should not be something that is illegal to visit.
>
(1) I think that explicit signpost is not necessary, unusually great
view seems sufficient. At least that is how I used this tag.

(2) As I understand, this place is described/called viewpoint
in multiple sources and widely used as such. So it is fulfilled anyway.

(3) In such case I would actually care about legality (I would not
always care about it! For example I would happily violate China/
North Korean/Russian laws about legality of mapping).

But sadly, it appears to actually to be viewpoint and on the ground
survey would almost certainly confirm this.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Opinions on Devil's Slide Bunker (San Mateo, CA)

[Mateusz Konieczny via Talk-us]

Aug 30, 2020, 20:01 by frede...@remote.org:

>
> While it is undeniably a de-facto tourist attraction, and undeniably
> offers great views, I think it should probably be changed to
> historic=ruins, access=no, and the tracks leading up to it should also
> be changed to access=no.
>
> Opinions?
>
It seems quite clear that tracks should have correct legal status set.

Though I wonder what should be done with viewpoint itself.

It is actually viewpoint, it is clearly an attractiom so should
we delete tourism=viewpoint? Probably no.

tourism=viewpoint + access=no (that will be ignored by
all/nearly all data consumers)?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Mapcarta with wrong info in Utah - whom to contact?

[Mateusz Konieczny via Talk-us]

27 Aug 2020, 14:37 by ian.d...@gmail.com:

>
>
> On Thu, Aug 27, 2020, 03:03 Mateusz Konieczny via Talk-us <> 
> talk-us@openstreetmap.org> > wrote:
>
>>
>>
>>
>> Aug 27, 2020, 09:52 by >> frede...@remote.org>> :
>>
>>> Hi,
>>>
>>> On 27.08.20 00:30, Alex Weech wrote:
>>>
>>>> They appear to be pulling straight from Google
>>>>
>>>
>>> Interesting! I didn't know you could (show an OSM map and pull POIs from
>>> Google).
>>>
>> AFAIK it is not against OSM license but it is break terms of service set by 
>> Google. 
>>
>>
>
> Since Google doesn't have a way to programmatically get this data about 
> places, it's more likely that Google and Mapcarta used the same data source 
> that list an incorrect phone number. 
>
At least some time ago Google Places
API existed. Is it shut down now?

https://developers.google.com/places/web-service/overview
describes it as an existing
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Mapcarta with wrong info in Utah - whom to contact?

[Mateusz Konieczny via Talk-us]

Aug 27, 2020, 09:52 by frede...@remote.org:

> Hi,
>
> On 27.08.20 00:30, Alex Weech wrote:
>
>> They appear to be pulling straight from Google
>>
>
> Interesting! I didn't know you could (show an OSM map and pull POIs from
> Google).
>
AFAIK it is not against OSM license but it is break terms of service set by 
Google. 

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Potential Import of Addresses for Thurston County, WA, USA

[Mateusz Konieczny via Talk-us]

Is specifying source in changeset
or on import page on Wiki qualifying
as crediting them?

Because doing this is actually required.

26 Aug 2020, 02:07 by thekingofrav...@disroot.org:

> Alright I have an update:
>
> After an email chain with Thurston County GeoData Center, I finally got
> explicit permission to use the data in open street map. 
>
> "Hello Raven,
>
> You can use the data in Open Street Maps and credit GeoData UNLESS you
> change the data in any way. If you change the data you can still use it
> in Open Street Maps but CANNOT credit GeoData and the County. We make
> no warrantees about the data temporally, spatially, or in terms of
> attribution.
>
> Please let me know if this helps to clarify the disclaimer or if you
> still have questions.
>
> Thank you!
>
> Leslie Carman
> GIS Analyst I"
>
> I can provide the entire email chain if required but this is the part
> that matters. As for the terms they gave me, what is the best way of handling 
> this? My instinct is just to, in some very minor way, ensure every piece of 
> data is modified somehow so future mappers do not have to worry about it. 
> Does just adding it to OSM count as modification, since we convert the data 
> fields?
>
> At this point, I would like to propose that we import this data, as
> this includes rural towns and unincorporated thurston
> county.
> I would divide the building footprints into small blocks to avoid well
> mapped areas.
> As for addresses, because they are points and there are so few
> addresses in my region, I feel like we could be more aggresive about
> that import, although how much so I am not certain.
>
>
> Also @Clifford Snow if you see this I would appreciate whatever you
> have to teach about imports. 
>
> Sincerely,
> Raven
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Fwd: Re: [Tagging] [Talk-transit] [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[Mateusz Konieczny via Talk-us]

The answer by Clay Smalley was public and visible on mailing lists.
Personally I was not answering because someone started
mailing list thread under badly chosen title and spammed
it to [Talk-us] AND [Tagging] AND [Talk-transit] AND [OSM-talk]

Why not also to [Imports] and [Talk-pl] and [Talk-diversity]
And [talk-ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn]?


Aug 22, 2020, 21:48 by talk-us@openstreetmap.org:

> ever time this person answers, no one else will talk because he is addressing 
> it to me and not the grope.
>  
> i have never id him as he has me, what about the rules ?
>
>
>  Forwarded message 
> From: Clay Smalley <> claysmal...@gmail.com <>> >
> To: 80hnhtv4a...@bk.ru, Public transport/transit/shared taxi related topics 
> <> talk-tran...@openstreetmap.org <>> >
> Cc: t...@openstreetmap.org, tagg...@openstreetmap.org, OSM Talk US <> 
> talk-us@openstreetmap.org <>> >
> Date: Saturday, August 22, 2020 2:33 PM -05:00
> Subject: Re: [Tagging] [Talk-transit] [OSM-talk] Call for verification (Was: 
> Re: VANDALISM !)
>  > Everyone knows who you're talking about at this point, and nobody cares. 
> Use the remaining day or so of your temporary ban to work on some hobbies 
> outside of OpenStreetMap. 
>  
> And be careful about who you say isn't local. I'm moving to Northern Indiana 
> next week and I'll certainly get the chance to survey many of the estimated 
> stop positions I remotely mapped. I hope to see you around as we continue 
> working on the same things.
>  
> On Sat, Aug 22, 2020, 12:21 PM 80hnhtv4agou--- via Talk-transit <> 
> talk-tran...@openstreetmap.org 
> > 
> > wrote:
>
>>> it was one person in CA adding 400 unverified tags to rail service in 
>>> chicago.
>>>  
>>> one just 818 m, away from my home.
>>>  
>>>
 SATURDAY, August 22, 2020 12:32 PM -05:00 from Martin Koppenhoefer < 
 dieterdre...@gmail.com  >:

 sent from a phone
  
 > On 22. Aug 2020, at 10:15, pangoSE < pang...@riseup.net <> > 
 > wrote:
 >
 > Here is yet another example of bad data in our database:

 fix it ;-)

 Of course OpenStreetMap contains errors, just like any other source, and 
 probably more, given that most contributors are laymen and have very few 
 experience (few total edits, often just 1).

 On the other hand, we may be very fast when something changes, very 
 flexible in emergencies (think Haiti), and have interesting niche data 
 that commercial and public data providers don’t care for.

 It all depends on the local community in the end. If you have reached a 
 critical mass to have locals everywhere, it will work great and bugs will 
 wash out. Otherwise the data might get stale just like any other data. 
 Also using the data is essential to find the problems, for example the 212 
 story garage is likely fixed now ;-)

 I tend to agree with Steve A.

 Cheers Martin
 ___
 talk mailing list
 t...@openstreetmap.org <>
 https://lists.openstreetmap.org/listinfo/talk

>>>  
>>>  
>>>  
>>>  
>>>
>>  
>>  
>>  
>>  
>> ___
>> Talk-transit mailing list
>> talk-tran...@openstreetmap.org 
>> 
>> https://lists.openstreetmap.org/listinfo/talk-transit
>>
> ___
> Tagging mailing list
> tagg...@openstreetmap.org <>
> https://lists.openstreetmap.org/listinfo/tagging
>
>
>  
>  
>  
>  
>  
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Tagging] VANDALISM !

[Mateusz Konieczny via Talk-us]

Thanks to DWG for taking this action.

Aug 22, 2020, 03:35 by claysmal...@gmail.com:

> For those who aren't following, the DWG recently decided on a two-day ban for 
> the person who posted this, for the exact behavior they're exhibiting right 
> now: > https://www.openstreetmap.org/user_blocks/3850
>
> jdd 3, please take a break. You have better things to do.
>
> I look forward to when you demonstrate the ability to communicate 
> collaboratively.
>
> Best,
> Clay
>
> On Fri, Aug 21, 2020 at 6:08 PM 80hnhtv4agou--- via Talk-us <> 
> talk-us@openstreetmap.org> > wrote:
>
>> FYI;
>> https://wiki.openstreetmap.org/wiki/Vandalism
>>  
>> Purposeful removal or degradation of data that are known to be correct,
>>  
>> Deliberate adding incorrect data;
>>  
>> People who revert other people's work should expect to be able to 
>> demonstrate that the reversion was well reasoned and proportionate to the 
>> issue.
>>  
>> Not There;
>> Unverified>>  >>  >> if someone puts in 400 + >>  unverified >> tags in one 
>> edit,
>>  
>> If someone reverts, 400 + edits,  in one edit, done on good faith by others 
>> over the years to conform to there way of thinking,
>>  
>> If someone deletes, 400 + edits,  in one edit, done on good faith by others 
>> over the years to conform to there way of thinking,
>>  
>> If someone refuses to let others, edit because they have taken over that 
>> type edit, all bus stops in the same area,
>> all train stations in the same area, all boundaries in the same area.
>>  
>> Edits that do not conform to the subject wiki. 
>>  
>> if someone downloads data that will create one mulitipolygon, against all 
>> wikis
>>  
>> Also there is no wiki on unverified edits.
>>  
>>  
>> ___
>>  Talk-us mailing list
>>  >> Talk-us@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk-us
>>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[Mateusz Konieczny via Talk-us]

"It a playground with half-ass quality more than an authoritative and verified 
source of information (like e.g. Wikipedia)"

I am not sure whatever you claim that
Wikipedia is
"playground with half-ass quality" or
"authoritative and verified source of information".

Though any of this claims would demonstrate that
you are wrong and uninformed.

Like with your "deprecate name tag"
there are so many wrong things here.
OSM would benefit from better verification
tools and so on but insult-laden post
filed with misunderstandings will not
lead towards them.
22 Aug 2020, 09:32 by pang...@riseup.net:

> Hi
>
> 80hnhtv4agou--- via talk  skrev: (22 augusti 2020 
> 03:06:37 CEST)
>
> > 
> >Also there is no wiki on unverified edits.
> > 
>
> In OSM we don't yet have an established system for verification or accurate 
> machine readable references for the data to my knowledge.
>
> This means the whole database is basically just a mess of biased data that 
> one of our millions of editors thought should be included. Most objects have 
> very few revisions and we have no idea about the overall quality or 
> correctness. It a playground with half-ass quality more than an authoritative 
> and verified source of information (like e.g. Wikipedia). Building upon it 
> can lead to strange things. E.g. 
> https://www.nyteknik.se/popularteknik/mystisk-jatteskrapa-dok-upp-i-flygsimulator-6999771
>  (building:levels=212 was entered erroneously and committed to the database 
> without any kind of QA follow-up. If someone knows the osmid I would like to 
> know how long this error was present in OSM)
>
> We should really fix this and start a verification effort after implementing 
> a sane verification model.
>
> ___
> talk mailing list
> t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Anyone familiar with Rocky Mountain National Park (RMNP)?

[Mateusz Konieczny via Talk-us]

Though I am sadly unfamiliar with Rocky Mountains -
but especially given (6) you are not obligated to make
even more research.


Aug 9, 2020, 10:44 by talk-us@openstreetmap.org:

> In such case removing this names should be fine.
>
>
> Aug 8, 2020, 21:12 by miketh...@gmail.com:
>
>> I thought the names of these water bodies[0] in RMNP were suspect because:
>> 1) The names do not appear in the GNIS,
>> 2) The names do not appear on the USGS topo
>> 3) The names do not appear in the NHD  
>> 4) The names do not appear on the RMNP map that is handed out to visitors
>> 5) I have hiked past here several times but have never seen signs naming 
>> these bodies of water.
>> 6) I asked the mapper that added the names what their source was, and they 
>> said they didn't remember.
>> 7) I have several hiking books covering RMNP and none mention these water 
>> bodies using these names.
>>
>> Mike
>>
>> [0]
>> https://www.openstreetmap.org/way/429681825
>> https://www.openstreetmap.org/way/429451427
>> https://www.openstreetmap.org/way/429681824
>> https://www.openstreetmap.org/way/429681823
>> https://www.openstreetmap.org/way/429451428
>>
>>
>
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Anyone familiar with Rocky Mountain National Park (RMNP)?

[Mateusz Konieczny via Talk-us]

In such case removing this names should be fine.


Aug 8, 2020, 21:12 by miketh...@gmail.com:

> I thought the names of these water bodies[0] in RMNP were suspect because:
> 1) The names do not appear in the GNIS,
> 2) The names do not appear on the USGS topo
> 3) The names do not appear in the NHD  
> 4) The names do not appear on the RMNP map that is handed out to visitors
> 5) I have hiked past here several times but have never seen signs naming 
> these bodies of water.
> 6) I asked the mapper that added the names what their source was, and they 
> said they didn't remember.
> 7) I have several hiking books covering RMNP and none mention these water 
> bodies using these names.
>
> Mike
>
> [0]
> https://www.openstreetmap.org/way/429681825
> https://www.openstreetmap.org/way/429451427
> https://www.openstreetmap.org/way/429681824
> https://www.openstreetmap.org/way/429681823
> https://www.openstreetmap.org/way/429451428
>
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Cycleway Crossings

[Mateusz Konieczny via Talk-us]

Aug 7, 2020, 13:11 by dougpeter...@dpeters2.dyndns.org:

> I have noticed in my area where some people have been adding crossings to a 
> designated cycleway (named and signed as a bike trail). The crossings are 
> fine. It is that the crossing is then been changed to a footway. 
>
link?

>
> I have looked at the highway=cycleway wiki and not seen anything addressing 
> crossings. There was one screenshot that seemed to show intersections or 
> crossings with roads remaining as cycleways. Before I made any effort on 
> changing these back I wanted to ask if there was any other knowledge out 
> there about this.
>
is https://wiki.openstreetmap.org/wiki/Key:crossing maybe helpful?

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Marking structure as damaged or condemned

[Mateusz Konieczny via Talk-us]

Is building completely destroyed (no longer existing)?

Simply delete it or remove building tag and use demolished:building=yes / 
not:building=tag,
possibly add also note.

Deleting is fine, but others may remap it from aerial images.



Still building, just damaged, abandoned or seriously damaged?

abandoned=yes, ruins=yes, damaged=yes is a typical tagging



I am not aware about good standard tagging for ruins that appeared recently
that are no longer a building.

Aug 6, 2020, 03:11 by talk-us@openstreetmap.org:

> Tropical Storm Isaias left several homes in my neighborhood severely damaged 
> and condemned.  Is there a proper way to map these structures?
>
> Thanks,
> Eric
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Interested in importing address points in New York State

[Mateusz Konieczny via Talk-us]

Jul 20, 2020, 15:32 by o...@dead10ck.com:

> Thanks Mateusz, I actually tried to make a page, but I am encountering some 
> strange behavior from the wiki. When I try to edit or add a page, a text box 
> appears that says "confirmation code," with no other explanation. I don't get 
> an email with a confirmation code, so I have no idea what it wants.
>
Have you tried disabling adblock or adblock-like protection?

Some sort of CAPTCHa should appear on the screen (probably because it was 
scared by creation
a page with links).


> I was going to make a subpage of New York with the title of "NYS GIS 
> Clearinghouse", and include a link to it in the Potential Data sources page. 
> I'm not sure if it's possible to upload and serve arbitrary files in the 
> wiki; if so, I was going to upload that raw email file.
>
Is this email a text-only email? That I would create a page where section/text 
would quote it.

I moved page to 
https://wiki.openstreetmap.org/wiki/New_York/NYS_GIS_Clearinghouse

It is just stub, so feel free to expand it.

I have not edited Potential Data sources page
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Interested in importing address points in New York State

[Mateusz Konieczny via Talk-us]

Jul 20, 2020, 05:12 by kevin.b.ke...@gmail.com:

> On Thu, Jul 16, 2020 at 12:46 PM Mateusz Konieczny via Talk-us <> 
> talk-us@openstreetmap.org> > wrote:
>
>> Once you write this diary entry (or OSM Wiki page) please post
>> it to the mailing list!
>>
>
> Here you go:  > https://www.openstreetmap.org/user/ke9tv/diary/393684
>
>  Feel free to repost, wikify, share as appropriate!
>
For now I created tiny https://wiki.openstreetmap.org/wiki/E911_data_in_New_York
to make this easier to search. 

For start - what would be the best name for that page?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [Talk-us-newyork] Interested in importing address points in New York State

[Mateusz Konieczny via Talk-us]

Not a lawyer, but is it possible that
"use the points for any lawful purpose"
is nonanswer as a use invaloving copyright infringement would not be lawful?

Jul 18, 2020, 18:34 by o...@dead10ck.com:

> Well, it turned it to be a lot easier than I was thinking it would be! I 
> reached out to the contact listed on the Clearing House web site, using the 
> template in the wiki page, and he replied confirming that we have permission 
> to use the data. This is the text of the email exchange, and I've also 
> attached the raw .eml file.
>
> From: Winters, Frank (ITS) frank.wint...@its.ny.gov
> Date: July 17, 2020 22:30:24
> Subject: RE: Interested in importing the Address Point data from the Clearing 
> House into OpenStreetMap
> To: Skyler Hawthorne o...@dead10ck.com
> CC: Coryell, Rodger (ITS) rodger.cory...@its.ny.gov, Fargione, Craig (ITS) 
> craig.fargi...@its.ny.gov
>
> Hi Skyler, nice to hear form you. We would very much like the SAM address 
> points to be included in Open Street Map. The permitted use of the points is 
> quite simple. You may use the points for any lawful purpose. While we do our 
> best to maintain a comprehensive and accurate set of address points with our 
> limited resources we know it has shortcomings. See the metadata for the 
> liability disclaimer.
>
> We generally post quarterly updates to the data set.
>
>
> Frank Winters
> Geographic Information Officer
>
> Office of Information Technology Services
> W. Averell Harriman State Office Campus
> Bldg. 5 - Floor 1
> Albany, NY 12226
> 518.242.5036 | 518.281.9140 m | frank.wint...@its.ny.gov
>
>
> -Original Message-
> From: Skyler Hawthorne  Sent: Friday, July 17, 2020 6:30 PM
> To: Winters, Frank (ITS) 
> Subject: Interested in importing the Address Point data from the Clearing 
> House into OpenStreetMap
>
> ATTENTION: This email came from an external source. Do not open attachments 
> or click on links from unknown senders or unexpected emails.
>
> Hello Mr Winters,
>
> Thank you for your part in making the GIS data for New York State available 
> to the public through the Clearing House project!
>
> I am a contributor to the OpenStreetMap project [1], a collaborative open 
> project to create a global geodata set freely usable by anyone [2].
>
> We respect the IP rights of others and I write to ask if we can use this 
> data. There does not appear to be any explicit information about the license 
> under which the data sets in the Cleaning House web site are distributed. 
> It's unclear what the terms are for its use, and specifically whether or not 
> it is public domain, and if it is permitted to import into the OpenStreetMap 
> project and redistribute to the world under an open license.
>
> At the most simple, I would seek a statement like this:
>
> "The New York State GIS Program Office [or the relevant NYS department(s)] 
> has no objections to geodata derived in part from the GIS Clearing House data 
> sets being incorporated into the OpenStreetMap project geodata database and 
> released under a free and open license" [1]
>
> I also ask that whatever statement you are prepared to make can be made 
> public for information purposes.
>
> Below is a fact sheet. If you would like any more information, I will do my 
> best to help or can ask our project's License Working Group to get in touch 
> with you.
>
> Regards,
> Skyler Hawthorne
>
> Fact Sheet
>
> [1] The OpenStreetMap project currently has over 750,000 registered 
> contributors worldwide. Our main website is https://www.openstreetmap.org
>
> [2] We are mandated to make our geodata available in perpetuity under a free 
> and open licence. We are not allowed to use a commercial license, but 
> commercial organisations are allowed to use our data under similar terms.
>
> [3] Our data is currently published under the Open Database License 1.0, 
> https://protect2.fireeye.com/v1/url?k=76761582-2a4eb33f-7674ecb7-000babd9fa3f-f71edf933744da0d&q=1&e=391ef603-5912-439f-b6e4-b8ac749598bd&u=http%3A%2F%2Fwww.opendatacommons.org%2Flicenses%2Fodbl%2F
>
> [4] Most of our geodata is contributed by individuals. However, we are very 
> grateful when able to incorporate or derive from other geo-data datasets 
> where license terms are compatible.
>
> [5] We formally attribute all such sources at 
> https://wiki.openstreetmap.org/wiki/Attribution, using any specific wording 
> if you request. We also try to provide a link to this page with any extract 
> of data from our database. However, for reasons of practicality, we do not 
> require end-users to repeat such attribution since it runs into hundreds.
>
> [6] We also keep a public track of third party data use at 
> https://wiki.openstreetmap.org/wiki/Import/Catalogue and usually have a 
> project page for each dataset, describing how we use it and whether there are 
> any license restrictions to be aware of.
>
> [7] If you have any specific legal questions, the OpenStreetMap Foundation's 
> License Working Group can be rea

Re: [Talk-us] Interested in importing address points in New York State

[Mateusz Konieczny via Talk-us]

Once you write this diary entry (or OSM Wiki page) please post
it to the mailing list!

Jul 16, 2020, 18:15 by kevin.b.ke...@gmail.com:

> (It got fixed.)  Mateusz, do I recall that you took part
> in the reversion?
>
No, but I was working on much simpler deimport:
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_objects_that_are_not_existing_according_to_source_of_import_that_added_them

Still, it took plenty of time to do it properly and for years OSM had 
many misleading POIs because import was not done properly.

Though note that it was import from OSM prehistory (2009),
when issues related to imports were not known well.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] sweat of the brow & sui generis database rights | Re: Interested in importing address points in New York State

[Mateusz Konieczny via Talk-us]

16 Jul 2020, 16:33 by r...@technomancy.org:

> On 16/07/2020 13:35, Russell Nelson wrote:
>
>> As you say, it's just a listing of facts about the world. At most the 
>> presentation of them is copyrightable, but as Skyler noted, he's changing 
>> the presentation.
>>
>> No license needed for facts.
>>
>
> Remember, that might the law in the USA, but not in the whole world, 
> including the UK, where (lots of) the OSM servers & legal body is based, 
> which can have the  “sweat of the brow” doctrine, rather than the higher  
> “creativity” requirement. In addition, many countries (incl. EU & UK) have 
> “sui generis database rights”, which give copyright like protections to 
> collections of facts. OSM uses that legal protection.
I am not a lawyer, but I am pretty sure
that it is not relevant to the data published
by New York State (that was produced 
in US jurisdiction).

> Regardless, OSM is not a forum to explore the grey areas of international 
> copyright law. If we're not sure, we don't use it! 🙂
>
+1, but hopefully with some research we
may becone sure what is the legal situation___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Interested in importing address points in New York State

[Mateusz Konieczny via Talk-us]

Jul 16, 2020, 06:44 by o...@dead10ck.com:

> I found that NYS publishes GIS data in their "Clearing House", and one of the 
> data sets available is address points: 
> https://gis.ny.gov/gisdata/inventories/details.cfm?DSID=921
>
> I opened the data in JOSM, and they look spatially accurate, for the most 
> part (I noticed some points are off for addresses that don't have recent 
> satellite imagery available).
>
> Reading up on the import guidelines, I can see that the license is important. 
> However, I am not able to see anything that explicitly states one way or 
> another what kind of license the data sets are distributed under
>
Hello and thanks for checking before the import!
License is important, sadly it seems to not be specified anywhere. 

> , and this whether or not it is compatible with the ODBL. I wanted to ask if 
> perhaps anyone else had investigated these data sets in the past, and what 
> their findings were. If not, is the next step to email someone and ask?
>
I just looked at it and it seems that either it is not specified or I missed it.

If nobody will be able to locate that info then emailing specified contact 
would be a good next step.

Note
https://en.wikipedia.org/wiki/Copyright_status_of_works_by_subnational_governments_of_the_United_States#New_York

So unlike work of federal government it is not automatically public domain.

On the other hand, it may be unoriginal database... Still, the preferred 
version is to have an explicit
license.

> I don't have anything like an extensive plan for carrying out an import, 
> which is why I did not include the "authoritative" imports mailing list yet. 
> However, at a high level, as I am a software engineer by trade, my plan is to 
> write a script that reads the shapefiles and an .osm file dump as input, does 
> the attribute to tag transformations, and deduplicates with the existing data 
> by excluding any address points that already exist in any OSM object with 
> equivalent addr:* tags (it might also be necessary to inspect all 
> associatedStreet and street relations). It would produce an .osm as output 
> that contains nodes with just addr:* tags. This can then be opened in JOSM 
> and merged into the standard data layer. I'd probably start with a single 
> county and go from there.
>
Similar things were done already so remember to check whatever existing tools 
for
converting and conflation are good enough to use/modify rather than start from 
scratch.

> As a disclaimer, I do this in my free time, which is in short supply, so 
> progress on this would likely be slow.
>
Like OSM mapping in general.

> However, I would love if everyone could just search for any address and find 
> it.
>
+1

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)

[Mateusz Konieczny via Talk-us]

Jul 14, 2020, 13:17 by jm...@gmx.com:

> On 7/14/2020 4:53 AM, Mateusz Konieczny  via Talk-us wrote:
>
>>
>> Jul 14, 2020, 02:20 by >> jm...@gmx.com>> :
>>
>>> If there was reason to believe you needed explicit  permission to 
>>> be on
>>> that way, then access=private would be correct.
>>>
>> I am unsure what is the best way to tag "explicit permissionnot 
>> required,
>> implicit permission is required" case. (it is not a bigproblem in 
>> Poland
>> where nearly all such roads will have a gate anyway, bumpingit 
>> into access=private)
>>
>
> I'm really not sure how to interpret "Implicit permission is  required." 
> To my mind, if permission is implicit, it's not  required 
> (access=permissive) and if permission is required, it's  not implicit 
> (access=private.)
>
>
You can go if you have a valid reason, even if not explicitly invited or 
permitted 
("hello, I am a new neighbor").

You are now allowed if you have no valid reason ("I used this road to make 
shortcut" or
"hello, I am a creepy stalker" or "hello, I am an onbnoxious peddler")
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] access=private on driveways (was: Deleting tiger:reviewed=no/addr:street for routes)

[Mateusz Konieczny via Talk-us]

Jul 14, 2020, 02:20 by jm...@gmx.com:

> On 7/13/2020 4:09 PM, Matthew Woehlke wrote:
>
>> On 13/07/2020 15.16, Kevin Kenny wrote:
>>
>>>
>>> The immediate curtilage of a house is presumed to be private; at least
>>> in the US, one does not drive or walk directly up to someone's house
>>> without having business there. (Someone making a delivery, obviously,
>>> has business there.)
>>>
>>
>> ...this seems to be the definition of access=destination?
>>
>
> I'd say yes, that access=destination is closest to how I interpret most
> driveways: you can walk/drive along the driveway if you have a good
> reason, eg to make a delivery or an inquiry.
>
access=destination mean "no transit", not "with valid reason".

access=destination on driveway means "cannot be used by transit",
not "can be used if owner presumably agrees".

access=destination has the same meaning as access=yes on ways
that are not usable for transit (for example driveway attached to 
a single road on one end and leading into house)

> If there was reason to believe you needed explicit permission to be on
> that way, then access=private would be correct.
>
I am unsure what is the best way to tag "explicit permission not required,
implicit permission is required" case. (it is not a big problem in Poland
where nearly all such roads will have a gate anyway, bumping it 
into access=private)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Importing data for Prince William County, VA

[Mateusz Konieczny via Talk-us]

Jul 13, 2020, 20:29 by mwoehlke.fl...@gmail.com:

> On 13/07/2020 14.22, Mateusz Konieczny wrote:
>
>> If you are staying from manually reviewing
>> and editing based on this new data,
>> aerials and current data it should be
>> perfectly fine as long as you actually review
>> what you add.
>>
>
> For now, yes. For buildings (later, and I'll probably ping y'all again), I 
> expect that to be more automated, but probably still manually reviewed.
>
> It is still required to use a separate account for manually audited changes?
>
Is it going to be "by comparing dataset X and OSM I found places to map roads 
that I added
using aerial images"? Or more of "manually copied and verified geometries from 
external dataset"?

I would say that for second case I would create an import page on wiki and so 
on,
including a separate user while for first just post on relevant mailing lists.

For "more automated" buildings you definitely need separate account, Wiki page 
documentation
etc.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Importing data for Prince William County, VA

[Mateusz Konieczny via Talk-us]

Ok, then it should be ok.

If you are staying from manually reviewing
and editing based on this new data,
aerials and current data it should be
perfectly fine as long as you actually review 
what you add.

13 Jul 2020, 20:15 by mwoehlke.fl...@gmail.com:

> On 13/07/2020 13.44, Mateusz Konieczny via Talk-us wrote:
>
>> Are you sure that it is in public domain?
>>
>
> It is according to the government POC.
>
> https://lists.openstreetmap.org/pipermail/imports-us/2020-July/000954.html
>
> -- 
> Matthew
>___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Importing data for Prince William County, VA

[Mateusz Konieczny via Talk-us]

Are you sure that it is in public domain?

Is it work of federal government?
Or a state government?

13 Jul 2020, 16:48 by mwoehlke.fl...@gmail.com:

> (Repost to talk-us also.)
>
> On 13/07/2020 10.44, Matthew Woehlke wrote:
>
>> I am working on a project that wishes to tentatively use OSM data from 
>> Quantico and possibly surrounding areas. Unfortunately, OSM is somewhat 
>> lacking in this area, especially within Quantico itself.
>>
>> I would like to import data from information provided by the county¹. To 
>> start with, I would like to use the country-provided roads to improve road 
>> shapes and fill in missing roads (for now, manually, probably using 
>> Merkaartor, and checked against available aerial imagery). Eventually, I 
>> want to add buildings and maybe anything else that seems useful.
>>
>> Being data generated by an agency of the US government, the source data is 
>> Public Domain (verified via the contact information provided on the site).
>>
>> Comments/concerns/objections/suggestions?
>>
>> (¹ https://gisdata-pwcgov.opendata.arcgis.com/)
>>
>
>
> -- 
> Matthew
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Is summit register something that is often found in USA mountains?

[Mateusz Konieczny via Talk-us]

Is summit register something that is often found in USA mountains?

("A summit book or summit register is a record of visitors to the summit
of a mountain. It is usually enclosed in a weatherproof, animalproof metal 
canister.")

I am asking as I plan to implement summit register part of 
https://github.com/westnordost/StreetComplete/issues/561 and I wonder
whatever it makes sense to ask this question in USA.

So far this kind of object is not mapped at all in USA ( 
https://taginfo.openstreetmap.org/keys/summit%3Aregister#map )
but https://en.wikipedia.org/wiki/Summit_register claims
"The Sierra Club places official registers on many mountains
throughout California and the United States." (with quite weak source)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] nhd pages documentation review

[Mateusz Konieczny via Talk-us]

I edited also 
https://wiki.openstreetmap.org/wiki/Key:stream 
and created https://wiki.openstreetmap.org/wiki/Tag:stream%3Dintermittent 
(describing this imported tag as clearly deprecated).

Review whatever my interpretation of situation is correct is welcomed.

Jun 14, 2020, 22:20 by matkoni...@tutanota.com:

> I created 
> https://wiki.openstreetmap.org/wiki/Key:nhd:fcode
> https://wiki.openstreetmap.org/wiki/Key:nhd:ftype
> https://wiki.openstreetmap.org/wiki/Key:nhd:reach_code
> https://wiki.openstreetmap.org/wiki/Key:nhd:com_id>  
> about tags added in imports. 
>
> Review is welcomed, especially the first two where I described tags 
> with over 250 000 uses as pointless and unwanted.
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] nhd pages documentation review

[Mateusz Konieczny via Talk-us]

I created 
https://wiki.openstreetmap.org/wiki/Key:nhd:fcode
https://wiki.openstreetmap.org/wiki/Key:nhd:ftype
https://wiki.openstreetmap.org/wiki/Key:nhd:reach_code
https://wiki.openstreetmap.org/wiki/Key:nhd:com_id 
about tags added in imports. 

Review is welcomed, especially the first two where I described tags 
with over 250 000 uses as pointless and unwanted.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [OSM-talk] Google earth, Google maps

[Mateusz Konieczny via Talk-us]

If you were not copying Google Maps then why you were using the ruler?

Why using ruler on Google Maps would be even necessary?

Jun 13, 2020, 17:31 by t...@openstreetmap.org:

> i put them as a source i used a ruler on there map.
>
>  
>
>> Saturday, June 13, 2020 10:20 AM -05:00 from Mateusz Konieczny via talk 
>> :
>>  
>>  
>>  
>>  
>> Jun 13, 2020, 16:59 by eric.lad...@gmail.com:
>>
>>> Yeah, be careful with Google Maps.  It's owned and created by a company and 
>>> if you copy from it and they can prove it, they could sue the OSM 
>>> Foundation into oblivion.  They used to even have their OWN satellites to 
>>> obtain imagery.  That's serious money.
>>>
>> That is not the main problem. Main problem is that it goes our own 
>> fundamental rules.
>> Mappers must not use other maps* even if whoever hold copyright is unable to 
>> sue for some reason.
>>  
>> And "they can prove it" part may be misleading - you are not allowed to copy 
>> even if you think that
>> you can hide the copying so that noone will notice it.
>>  
>> *that is more complicated, we are must not copyrighted data on incompatible 
>> licenes -
>> but if you are unsure what it means do not use other maps and ask for help 
>> before doing this
>>
>>>  
>>> Typically, with local edits, I put "Local knowledge" as the source.  Sounds 
>>> more highbrow than "my eyeballs". 
>>>
>> I usually put survey/memory depending on how recent my data is.
>>
>>> IMO, if somebody is challenging one of your local edits, if they are not 
>>> local also, they should be told as much and sent on their way - UNLESS it's 
>>> something that relates to a mapping standard or best practice.  Then, learn 
>>> from your mistakes and move on.
>>>
>> +1
>>
>>> On Sat, Jun 13, 2020 at 9:32 AM 80hnhtv4agou--- via Talk-us <>>> 
>>> talk-us@openstreetmap.org >>> > wrote:
>>>
>>>> this was a tool on the map that measured distance.
>>>>
>> Have you copied that map? I am unsure how the distance measuring tool
>> relates to "why are you telling me I can not use google as a map source"?
>>
>>>>  
>>>>
>>>>> Saturday, June 13, 2020 9:29 AM -05:00 from Mateusz Konieczny via Talk-us 
>>>>> <>>>>> talk-us@openstreetmap.org >>>>> >:
>>>>>  
>>>>> You are not allowed to use Google Maps as source.
>>>>>  
>>>>> Have you used Google Maps to edit OSM?
>>>>>  
>>>>> "since all the maps on OSM are old news like in my local area 7 months 
>>>>> old."
>>>>>  
>>>>> FYI, world is larger than your local area.
>>>>>  
>>>>>  
>>>>> Jun 13, 2020, 16:08 by >>>>> talk-us@openstreetmap.org 
>>>>> >>>>> :
>>>>>
>>>>>> If you people want me to prove my edit by adding a source, and a person 
>>>>>> from the data group as an editor,
>>>>>>  
>>>>>> asks me to prove it, and i redo my edit and he does not get back to me, 
>>>>>> why are you telling me I can not use
>>>>>>  
>>>>>> google as a map source, since all the maps on OSM are old news. like in 
>>>>>> my local area 7 months old.
>>>>>>  
>>>>>>  
>>>>>>
>>>>>  
>>>>> ___
>>>>> Talk-us mailing list
>>>>> Talk-us@openstreetmap.org <http:///compose?To=talk%2...@openstreetmap.org>
>>>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>>>
>>>>  
>>>>  
>>>>  
>>>>  
>>>> ___
>>>> Talk-us mailing list
>>>> Talk-us@openstreetmap.org 
>>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>>
>>>  
>>>  
>>> --
>>> Eric Ladner
>>>
>>  
>> ___
>> talk mailing list
>> t...@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk
>>
>  
>  
>  
>  
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Google earth, Google maps

[Mateusz Konieczny via Talk-us]

Jun 13, 2020, 16:59 by eric.lad...@gmail.com:

> Yeah, be careful with Google Maps.  It's owned and created by a company and 
> if you copy from it and they can prove it, they could sue the OSM Foundation 
> into oblivion.  They used to even have their OWN satellites to obtain 
> imagery.  That's serious money.
>
That is not the main problem. Main problem is that it goes our own fundamental 
rules.
Mappers must not use other maps* even if whoever hold copyright is unable to 
sue for some reason.

And "they can prove it" part may be misleading - you are not allowed to copy 
even if you think that
you can hide the copying so that noone will notice it.

*that is more complicated, we are must not copyrighted data on incompatible 
licenes -
but if you are unsure what it means do not use other maps and ask for help 
before doing this

>
> Typically, with local edits, I put "Local knowledge" as the source.  Sounds 
> more highbrow than "my eyeballs". 
>
I usually put survey/memory depending on how recent my data is.

>  IMO, if somebody is challenging one of your local edits, if they are not 
> local also, they should be told as much and sent on their way - UNLESS it's 
> something that relates to a mapping standard or best practice.  Then, learn 
> from your mistakes and move on.
>
+1

> On Sat, Jun 13, 2020 at 9:32 AM 80hnhtv4agou--- via Talk-us <> 
> talk-us@openstreetmap.org> > wrote:
>
>> this was a tool on the map that measured distance.
>>
Have you copied that map? I am unsure how the distance measuring tool
relates to "why are you telling me I can not use google as a map source"?
>>  
>>
>>> Saturday, June 13, 2020 9:29 AM -05:00 from Mateusz Konieczny via Talk-us 
>>> <>>> talk-us@openstreetmap.org>>> >:
>>>  
>>> You are not allowed to use Google Maps as source.
>>>  
>>> Have you used Google Maps to edit OSM?
>>>  
>>> "since all the maps on OSM are old news like in my local area 7 months old."
>>>  
>>> FYI, world is larger than your local area.
>>>  
>>>  
>>> Jun 13, 2020, 16:08 by >>> talk-us@openstreetmap.org>>> :
>>>
>>>> If you people want me to prove my edit by adding a source, and a person 
>>>> from the data group as an editor,
>>>>  
>>>> asks me to prove it, and i redo my edit and he does not get back to me, 
>>>> why are you telling me I can not use
>>>>  
>>>> google as a map source, since all the maps on OSM are old news. like in my 
>>>> local area 7 months old.
>>>>  
>>>>  
>>>>
>>>  
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org <http:///compose?To=talk%2...@openstreetmap.org>
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>  
>>  
>>  
>>  
>> ___
>>  Talk-us mailing list
>>  >> Talk-us@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
>
> -- 
> Eric Ladner
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Google earth, Google maps

[Mateusz Konieczny via Talk-us]

You are not allowed to use Google Maps as source.

Have you used Google Maps to edit OSM?

"since all the maps on OSM are old news like in my local area 7 months old."

FYI, world is larger than your local area.


Jun 13, 2020, 16:08 by talk-us@openstreetmap.org:

> If you people want me to prove my edit by adding a source, and a person from 
> the data group as an editor,
>  
> asks me to prove it, and i redo my edit and he does not get back to me, why 
> are you telling me I can not use
>  
> google as a map source, since all the maps on OSM are old news. like in my 
> local area 7 months old.
>  
>  
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [OSM-talk] Edit Attacks

[Mateusz Konieczny via Talk-us]

I am not a native speaker, but as far as I know "freak" is pejorative and quite 
strong 
slur.

If I am right and it has strong negative associations - please do not use it on 
mailing lists
or elsewhere in OSM.

Jun 10, 2020, 23:41 by talk-us@openstreetmap.org:

> this is a good one because i had a back and forth discussion with somebody 
> that was 
> calling me out on my edit because from space this looked like a flat surface 
> and then explaned
> how to list it as non active.
>  
> https://www.openstreetmap.org/way/802256628#map=16/42.1110/-87.8160
>  
> but the thing is the river was a 10 year old 81 mile download that maye 
> should not be as to the Wiki.
> and this guy must be a river freak just like the bus stop guy who thought he 
> own the map.
>  
>
>> Wednesday, June 10, 2020 2:26 PM -05:00 from Mateusz Konieczny via talk 
>> :
>>  
>> Can you link any specific changeset damaging data
>> or object that was deleted and should not be?
>>  
>> Linked ones
>> http://nrenner.github.io/achavi/?changeset=86230442
>> http://nrenner.github.io/achavi/?changeset=85357849
>> appear to not be problematic
>>  
>> ( >> https://www.openstreetmap.org/relation/233949#map=9/41.8982/-87.7286
>> is on boundary of unreasonably large relation, but it is not
>> something very problematic)
>>  
>> Jun 10, 2020, 15:27 by talk-us@openstreetmap.org:
>>
>>>     Last week I edited a 10 year old, 81 mile>>>  MultiPolygon with GHOSTS 
>>> in the ID editor, all I know, Someone
>>>  
>>> took offence to that,  >>> 
>>> https://www.openstreetmap.org/changeset/85357849#map=13/42.0813/-87.8854
>>>  
>>> and attacked all my edits of that day, and as he moved from north to south, 
>>> every thing I did for the
>>>  
>>> last year.   >>> https://www.openstreetmap.org/changeset/86230442>>>  , 
>>> with things other people had already
>>>  
>>> called me on, (discussion). so >>>  >>> exposing>>>  my self everything I 
>>> have done in the last 24 hours is under question
>>>  
>>> from people who are not local but in Europe. even my visit to the golf 
>>> course is in question a 7 year stale edit.
>>>  
>>>  
>>>  
>>>
>>  
>> ___
>> talk mailing list
>> t...@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk
>>
>  
>  
>  
>  
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Edit Attacks

[Mateusz Konieczny via Talk-us]

Can you link any specific changeset damaging data
or object that was deleted and should not be?

Linked ones 
http://nrenner.github.io/achavi/?changeset=86230442
http://nrenner.github.io/achavi/?changeset=85357849
appear to not be problematic

( https://www.openstreetmap.org/relation/233949#map=9/41.8982/-87.7286 
is on boundary of unreasonably large relation, but it is not
something very problematic)
 
Jun 10, 2020, 15:27 by talk-us@openstreetmap.org:

>     Last week I edited a 10 year old, 81 mile>  MultiPolygon with GHOSTS in 
> the ID editor, all I know, Someone
>  
> took offence to that,  > 
> https://www.openstreetmap.org/changeset/85357849#map=13/42.0813/-87.8854
>  
> and attacked all my edits of that day, and as he moved from north to south, 
> every thing I did for the
>  
> last year.   > https://www.openstreetmap.org/changeset/86230442>  , with 
> things other people had already
>  
> called me on, (discussion). so >  > exposing>  my self everything I have done 
> in the last 24 hours is under question
>  
> from people who are not local but in Europe. even my visit to the golf course 
> is in question a 7 year stale edit.
>  
>  
>  
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [OSM-talk] fake mapping

[Mateusz Konieczny via Talk-us]

Jun 9, 2020, 00:26 by t...@openstreetmap.org:

> just to be safe i went to a pre-edit location, less than 5 miles 2 hours by 
> public transportation.
>  
> the satellite view was wrong, the river area were ponds because of the dam, 
> which was not there in 1969
>  
> when we went down the river in cement tubs, and the golf cart paths were all 
> marked unmaintained track road.
>  
> there are pologons around the greens, holes and fairways not the whole 
> property, where natural woods
>  
> that have separate pologons.  
>  
> the point is there is to much there to fix.  
>
Yes, in many cases map should be updated. If aerial images are wrong it is 
useful to add
something like
note=edited based on survey, as of 2020 Bing aerial imagery is outdated and 
wrong

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] [OSM-talk] river - stream

[Mateusz Konieczny via Talk-us]

Jun 5, 2020, 14:45 by t...@openstreetmap.org:

> if water goes under a bridge, why in the ID  editor is it pictured on top of 
> the bridge,
>
Is layer tag set correctly?

>  
> when the river stream comes to the bridge can you split and add tunnel ?   
>  
>
No, if it is under bridge then mapping it as a tunnel (culvert) is incorrect.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Mateusz Konieczny via Talk-us]

Jun 3, 2020, 06:09 by stevea...@softworkers.com:

> Mateusz Konieczny writes:
> "OSM is not a place to map property rights.  And landuse=residential is 
> certainly not a tool for mapping boundaries of owned areas or property right 
> boundaries."
>
> I don't wish to start an argument, and I ask with all the politeness I can 
> muster, but Mateusz, how can you be so sure?  Quoting our wiki, "land 
> use...describes what an area of land is used for e.g. housing..., etc."  On 
> the land that property owners own, and live on, can you truly say they are 
> not "using the entirety of their land for residential purposes?"  Of course, 
> some of that might have a house or apartment building, but the rest of it, is 
> that land not also residential?
>
Depends on a case. If you have a tree-covered area next to house, then it is 
likely a landuse=residential
and it likely terminates where your owned area terminates.

But if you have 2000 acres of forest, wetland and whatever else - with your 
house there, it
does not mean that the entire area becomes landuse=residential.

I agree that landuse=residential often matches property area (as people 
typically use
their entire property).

But I would strongly against matching residential areas to property boundaries.

And I am strongly opposed to basing OSM mapping on people who think that
landuse=residential mapped in OSM defines their owned property and affects
their legal rights.

>   "the remainder of land which is used for residential purposes which does 
> not strictly contain the footprint of a building (hut, apartment, tent, 
> hogan, mud daub dwelling)?"  Something other than residential?  It is 
> residential!
>
Yes, this is residential. But I have seen cases (and though that you are 
talking about it) of people
tagging private forest/wetland/whatever as landuse=residential till their 
property boundary

For example things like
https://commons.wikimedia.org/wiki/File:Lush_undergrowth_Bj%C3%B6rnlandet_national_park.jpg
https://commons.wikimedia.org/wiki/File:Lawthorn_wetland,_Irvine,_North_Ayrshire.jpg
were marked as landuse=residential solely because were on the same legal area 
as a house,
despite not used for residential purpose in any way (except some 
sightseeing/walking,
like it happens with any other forest).

For example, area should not be marked as landuse=industrial just because 
someone
has legal rights to drill for oil there or legal rights to build factory there.

It also is not landuse=industrial if it is forest next to currently operating 
factory, with a planned
construction there.

Only once a construction starts it can be marked as a  landuse=construction and
later once the factory is actually there it will be a landuse=industrial
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Mateusz Konieczny via Talk-us]

Jun 2, 2020, 20:16 by stevea...@softworkers.com:

> "this IS residential landuse."  (Not COULD BE, but IS).  Yes, this land might 
> be "natural" now, including being "treed," but I could still build a patio 
> and bbq there after perhaps cutting down some trees, it is my residential 
> land and I am allowed to do that, meaning it has residential use, even if it 
> is "unimproved" presently.  
>
It is a residential property, not a residential landuse.

> These facts do add to the difficulty:  OSM doesn't wish to appear to be 
> removing property rights from residential landowners (by diminishing 
> landuse=residential areas)
>
Are there people somehow believing that edits in OSM affect property rights and 
may remove them?
That is ridiculous.

>  but at the same time, significant portions of these areas do remain in a 
> natural state, while distinctly and presently "having" residential landuse.  
>
For me and in my region (Poland) it would be treated as a clearly incorrect 
mapping.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Mateusz Konieczny via Talk-us]

Jun 2, 2020, 22:32 by stevea...@softworkers.com:

> On Jun 2, 2020, at 1:25 PM, Joseph Eisenberg  
> wrote:
>
>> >  should the entirety of the underlying area be tagged landuse=farmland or 
>> > landuse=residential?
>>
>> Neither: just tag the areas that are used for residences as 
>> landuse=residential, and the area used for farming (mostly crops) as 
>> landuse=farmland.
>>
>
> I can certainly appreciate how this is an easy suggestion from the author of 
> a renderer, but it diminishes from our map the extent of property rights of 
> the owner of the residence / farmland.
>
OSM is not a place to map property rights.

And landuse=residential is certainly not a tool for mapping boundaries of owned 
areas or
property right boundaries.

> In OpenStreetMap we want to map what is actually there, not the zoning or 
> legal landuse or property boundaries.
>
> What is actually there are property rights, which is what I take as the 
> meaning of "landuse=residential."
>

landuse=residential is an area of land dedicated to, or having predominantly 
residential buildings

such as houses or apartment buildings.

In many cases (properties for solely residential use) it coincides with areas 
owned by people
owning a house.

But it is not always true, if you have a property with forest/farmland - then 
part of your property will be
landuse=residential and part of it will be landuse=farmland (or =forest or 
=industrial or =construction
or something else in other cases).

In some cases, especially with tree-covered areas part of area may be covered 
by two such areas.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Mateusz Konieczny via Talk-us]

Jun 2, 2020, 13:11 by g...@lexort.com:

> First, I'm going to assume that polygons for landuse=residential do or
> are intended to align with property boundaries.
>
I think that it is not a good assumption. One may have a property boundary
that is partially landuse=residential and partially landuse=industrial/farmland


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Stay-Healthy Streets in Seattle do not appear to be Living Streets

[Mateusz Konieczny via Talk-us]

May 31, 2020, 22:50 by joseph.eisenb...@gmail.com:

> Some mappers have suggested using highway=living_street for streets in 
> Seattle (and perhaps elsewhere) which temporarily have through-traffic 
> restricted for motor vehicles. However, this appears to be incorrect usage of 
> the tag.
>
For what is worth, for me primary meaning of highway=living_street is that 
pedestrian have legal
priority over vehicles and are allowed to use entire street, while motor 
vehicles
are still generally allowed.

So pedestrian may walk in any way and vehicles are obligated to yield to any 
and 
all pedestrians.

>
> According to the announcement by SDOT, the streets in the Stay-Healthy 
> Streets program have a speed limit of 32 kph (20 mph), much higher than the 
> maximum for a Living Street (20 kmh to "walking speed"). It appears that the 
> legal change is that these streets are now motor_vehicle=destination, with 
> through-traffic prohibited, but they are not Living Streets according to the 
> description in this page or at Wikipedia: 
>
Is there any other change? Because "no transit for motor vehicles, 32 km/h 
speed limit"
is well tagged with motor_vehicle=destination and maxspeed, not 
highway=living_street

And how temporary this is? 5 days? 2 weeks? 2 months? Nobody knows?

If just for 5 days I am dubious about tagging this at all.

> The streets in Seattle have street parking along their whole lengths, and 
> there are no design changes compared to other highway=residential streets in 
> the city, except for signage / paint. 
>
In Poland we use that for roads signed with
https://pl.wikipedia.org/wiki/Strefa_zamieszkania#/media/Plik:Znak_D-40.svg
that has a legal meaning, even if street is designed like any other 
highway=living_street,
and street designed like living street without it would not be marked as 
highway=living_street
without that sign.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Mateusz Konieczny via Talk-us]

May 28, 2020, 23:54 by stevea...@softworkers.com:

> "treed farmland" or "heavily wooded residential" prove slightly problematic 
> to OSM tagging.
>
Map tree-covered area (landuse=forest) and map farmland (landuse=farmland) or
residential (landuse=residential).

Yes, the same area may be tree covered and residential at the same time.

Yes, "tree-covered area" meaning for landuse=forest mismatches strict meanning
of bot landuse and forest.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] admin_level and COGs, MPOs, SPDs, Home Rule

[Mateusz Konieczny via Talk-us]

Note that vandalism in OSM and similar project is considered as
something that is not only damaging but also malicious and
intended to be damaging.

In cases where you consider other mapper as mistaken and
wrong, but not malicious - consider using other terms.

See https://wiki.openstreetmap.org/wiki/Vandalism

(it is not unique to OSM, see
for example 
https://en.wikipedia.org/wiki/Wikipedia:Vandalism )


May 12, 2020, 05:28 by mach...@gmail.com:

> I am just going to paste here what I wrote on Slack and I as well consider 
> removal of counties from admin_level=6 as vandalism.
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Relation disappearing from renderer

[Mateusz Konieczny via Talk-us]

May 9, 2020, 00:34 by the.spui.ni...@gmail.com:

>
> So I noticed recently that the boundary for the Black Hills National Forest 
> (> https://www.openstreetmap.org/relation/4069100 
> > ) has started disappearing 
> from the standard view, while the boundary for the Buffalo Gap National 
> Grassland, which has basically identical tags where it matters, is still 
> visible (> https://www.openstreetmap.org/relation/2834554> ). I checked that 
> the BHNF relation wasn’t broken (at least as best as I can tell; I put it in 
> manually a few years ago so it has a lot of parts), so I’m not sure what’s 
> going on.
>
>
Have you tried loading affected relation in JOSM and running validator?

(let me know if you have no idea how to do this and I will try to explain the 
process)
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Alt_names on counties

[Mateusz Konieczny]

I would use rather short_name.

But I see no valid reason for removing then.

Have you alerted this active user that you
started conversation about his/her mapping?
26 Dec 2019, 02:25 by t...@fitchfamily.org:

> I’ve noticed that a number of counties in California and Arizona have what 
> seems to be unneeded alt_name tags in their boundary relations. For example 
> Pima County, Arizona has name=“Pima County” and alt_name=“Pima”. Same for 
> Pinal County in Arizona and Riverside, Orange, Kern and Ventura counties in 
> California. But this does not seem universal as the few counties I looked at 
> in Washington state have only a name=* tag (e.g. name=“Columbia County”).
>
> I don’t see a wiki page for the standard for this in the United States. Is 
> there one I’ve missed?
>
> Assuming there is not standard for this, should there be? And what should it 
> be? (My preference is to remove an alt_name that is simply the name without 
> “County”.)
>
> For what it is worth, it looks like the alt_names for counties in Arizona and 
> California were added in 2014 by the user “revent” who is still actively 
> mapping borders around the world.
>
> Thanks!
> Tod
>___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Marking a wiki page for deletion?

[Mateusz Konieczny]

In this case redirect seems better.

Replace entire page text by 
#REDIRECT [[target page]]


You can also add delete template 
to request deletion:

{{Delete|reason for deletion}}

24 Dec 2019, 01:18 by stevea...@softworkers.com:

> I goofed in our wiki by not moving (renaming) an old page to a new one, but 
> by instead and mistakenly creating the new one from scratch.  So, the old 
> wiki page ("Tren Urbano," a subway/metro in Puerto Rico) needs to be deleted, 
> as "Puerto Rico/Railroads" encompasses / supersedes it).
>
> Is there a way for me to delete a wiki page (without special wiki privileges, 
> which I have not) or a place / method to "mark" a wiki page for deletion?
>
> Thank you in advance for any answers / action,
> SteveA
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Mateusz Konieczny]

21 Dec 2019, 15:29 by wolfg...@lyxys.ka.sub.org:

> * Mateusz Konieczny 
>
>> 21 Dec 2019, 12:00 by wolfg...@lyxys.ka.sub.org:
>>
>>> I suggest to keep the road classification consistent at least within
>>> a country and try to solve the problem of roads in low-zoom maps at
>>> the rendering level, by modifying the list of displayed road classes
>>> until a target density of displayed roads is reached. That might
>>> become easier to do when we move to vector tiles.
>>>
>> Seems not doable with OSM data - this
>> would require far more road classes
>> than we use.
>>
>
> Why would we need more road classes for that? This would only be an
> issue if the difference between two "adjacent" classes would be so big
> that you would jump from "almost none" to "to many to display" in one
> step.
>
Exactly.

There are many places where motorway 
and trunk is not enough
(as trunks are not used for roads
forming core network but for expressways).

Adding also primary roads pushes it into 
unacceptable many roads forming blobs.

>> lane and surface data is also almost
>> certainly not helpful here even with full
>> coverage
>>
>> And it would result in weird transitions
>> between countries.
>>
>
> Only if road density changes rapidly at the border, and then we would
> just depict the weird transition that exists in reality.
>
In case of using regions not matching countries
you will still have weird transitions on borders of regions.
> I think it might be possible to upgrade the "minimum zoom level to
> display" on a way if there are no already displayed ways in an area,
> maybe only if it connects to an already displayed way (recursive).
> That way we would boost the minimum zoom level of e.g.
> https://www.openstreetmap.org/way/196509120 to zoom-level 11 or maybe
> even 9, even with it being just a low quality dirt track going near an
> obscure archaeological site in the middle of nowhere.
>
I had some ideas, none managed to deal
with "weird borders somewhere".___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Mateusz Konieczny]

21 Dec 2019, 12:00 by wolfg...@lyxys.ka.sub.org:
> I suggest to keep the road classification consistent at least within
> a country and try to solve the problem of roads in low-zoom maps at
> the rendering level, by modifying the list of displayed road classes
> until a target density of displayed roads is reached. That might
> become easier to do when we move to vector tiles.
>
Seems not doable with OSM data - this
would require far more road classes
than we use.

lane and surface data is also almost
certainly not helpful here even with full
coverage

And it would result in weird transitions
between countries.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Mateusz Konieczny]

21 Dec 2019, 01:09 by joseph.eisenb...@gmail.com:

> Above it was said that the highway=trunk vs highway=primary
> distinction is mostly for routing applications. But allowing a proper
> rendering is also a main goal of the road tagging system.
>
Yes, during my work on road display in
OSM Carto I really wished for consistent
use of highway=trunk as
"The most important roads on national
level, but not motorways".

I encountered some definitions of highway=trunk
describing this type of user,
but it is sadly not universally followed.

I think it would be desirable to use it this way,
rather than for tagging of "high performance
roads below motorway quality".
> While it's true that road class is useful for routing when there are
> two alterate routes, a main reason to tag highways with a certain
> class is to be able to render maps properly at different zoom levels.
>
> When you are making a high-scale, low-zoom-level map of a large area
> (say, the whole State of Alaska, all of England, or all of Australia),
> you will want to only render highway=motorway + highway=trunk, because
> showing all highway=primary would lead to rendering many smaller roads
> which are not reasonable to show at that scale in most places.
>
+1___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

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

[Mateusz Konieczny]

21 Dec 2019, 01:44 by ba...@ursamundi.org:

>
>
> On Fri, Dec 20, 2019 at 1:07 AM Mateusz Konieczny <> matkoni...@tutanota.com> 
> > wrote:
>
>>
>> 20 Dec 2019, 01:25 by >> ba...@ursamundi.org>> :
>>
>>> So, for example, in the US, instead of motorway, trunk, primary, secondary, 
>>> tertiary, perhaps something more like freeway, expressway, 
>>> major/minor_principal (just having this would fix a *lot* of problems with 
>>> Texas and Missouri and their extensive secondary systems), 
>>> major/minor_collector...the US just has a way more complex view of how 
>>> highways work.  
>>>
>>> Or at least some more serious consideration given to the proposal at >>> 
>>> https://wiki.openstreetmap.org/wiki/User:UltimateRiff/HFCS>>>  (but perhaps 
>>> with "other principal arterials" as primary and a new "highway=quartinary".
>>>
>> Fitting thing like road classification
>> into UK system is irritating at times.
>>
>> But idea of each country with separate tags
>> for roads is simply a bad idea.
>>
>
> Could you expand on this?  Being able to speak each country's highway lingua 
> franca would make it a lot easier for OSM to become the Rosetta Stone of maps 
> simply from ease of classification.
>
I am consider it unlikely that it would make
anything easier.

Current solution is not ideal butfollowing each local and incompatible 
classification scheme instead seems to not be better.

I am 100% OK with tagging official road 
status somehow - US expressway,
US highway route, Polish droga wojewódzka,
Polish droga gminna and so on.

But as a new (maybe already existing)
tag.
But do not expect 1:1 mapping to highway tag value.
>  
>
>>
>> This info is probably worth recording,
>> but legal status should go into a separate tag.
>>
>
> Legal status of roads in the US isn't quite as clearcut as it is in the UK, 
> where the highway=* tag is literally equal to that country's legal 
> classification, plus private roads with significant public passage and/or 
> reach.  Off the top of my head we have 1 country, 2 states, 34 tribes, 77 
> counties and 597 towns, plus MacQuarie Group Australia running the turnpikes 
> and the Boy Scouts of America, Phillips 66, ConocoPhillips, or some 
> combination of the three, and potentially scores more private entities, 
> operating extensive networks of publicly accessible roads and highways in 
> Oklahoma.  And I generally consider myself lucky I have it > this>  
> straightforward in the US.
>
> Texas likely has similar situations but throw in the fact that they have 7 
> different state highway systems before you get into at least 3 more 
> (regional? state? private? unclear...) competing turnpike networks, sometimes 
> running side by side on the same right of way (consider TX 121 with the 
> George Bush Turnpike operated by the North Texas Transportation Agency 
> running down the median).
>
> Simply starting with the HFCS and expanding from that (particularly on the 
> freeway/expressway distinction, and having more levels between secondary and 
> unclassified) would be a fantastic boon to dealing with this mess in a more 
> concise fashion as it changes highway=* tagging from almost entirely 
> subjective to subjective but within a limited range.  Establish wiki pages 
> describing how each region works and let the consumers sort it out from there.
>
> At an absolute minimum, we really need to establish values lower than 
> tertiary yet above unclassified, and we definitely do need to make the 
> freeway/expressway distinction.
>
I consider any plan that would add new
highway values to be unlikely to succeed.

Consider introducing new tags instead.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Trunk VS primary,

[Mateusz Konieczny]

20 Dec 2019, 01:25 by ba...@ursamundi.org:

> So, for example, in the US, instead of motorway, trunk, primary, secondary, 
> tertiary, perhaps something more like freeway, expressway, 
> major/minor_principal (just having this would fix a *lot* of problems with 
> Texas and Missouri and their extensive secondary systems), 
> major/minor_collector...the US just has a way more complex view of how 
> highways work.  
>
> Or at least some more serious consideration given to the proposal at > 
> https://wiki.openstreetmap.org/wiki/User:UltimateRiff/HFCS>  (but perhaps 
> with "other principal arterials" as primary and a new "highway=quartinary".
>
Fitting thing like road classification
into UK system is irritating at times.

But idea of each country with separate tags
for roads is simply a bad idea.

This info is probably worth recording,
but legal status should go into a separate tag.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Opinions on micro parks

[Mateusz Konieczny]

1 Oct 2019, 16:26 by frede...@remote.org:

>
> Case 1:
>
> http://www.remote.org/frederik/tmp/case1.png
>
> Two small coastal areas that look a bit like rock outcroppings.
>
It is hard to imagine to me situation where
it would be leisure=park.
> "zone=PR-PP" which was then interpreted as meaning it's somehow a
> "park".
>
Is this a typical quality of this import?
> Case 2:
>
> http://www.remote.org/frederik/tmp/case2.png
>
(...)
> One mapper says "not a park", the other mapper says that according to
> CPAD 2018a and SCCGIS v5 this is a park
>
Aerial image is useless here, it
is a tree covered area.

It may be in addition leisure=park,
it may be a dump of nuclear waste,
it may be a military polygon.

Is there a chance of on ground photo?
I am unfamiliar with CPAD 2018a and SCCGIS v5.

Is there a good reason to expect that their classification
matches OSM classification of objects?
> "It is a park in the sense of American English as of 2019. Whether it is
> a park according to OSM may be debatable, as it is an "unimproved" park,
> meaning it is under development as to improvements like restrooms and
> other amenities.
>
I would not expect restrooms to 
be indicator of leisure=park
> However, it is an "urban green space open to public
> recreation"
>
I am one of people that attempted to
improve OSM Wiki documentation
of leisure=park

Note that it (IMHO correctly) explicitly
mentions and excludes urban forests.

See Las Wolski example at
https://wiki.openstreetmap.org/wiki/Tag:leisure=park?uselang=en 


I suspect that it may be situation here.
> Case 3:
>
> http://www.remote.org/frederik/tmp/case3.png
>
> The highlighted area in the middle of the picture straddles a street and
> parts of an amenity=parking north and south of the street and seems to
> rather arbitrarily cut through the woodland at its northern edge.
>
> Mapper 1: "This isn't a park. It's just a small fenced off grassy
> area.". Mapper 2: "It is a park according to County Park as it meets the
> leisure=park definition of "area of open space for recreational use" and
> contains amenities (parking)."
>
> It is currently tagged leisure=park.
>
Is there a chance of on ground photo?

Provided data - description and arterial is unable to 
distinguish between a decorated park lot 
and a really small park.

I would give low weight to whatever it is officially considered as a county 
park 
> Mapper 1: "This park doesn't exist." Mapper 2: "It is undeveloped land
> managed by County Parks in a sort of proto park state. How would YOU map
> this?"
>
Park is not there so I would not map.

I would map tree-covered area, maybe trees,
water features and paths if present.

Again, is there a chance for on ground photo?
> I> would love to have a rule of thumb that says "if it doesn't have a name
> (or if it's not more than  sq ft) then it's not a park, it is just
> some trees" or so. 
>
See https://www.openstreetmap.org/way/490987980 

that is in my opinion will mapped as
leisure=park desire very small 

Though mapping it as a garden may also work.
> Just because an area of a few 100 sq ft is
> technically a "park" in some county GIS system, doesn't mean we have to
> call it a park in OSM,
>
+1
> and the idea that any patch of earth with three
> trees on it and two cars parked on it is a "park" because it is "open to
> the public" and "has amenities" sounds very far-fetched to me.
>
+1
> Also, mapping micro-protected areas on a rocky shore seems to be of
> limited value to me and puts a big burden on anyone who wants to verify
> that.
>
+1___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proper way to "close" a ferry route

[Mateusz Konieczny]

I would also remove route=ferry tag.

I assume here that "temporary" means
"closed for at least week or two", 
with closer closure I have doubts about
mapping it in OSM.

9 Sep 2019, 17:22 by talk-us@openstreetmap.org:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> The Ocracoke-Hatteras Village ferry[0] has been temporary closed due to 
> damage to NC-12 on Ocracoke Island.  A new route[1] has been established from 
> Hatteras Village to Ocracoke Village.  My question is, how do I show the 
> original ferry route[0] to be closed?  I added "opening_hours=off" to the 
> route but I'm not sure that will have the intended consequences.  Anyone have 
> any ideas?
>
> [0] https://www.openstreetmap.org/way/16611155/history
> [1] https://www.openstreetmap.org/way/723123847/history
>
> R,
> Eric
>
> -BEGIN PGP SIGNATURE-
> Version: ProtonMail
>
> wsFcBAEBCAAGBQJddmA6AAoJEIB2q94CS7PRQSAQAL0fSewgLtUN2Mrwbwcz
> N221knSp4oyndd1iY++UFEKD1gaHWFXgzLyqijI5znRu9iZeqN0tVMZRmnKn
> VQ0tBAXw/UsxK2owyXDu76Ii2InAnLZ8g2D5yiABKgI1XdXVb1z3tl9Onhcd
> OVk3sqPKgv5ziRudwUoc+cnqNjykb+/yRqJ/8AUufuichr7EtnvA2X9X8/rG
> qLRW+VzAsQ8kJBjDtBfPEkTh0yoKtFiE6qalvDD9NF4jha6Mf+Esi/OTqvzb
> IQ54rAN77iE9M0LK40BNRKsxsaZIDGQZW9MVFpZzKTdJ0fIaihZoNqgNntmy
> 3/7N9eeyhAUrf0QxcEpxgfybesBYMqx2HielxaS/1dwA+j4yZg+KdYW69FIw
> YPWsOxx5CaUjnWkYQX0vi1sCUWGyf3wCrMNvYaO07MMvpZCBgUPedPR0HcDT
> eVj9x79OzlAv3PPQFIyRwbDAuKVszP9LMeDPudq0ZRfZASqQQst478E73WOk
> iKFuiLauOpF7Z6maQ3JfRdwvpXDXiWcdom3QCiGb+RMVCQmR9mY6i8hV3pfF
> WzJ2WG25n8dYs+7JmbSG8m9LLDvPv+OxuOa0r+bKepMbUqjJb5IRT3Uxn0TQ
> IRB1CXPj8KfusFgLHbu6j6ZCby2BK6GdIGkWfMnHFNuAFcDP9WVpQqtVOxlj
> 4XUl
> =krMq
> -END PGP SIGNATURE-
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Oahu, Hawaii CDP boundaries

[Mateusz Konieczny]

6 Sep 2019, 22:10 by stevea...@softworkers.com:

> I slightly disagree with Mateusz that we "reflect local postal" boundaries, 
> as we don't do that in the USA with ZIP codes:  they are routing algorithms, 
> not actual areas definable by a (multi)polygon.
>
Note that I was asking whatever it is
actually administrative boundary
(Postal codes are not forming
administrative boundaries in Poland,
not sure is it different in USA)___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Next Mappy Hour July 10!

[Mateusz Konieczny]

I like this idea, I would be happy to talk about StreetComplete and Vespucci.

12 Jul 2019, 23:10 by m...@rtijn.org:

> Hi all, 
>
> Thanks for participating in the Virtual Mappy Hour this week! We had a record 
> number of 16 participants (from as far away as Poland and Japan) and lively 
> discussion on a variety of mappy topics. I enjoyed it very much and I hope 
> you did as well. 
>
> I will announce the next Mappy Hour soon. I suggest we make the next one 
> about field mapping and associated tools like StreetComplete, GoMap, 
> Vespucci, Fieldpapers etc! What do you think?
> -- 
>  Martijn van Exel
>  m...@rtijn.org
>
> On Tue, Jul 9, 2019, at 12:34, Martijn van Exel wrote:
>
>> Hi all, 
>> Final call for people who want to present a mappy topic at tomorrow's 
>> mappy hour!
>> Doesn't have to be anything too formal / prepared.. Just take 5 minutes 
>> to present what you work on / how you map / how OSM has changed your 
>> life / what you think the difference is between amenity=pub and 
>> amenity=bar / ... 
>> In any case, see you tomorrow!
>> -- 
>>  Martijn van Exel
>>  m...@rtijn.org
>>
>> On Tue, Jul 2, 2019, at 08:58, Martijn van Exel wrote:
>> > Hi all!
>> > 
>> > Here’s a reminder, Mappy Hour next Wednesday! Sending out the reminder 
>> > a little early because of the upcoming holiday weekend. Details and 
>> > sign up link in the thread below. So far we have 9 folks signed up. 
>> > Signing up is optional but you get to express your topic preferences. 
>> > So far we have a wide range:
>> > 
>> > * Tagging for data consumers
>> > * Vodka
>> > * Mapping bike routes and trails; and OSMAnd Specific considerations
>> > * A future program to qualify new mappers
>> > * Tips on how to quickly determine potentially missing/old information 
>> > of existing ways (buildings, roads, forests, etc.) 
>> > 
>> > I hope to see you there! July 10 6pm PT / 9pm ET
>> > 
>> > Martijn
>> > 
>> > -- 
>> >   Martijn van Exel
>> >   m...@rtijn.org
>> > 
>> > On Wed, Jun 26, 2019, at 16:05, Martijn van Exel wrote:
>> > > Here's a sign up link. It helps me a lot if you fill this out if you 
>> > > plan to attend. Thanks!
>> > > https://forms.gle/WktPPimyB69jGnH29
>> > > -- 
>> > >   Martijn van Exel
>> > >   m...@rtijn.org
>> > > 
>> > > On Wed, Jun 26, 2019, at 11:16, Martijn van Exel wrote:
>> > > > Hi all,
>> > > > The next OSM US Virtual Mappy Hour will be on July 10 at 6pm PT / 9pm 
>> > > > ET!
>> > > > As always the Mappy Hour is a great place to catch up with your fellow 
>> > > > mappers, and learn something new. 
>> > > > I am always looking for volunteers to do a 5 minute presentation on 
>> > > > something they are working on. This can be a personal mapping project, 
>> > > > a local mapping group update, something interesting going on at your 
>> > > > company.. As long as it's OSM related!
>> > > > See the OSM wiki for more details on how to join --> 
>> > > > https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/United_States/Virtual_Mappy_Hours
>> > > > See you then!
>> > > > -- 
>> > > >   Martijn van Exel
>> > > >   m...@rtijn.org
>> > > > 
>> > > > ___
>> > > > Talk-us mailing list
>> > > > Talk-us@openstreetmap.org
>> > > > https://lists.openstreetmap.org/listinfo/talk-us
>> > > >
>> > > 
>> > > ___
>> > > Talk-us mailing list
>> > > Talk-us@openstreetmap.org
>> > > https://lists.openstreetmap.org/listinfo/talk-us
>> > >
>> > 
>> > ___
>> > Talk-us mailing list
>> > Talk-us@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk-us
>> >
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Website showing the best time to survey with GPS.

[Mateusz Konieczny]

Note that for a typical GPS, especially GPS in smartphone I would expect that
this effects will be not really noticeable in affecting accuracy.

Maybe except massive solar storms like
https://en.wikipedia.org/wiki/Solar_storm_of_1859

I tried to check sources, but quick search found nothing really good, except 
some things
like
https://www.utdallas.edu/news/2013/5/16-23761_Solar-Flares-May-Interrupt-GPS-Navigation-Research_article-wide.html
 

"If a flare is particularly large, the resulting turbulence in our upper 
atmosphere 
could disrupt radio signals and GPS navigation, for example."

what seems to confirm that you need really unusual activity to have results.


27 Jun 2019, 00:18 by talk-us@openstreetmap.org:

> I was told there was a website that forecasted the best times to do survey 
> work with GNSS based upon diversity of satellites in the sky, solar activity, 
> etc.  Does anyone know what site this is?
>
> Thanks,
> Eric
>
>
>
>
>
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Typical maxweight signs in USA? (editor developmnent question)

[Mateusz Konieczny]

25 Jun 2019, 17:47 by pe...@dobratz.us:

> Thanks for trying to standardize on this.  I've seen a few of these maximum 
> weight signs and was unsure of how to tag.
>
> From what I've seen in the United States, I've seen maximum weights listed as 
> both lbs (pounds) and tons (where 1 ton = 2000 pounds).
>
> In Portland, Oregon, I've recently come across the following following text 
> on signs:
>
> WEIGHT
> RESTRICTED
> BRIDGE
> SINGLE AXLE TRUCKS
> 50,000 LBS MAX
> COMBINATION TRUCKS
> 80,000 LBS MAX
>
maxweight:hgv_articulated=8 lbs (?)
 = 5 lbs

> WEIGHT LIMIT REDUCED
> ANY SINGLE AXLE 20,000 LBS
> ANY TANDEM AXLE 34,000 LBS
> ANY GROSS WEIGHT 105,500 LBS
> LEGAL AXLE LOADS ONLY
>
maxweightrating=8 lbs
maxaxleload=2 lbs
but how to express tandem axle part?

I hunted down example image and uploaded to
https://commons.wikimedia.org/wiki/File:Trb2014_pooledfund_update_fig03.jpg 

https://wiki.openstreetmap.org/wiki/File:US_weight_limit_sign_%3D_single_axle,_tandem_axle,_gross_weight.png
 


and added as an example at
https://wiki.openstreetmap.org/wiki/Key:maxweightrating#maxweightrating_sign 

and
https://wiki.openstreetmap.org/wiki/Key:maxaxleload#Examples

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Typical maxweight signs in USA? (editor developmnent question)

[Mateusz Konieczny]

25 Jun 2019, 17:47 by pe...@dobratz.us:

> Reading this page, I see the potential ambiguity extends deeper than I 
> realized (short ton, metric ton, long ton)
> https://en.wikipedia.org/wiki/Tonne 
>
AFAIK all cases of "t" in USA on max weight signs means "short ton".

Taggable by adding "st" unit or by converting to pounds, and adding "lbs" unit.
First seems to be superior as puts lower burden on mappers and it allows to 
directly map what is signed.
See https://wiki.openstreetmap.org/wiki/Key:maxweight#Usage

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Typical maxweight signs in USA? (editor developmnent question)

[Mateusz Konieczny]

How often weight limit signs other than plain 
"Weight limit X tons" https://wiki.openstreetmap.org/wiki/File:MUTCD_R12-1.svg 


and

R12-5 https://wiki.openstreetmap.org/wiki/File:MUTCD_R12-5.svg 

appear?

Some of them are listed at 
https://wiki.openstreetmap.org/wiki/Key:maxweight#United_States 

but I am unsure is it case of something actually popular or rare curiosity?

-

I am asking as I work on extending StreetComplete by adding max weight quest 
for bridges 
and I want to support also USA-style weight limits.


PS StreetComplete is a bit different editor, available as an Android 
application - it allows to make 
a very limited set of edits, but all can be done by answering simple questions 
with no OSM specific
knowledge necessary.

PPS In case that somebody used StreetComplete and noticed some stupid and 
preventable behavior,
reports at https://github.com/westnordost/StreetComplete/issues 
 are welcomed (or
within this thread if someone is unable/unwilling to make a Github account)



___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] maxweight sign R12-5 - how to tag it? Is this correct? (editor development question)

[Mateusz Konieczny]

There is a bit tricky sign 
https://wiki.openstreetmap.org/wiki/File:MUTCD_R12-5.svg 


OSM Wiki at https://wiki.openstreetmap.org/wiki/Key:maxweight#Examples 
 proposes to use:
maxweight=8 st
maxweight:hgv_articulated=12 st
maxweight:hgv:conditional=16 st @ (trailer)

This seems reasonable to me, but I wanted to check is it correct.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Mateusz Konieczny]

29 Apr 2019, 17:36 by kevin.b.ke...@gmail.com:

> On Mon, Apr 29, 2019 at 11:24 AM Mateusz Konieczny
> <> matkoni...@tutanota.com <mailto:matkoni...@tutanota.com>> > wrote:
>
>> Why not simply call anything which is a 'large public area for recreation', 
>> a park, and specify it additionally with additional tags?
>>
>> That would require redefining leisure=park and while would match use of word 
>> "park" in USA
>> it would start mismatching use of work "park" in UK. It would also start to 
>> mismatch how
>> leisure=park is used in Europe.
>>
>> Generally British English is preferred in OSM and redefining popular tags is 
>> deeply problematic.
>>
>
> Are we talking about the use of the *tag*, or the use of the *word* in
> British English?
>
It is supposed to be about both, I attempted to check both but I open to 
discovering that I am mistaken.
In case of British English I attempted to consult with people who are native 
speakers of BE 
and people better in English than myself but maybe my questions/examples failed 
to capture
cases of what should be described park (and or leisure=park).

I know that it is possible, that is part of the reason why I posted quoted 
message (it would be embarassing
to discover that my claims were wrong but I prefer to discover as soon as 
possible).

> If we're talking about the use of the word 'park' in common speech,
> the British Isles have ample examples of 'park' being used in a sense
> much like the US one: > https://www.openstreetmap.org/way/359617831 
> <https://www.openstreetmap.org/way/359617831>
> happened to be the first one I noticed, but
> https://www.openstreetmap.org/way/421685070 
> <https://www.openstreetmap.org/way/421685070>>  and others are also
> present. If these aren't 'parks' in UK English, why do they exist in
> the UK with 'park' in their names?
>
Neither of them is tagged leisure=park and it seems that
"national park" is in some way similar to "business park" or "industrial park"
- word park is in the name but it is not considered as a special case
of "green human-sculpted landscape" that is commonly referred to as
a "park".

Note that I may be mistaken here, my check was quick sanity check of
a biased group of people not some scientific research

> I also notice that Great Britain has similar situations to the US
> national parks, where other land uses are embedded. I see that
> Cairngorms National Park
> https://www.openstreetmap.org/relation/1947603 
> <https://www.openstreetmap.org/relation/1947603>>  embeds at least four
> villages (Avlemore, Ballater, Grantown-on-Spey and Kingussie).
>
This one is not surprising to me, it is probably result of compromise/conflict
resulting in potected area with some objects that are contrary to any 
nature protection attempts.
Poland has cases of legal large-scale active logging in Tatra mountains 
that is result of conflict between local people and desire to protect nature.

See 
https://pl.wikipedia.org/wiki/Wsp%C3%B3lnota_Le%C5%9Bna_Uprawnionych_O%C5%9Bmiu_Wsi
 
<https://pl.wikipedia.org/wiki/Wsp%C3%B3lnota_Le%C5%9Bna_Uprawnionych_O%C5%9Bmiu_Wsi>
- conflict dates back to creation of the Tatrzański Park Narodowy (=Tatra 
National Park).

See also motorways going sometimes through protected or "protected" areas.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Mateusz Konieczny]

29 Apr 2019, 05:12 by stevea...@softworkers.com:

> How much consensus IS there for tagging national_park on "large, (important?) 
> state parks" which roughly (or not) meet the national_park definition in our 
> wiki?
>
It seems that national_park is likely to be affected by problem similar to 
leisure=park.
Many countries have things  called "national park" that are some form of nature 
protection
but details are very different.

Given that there is viable alternative that may be less ambiguous it may be 
preferable to
avoid national_park or at least be aware that meaning is likely to be strongly 
affected by regional
differences.

For example:
in Poland "national park" is basically "large/very large nature reserve that 
has stronger legal 
protections and is more famous". Some of them are tiny (probably comically tiny 
by USA standards)
like Ojcowski Park Narodowy ("Park Narodowy" directly translates into "Naional 
Park")
at https://www.openstreetmap.org/relation/6247785#map=12/50.2054/19.8272 
 - 
covering 21 square km.

I am tempted to treat boundary=protected_area as preferable, despite that tags 
specifying exact type
are unreadable codes.

(I am loudly thinking here, and not sue what exactly should be done here)

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Mateusz Konieczny]

Sorry for a previous empty message. I clicked send too early by an accident.

29 Apr 2019, 15:02 by g...@lexort.com:

> So, I'd be in favor of having a way on the parcel boundary, and another
> denoting the park-type sub-piece, calling those outer and inner and
> tagging:
>
>  outer: name="Foo State Park"
>  inner: leisure=park
>  relation wtih outer/inner: leisure=nature_reserve
>
> Or, perhaps not having a relation and putting leisure=nature_reserve on
> the outer, with the expectation that renderers/etc. will resolve the
> overapping landuse to the smaller geometry.
>
I think I would base deciding whatever leisure=nature_reserve (or 
boundary=protected_area)
should be multipolygon excluding inner or cover both should be based on a 
situation.

For example - is leisure=park area exempt from (all/nearly all) rules 
protecting remaining area?
It is probably should be multipolygon.

Is leisure=park area more intensively used but there are still some real 
restrictions? Probably
boundary=protected_area should also cover it.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Mateusz Konieczny]

29 Apr 2019, 15:02 by g...@lexort.com:

> The other case is a large area with subareas that are each clearly one
> or the other.  Consider:
>
>  1000 acre parcel, almost entirely forest in a natural state, with dirt
>  hiking paths
>
>  a 40 acre sub-piece of this on the edge, that is different:
>  - paved parking lot
>  - visitor center / bathroom building
>  - grass and a few trees (city park like)
>  - picnic tables, grills
>
>  probably there are different rules for the two pieces.  Dogs might be
>  allowed in the 40-acre chunk, but not in the larger forest, for
>  example.
>
>  the entire thing is called "Foo State Park", owned by a state
>  government.  Legally it is one parcel, and run by the same state
>  agency.
>
> I think the basic issue is that we tend to focus on the larger
> definition of area and think we must give it one tag, so we frame the
> question: "Is this 1000 acre place a =park or a =nature_reserve?".
> Stepping back, I see a park and a nature_reserve as separate and related
> things.
>
> So, I'd be in favor of having a way on the parcel boundary, and another
> denoting the park-type sub-piece, calling those outer and inner and
> tagging:
>
>  outer: name="Foo State Park"
>  inner: leisure=park
>  relation wtih outer/inner: leisure=nature_reserve
>
> Or, perhaps not having a relation and putting leisure=nature_reserve on
> the outer, with the expectation that renderers/etc. will resolve the
> overapping landuse to the smaller geometry.
>
> (As I see it this applies to many National Parks too, but we don't worry
> about that because we just call them national_park.)
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-us 
> 
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Mateusz Konieczny]

29 Apr 2019, 15:28 by bradha...@fastmail.com:

> It doesn't restrict, as the leisure:park wiki does, to smaller, urban 
> human-sculpted parks.
>
I am partially responsible for recent rewrite. The rewrite was supposed to 
explain how leisure=park
is used in OpenStreetMap, and not redefine meaning of this tag. USA is a tricky 
case as typical
use of leisure=park was not matching use of leisure=park that was intended and 
initial and
dominating in other well mapped areas.

Restricting to "human-sculpted parks" was 100% intentional, "smaller" as in 
"area covering 
hundreds square kilometers is extremely unlikely to be leisure=park" was 
intentional.

Restricting it cities was not intentional and should be fixed if it  happened, 
some leisure=parks
exist in rural areas.

> Why not simply call anything which is a 'large public area for recreation', a 
> park, and specify it additionally with additional tags?
>
That would require redefining leisure=park and while would match use of word 
"park" in USA
it would start mismatching use of work "park" in UK. It would also start to 
mismatch how
leisure=park is used in Europe.

Generally British English is preferred in OSM and redefining popular tags is 
deeply problematic.

If someone feels that leisure=park as described by me here (and partially on 
Wiki)
misrepresents situation - I would participate in some wider discussion 
on global tagging mailing list if someone would start it.

Just recently leisure=park OSM Wiki page was basically without definition and 
discussion
page had basically failed definition attempt and I hope that was is now on the 
page is an improvement
over no definition/explanation at all, but...
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Private playgrounds (was Parks in the USA, leisure=park, park:type)

[Mateusz Konieczny]

29 Apr 2019, 13:56 by g...@lexort.com:

> It does mean that leisure=playground access=private is going to happen,
> in gated community-ish places.  But that's fine, I think.
>
Or in schools/kindergartens. (leisure=playground access=private is even 
supported
by a special rendering in OSM Carto ).
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Mateusz Konieczny]

24 Apr 2019, 23:05 by kevin.b.ke...@gmail.com:

> TL;DR - Tag the land use, not the land ownership. A city, town,
> county, or state park may be virtually indistinguishable urban green
> spots, recreation grounds, nature reserves, whatever. The level of
> government that manages them may be of interest and worth tagging, but
> ought not to be the primary determinant of 'park type'.
>
I fully agree - who owns objects is not changing its type.
Especially for parks - it does not matte whatever it is owned by
government, company or a single person.

> I think that the Wiki definition leaves a lot to be desired, and I'm
> groping in a fog, much as you are, so please don't take anything that
> I say here as a confrontational pronouncement.
>
It is one of things that seems easy to define until one actually attempts to do 
it.
Further help is welcomed!

> (...)
> All of these features make for what is essentially a human landscape.
> It's one that's designed to be relaxed, focused on being a respite
> from the hurly-burly of the city, but it's still relatively densely
> developed - with many users concentrated in a relatively small area -
> and definitely human-sculpted.
>
I agree, and I really like term "human-sculpted".

> The 'type' of park ought to be "what type of experience ought the
> visitor to expect" and not "what government manages it."
>
Again, I fully agree.

> Bethpage State Park > https://www.openstreetmap.org/relation/6447778 
> >  is
> a golf course. Robert Moses State Park
> https://www.openstreetmap.org/relation/6442393 
> >  is a swimming beach. I
> see no reason to map them as anything but what they are, except to
> inform the user that they're state-owned and run by OPRHP (the Office
> of Parks, Recreation and Historic Preservation).
>
Yes, "park" in the name does not mean that it is leisure=park.

And some leisure=park may not have "park" in the name (not sure how
often it happens in USA).

We have also things called "industrial park" or "business park"
that are also not tagged leisure=park.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] What is sold in Value Village? (shop=second_hand vs shop=clothes)

[Mateusz Konieczny]

Is it a second hand shop, but what it is primarily selling?

Clothes? Or something else? Or is there no dominating product
and it is selling mix of everything?

I am asking as name-suggestion-index has it as shop=second_hand
without any indication of sold product and it seems to me that
shop=clothes + second_hand=only would be preferable tagging.

name-suggestion-index is used at least by iD and Vespucci so improving
it makes mapping a bit easier.

nsi issue: https://github.com/osmlab/name-suggestion-index/issues/2587
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] trail tagging

[Mateusz Konieczny]

Apr 19, 2019, 5:25 PM by t...@fitchdesign.com:

>  the best you could tag surface would be as “unpaved” as the natural material 
> and can vary over very short distances).
>

surface=unpaved is already helpful and useful
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] trail tagging

[Mateusz Konieczny]

tl;dr: Please, add always surface tag and other similar tags as needed.

I see that I answered at 
https://wiki.openstreetmap.org/w/index.php?title=Talk:Key:highway&diff=1844151&oldid=1843977
 


It is a tricky topic. Lets start from disclaimers:

(1) I am from Poland and unfamiliar with US local situation (though I am 
familiar with hiking)
(2) I was involved in one of highway=path controversies - see 
https://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/35389 
 
https://gist.github.com/gravitystorm/ff5a6fdc695f08de1751 
 
https://github.com/gravitystorm/openstreetmap-carto/pull/1713 


Note that highway=footway is used in multiple ways. it may be used to indicate 
(1) a paved footway
(2) way primarily for walking.

In both cases I would encourage tagging also physical characteristics - at 
least surface=*
(StreetComplete is useful here).

"Path and track indicate the physical characteristics of the way." - I would 
dispute this.
There are highway=track that are high-quality asphalt, there are ones that are 
overgrown/muddy/with deep sand. Note that tracktype=* exists. I would argue the 
same for
highway=path, though many argue that surface=unpaved may be safely assumed 
there.

"cycleway/footway/bridleway should be discouraged, and should be only used if 
that is 
the only permitted usage" - also for cases like highway=footway + bicycle=yes?

Apr 19, 2019, 4:28 PM by bradha...@fastmail.com:

> Everywhere I've been in the US or Canada a dirt 'way' too narrow fora 4 
> wheel vehicle is called a trail, path, or single track.   Forthe most 
> part they are appropriately (IMO) tagged as path.  Unfortunately the wiki 
> says this for highway:path (the highlightingis mine):
>  
>  > A non-specific path. 
> Use > highway <>> => footway 
> >  for paths 
> mainly for walkers, > highway <>> => cycleway 
> >  for one also 
> usable by cyclists, > highway <>> => bridleway 
> >  for ones 
> available to horse riders as well as walkers
> and > highway <>> => track 
> >  for  ones 
> which is passable by agriculture or similar vehicles.
>  
>  I think it makes no sense to call a dirt path, open to more than 1user 
> group, anything other than a path.    Since about 98% of thetrail tagging 
> that I've seen seems to agree, Is there consensus onthis?   Perhaps if 
> the international group likes the description asis, a clarification on 
> the US road tagging wiki page?
>  > https://wiki.openstreetmap.org/wiki/United_States_roads_tagging 
> 
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Is there any value at all in tiger:MTFCC and tiger:FUNCSTAT tags?

[Mateusz Konieczny]

Mar 25, 2019, 4:19 PM by matkoni...@tutanota.com:

> I encountered this tags some time ago and seem to be popular, imported, 
> useless
> and without clear meaning.
>
> Therefore I think it would be a good idea to add them to discardable tags 
> (tags not displayed
> by editors and silently removed if mapper edited object with it).
>
> I created documentation pages for them at
>
> https://wiki.openstreetmap.org/wiki/Key:tiger:MTFCC 
> 
> and
> https://wiki.openstreetmap.org/wiki/Key:tiger:FUNCSTAT 
> 
>
> Is anyone aware about meaning or use of this tags or supports their continued
> presence?
>
https://wiki.openstreetmap.org/wiki/Key:tiger:MTFCC 
 is now documented

Any info about meaning or use of 
https://wiki.openstreetmap.org/wiki/Key:tiger:FUNCSTAT 

would be useful.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Is there any value at all in tiger:MTFCC and tiger:FUNCSTAT tags?

[Mateusz Konieczny]

I encountered this tags some time ago and seem to be popular, imported, useless
and without clear meaning.

Therefore I think it would be a good idea to add them to discardable tags (tags 
not displayed
by editors and silently removed if mapper edited object with it).

I created documentation pages for them at

https://wiki.openstreetmap.org/wiki/Key:tiger:MTFCC 

and
https://wiki.openstreetmap.org/wiki/Key:tiger:FUNCSTAT 


Is anyone aware about meaning or use of this tags or supports their continued
presence?
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 22, 2019, 3:22 PM by m...@rtijn.org:

>> On Mar 22, 2019, at 4:08 AM, Mark Wagner <>> mark+...@carnildo.com 
>> <mailto:mark+...@carnildo.com>>> > wrote:
>>
>> On Thu, 21 Mar 2019 13:23:48 -0600
>> Martijn van Exel <>> m...@rtijn.org <mailto:m...@rtijn.org>>> > wrote:
>>
>>>> On Mar 21, 2019, at 12:35 PM, Mark Wagner <>>>> mark+...@carnildo.com 
>>>> <mailto:mark+...@carnildo.com>>>>> >
>>>> wrote:
>>>>
>>>> On Wed, 20 Mar 2019 21:46:59 -0600
>>>> Martijn van Exel <>>>> m...@rtijn.org <mailto:m...@rtijn.org>>>>>  
>>>> >>> m...@rtijn.org <mailto:m...@rtijn.org>>>>> >> wrote:
>>>>
>>>>>> On Mar 20, 2019, at 9:01 AM, Mateusz Konieczny
>>>>>> <>>>>>> matkoni...@tutanota.com <mailto:matkoni...@tutanota.com>>>>>>> > 
>>>>>> wrote:
>>>>>>
>>>>>> I plan to run an automated edit that will revert part of the GNIS
>>>>>> import that added them and delete objects that never had any
>>>>>> reason to appear in the OSM database in any form, at least
>>>>>> according to GNIS data.
>>>>>>
>>>>>> Please comment no matter what you think about this idea! I will
>>>>>> not make the edit without a clear support so please comment if
>>>>>> you think that it is a good idea and if you think that it should
>>>>>> not be done.
>>>>>>
>>>>>
>>>>>
>>>>> Thanks for bringing the idea up. It actually did come up fairly
>>>>> recently on Slack
>>>>> https://osmus.slack.com/archives/C029HV951/p1550176430103000 
>>>>> <https://osmus.slack.com/archives/C029HV951/p1550176430103000>>>>>>  
>>>>>
>>>>> My view is that we would be missing an opportunity to have mappers
>>>>> review these locations and update the areas concerned. These nodes
>>>>> exist mostly in ‘undermapped' / remote areas that could use some
>>>>> human mapper attention. So I’d be in favor of trying to resolve
>>>>> this using some human driven cleanup first.
>>>>>
>>>>
>>>> My experience is that this will mostly just make things worse.
>>>>
>>>> There was a MapRoulette task a while back for cleaning up
>>>> unmodified GNIS-imported schools.  There were only a few of them
>>>> left around me, but the most common result was that an armchair
>>>> mapper would drag the node to a nearby non-house-looking building,
>>>> trace the building, and merge it with the imported node.  Not one
>>>> of these was actually a school.
>>>>
>>>
>>> Do you think this could have been prevented had there been better
>>> instructions?
>>>
>>
>> No, I don't.  Sorting out which GNIS nodes are outdated and which are
>> merely misplaced isn't something that can reliably be done from aerial
>> imagery.  For something like "(historical)" GNIS nodes, it's better
>> just to delete all of them.
>>
>
> Short of messaging individual mappers, do you see a way in which MapRoulette 
> could be a ‘better citizen’?
> I’m thinking perhaps a way to ‘report’ challenges. (Not sure how that would 
> work though.)
>
Is there way to mark challenge as for armchair users/requiring local survey?

And show from the second group only when explicitly required?

I remember that on my attempt to use MapRoulette many were not doable without 
local survey.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 22, 2019, 9:51 AM by rich...@systemed.net:

> The other automated edits you're proposing would be better done by adding
> the keys to editor blacklists because the tags aren't actually harming
> anyone. 
>
Main harm is that
- it is one more tag that people, especially newbies need to understand (
or be confused by it)
- its presence encourages adding more tags like this or adding
is_in:continent to additional objects

I agree that it is matter of opinion is this harm significant enough to justify
automated edit, but it certainly exists.

Anyway, based on earlier comment by Frederik Ramm I just created
https://josm.openstreetmap.de/ticket/17504 

"consider is_in:continent for automatic dropping or validator warning with 
autofix removal"

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 21, 2019, 6:18 PM by kevin.b.ke...@gmail.com:

> I, too, would appreciate seeing some sample data, let's say, some
> reasonable radius around 42.8257, -73.8790.  That's more to make sure
> that the technology is working right and not wetting on stuff that's
> already fixed, but of course, I'd check to verify my tentative
> conclusion that (historic) doesn't tag anything useful.
>

I uploaded files to https://github.com/matkoniecz/objects_for_deletion 
 and linked in

https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_objects_that_are_not_existing_according_to_source_of_import_that_added_them#List_of_candidates

For now just file with all nodes in .osm file (can be opened with JOSM - File | 
Open menu).
As it is limited to nodes it works fairly well and can be browsed without 
performance issues.

I uploaded also file with objects very far away from 42, -73 deleted but it 
turned out to produce 
larger file, probably JOSM recorded deletions.

I can produce later something more user friendly if that would be useful and 
.osm files are too complicated
- let me know if that would be useful!

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 21, 2019, 6:23 PM by cliff...@snowandsnow.us:

>
>
> On Thu, Mar 21, 2019 at 9:52 AM Mateusz Konieczny <> matkoni...@tutanota.com 
> <mailto:matkoni...@tutanota.com>> > wrote:
>
>> Good idea, independent check would be welcomed!
>>
>> Something from Seattle region would be OK, right?
>>
>> If my googling went right the you are probably interested
>> in data around
>> https://www.openstreetmap.org/user/Glassman/history#map=8/47.780/-122.388 
>> <https://www.openstreetmap.org/user/Glassman/history#map=8/47.780/-122.388>
>>
>>
>
> Seattle area is fine or Skagit County to the north. Seattle would give me 
> more nodes to review which is good.
>
I uploaded files and linked in

https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_objects_that_are_not_existing_according_to_source_of_import_that_added_them#List_of_candidates

For now just file with all nodes in .osm file (can be opened with JOSM). As it 
is limited to nodes
it works fairly well and ca be browsed without performance issues.

I uploaded also file with objects very far away from Seattle deleted but it 
turned out to produce larger file,
probably JOSM recorded deletions.

I can produce later something more user friendly if that would be useful and 
.osm files are too complicated
- let me know if that would be useful!
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Good idea, independent check would be welcomed!

Something from Seattle region would be OK, right?

If my googling went right the you are probably interested
in data around
https://www.openstreetmap.org/user/Glassman/history#map=8/47.780/-122.388

Mar 21, 2019, 5:43 PM by cliff...@snowandsnow.us:

> I'm in favor of the bot but I'd like to review a sample of the data being 
> removed in my area. The purpose is to test the assumption that the data is of 
> no use.
>
> Best,
> Clifford
>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 21, 2019, 3:56 PM by m...@rtijn.org:

> Re-reading this I phrased this with more hyperbole than I intended, sorry.
>
I see no problem here, after all lack of control over automated edit is how we 
ended 
in this situation.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Gated communities

[Mateusz Konieczny]

Mar 21, 2019, 4:11 PM by kevin.b.ke...@gmail.com:

> On Thu, Mar 21, 2019 at 3:01 AM Mateusz Konieczny
> <> matkoni...@tutanota.com <mailto:matkoni...@tutanota.com>> > wrote:
>
>> For start, "residents only" gate is for me clearly access=private.
>>
>> "manned main gate" - is access strongly restricted?
>> If nearly everybody, including vehicles, is let in I would tag it access=yes.
>> It would also mean that access=destination would be better than 
>> access=private
>> for inner ways of community.
>>
>> If access is strongly filtered (entrance requires permission from resident or
>> guard is likely to resuse) then I would tag both gates access=private.
>> Though it means that these gates are again not distinguishable.
>>
>
> In practice, for the gated communities that I'm familiar with, there's
> not that significant a difference between access=destination and
> access=private at the main gate from this standpoint. If you have
> business in the community - pretty much equivalent to 'your
> destination is inside the community' - you're extremely likely to have
> the permission of a resident or business owner inside the gates.
> Nevertheless,  if you're not a resident with a key card, you're not
> going to get through the automated gates. So access=destination for
> the main gate is in theory no more permissive than access=private, but
> gives a router a strong indication that "here is the correct entrance
> for visitors."
>
> I agree that access=destination is also better than access=private for
> roads inside the gate that are usable by visitors. (access=private is
> appropriate for service ways that lead to residents-only parking and
> similar things.)
>
AFAIK access=destination is not limited to "I have permission from someone
within", it also covers things like "I want to leave promotional leaflets", or
"I want to walk around".

It is rather for "no thru traffic" / "local traffic only" than "with permission 
only".

Though I have no idea how to distinguish
"with permission only, you are likely to get it if you have a good reason"
and
"with permission only, to get it you need to be an owner of a flat"

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 21, 2019, 3:29 PM by m...@rtijn.org:

> The benefit is that it gives mappers a reason to examine places - not just 
> the disappeared feature itself but also the area around it - that would 
> otherwise go unexamined. Since we have so much unexamined space in the U.S., 
> any opportunity to spark mappers’ curiosity about some of that space, is a 
> welcome trigger. 
>
> It may feel like a time sink for some, but my hope is that others will feel 
> it’s an interesting exercise to improve the map. 
>
I think that existing issues detected by say Osmose are more than enough to 
encourage fixing stuff.

http://osmose.openstreetmap.fr/en/map/  
has massive amount of things to fix, even in well 
mapped areas.

Willing mappers are bottleneck, so whenever rare of bot-fixable
problems happens I think that it is a good idea to use it and spend human 
mapping time
on something more useful.

And if there is any danger of any area in USA running out of Maproulette or 
Osmose tasks - 
let me know and I will create something.

Especially Wikipedia-related one, as side effect of my project of finding 
tourism attractions
based on OSM data I created validator detecting various issues with wikipedia 
and wikidata tasks,
if anyone is interested I may run it for some part of USA.

> Stepping back a bit, the urge to fix previous automated edits with new 
> automated fixes is understandable, but it may lead to a more casual approach 
> to imports and automated edits, because we basically say with each fix that 
> ill-informed automated map edits can always be fixed with more automated 
> edits later. We’ve already gone down that path in the U.S. quite far, so we 
> should proceed with extra care - unless we as a community decide that that is 
> the nature of OSM in this country. It isn’t to me.
>
I fully support proper discussion before doing automatic changes, especially on 
larger scale and
ones that will delete items making them harder to reverse.

And I would be really irritated if someone would use this automatic edit 
proposal to 
support "my edit requires no discussion, after all sooner or later someone will 
fix my mess".

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 21, 2019, 1:14 PM by ethnicfoodisgr...@gmail.com:

>> Date: Thu, 21 Mar 2019 08:04:13 +0100 (CET)
>> From: Mateusz Konieczny <>> matkoni...@tutanota.com 
>> <mailto:matkoni...@tutanota.com>>> >
>> Cc: Talk Us <>> talk-us@openstreetmap.org 
>> <mailto:talk-us@openstreetmap.org>>> >
>> Subject: Re: [Talk-us] Proposed mechanical edit - remove objects that
>>  are not existing according to source of GNIS import that added them
>>
>>
>>
>> Mar 21, 2019, 4:46 AM by >> m...@rtijn.org <mailto:m...@rtijn.org>>> :
>>
>>>> On Mar 20, 2019, at 9:01 AM, Mateusz Konieczny <>> >>>> 
>>>> matkoni...@tutanota.com <mailto:matkoni...@tutanota.com>>>>>  >>> 
>>>> matkoni...@tutanota.com <mailto:matkoni...@tutanota.com>>>>> >>> > wrote:
>>>>
>>>> I plan to run an automated edit that will revert part of the GNIS
>>>> import that added them and delete objects that never had any reason to
>>>> appear in the OSM database in any form, at least according to GNIS data.
>>>>
>>>> Please comment no matter what you think about this idea! I will not
>>>> make the edit without a clear support so please comment if you think
>>>> that it is a good idea and if you think that it should not be done.>>
>>>>
>>> Thanks for bringing the idea up. It actually did come up fairly recently on 
>>> Slack > >>> https://osmus.slack.com/archives/C029HV951/p1550176430103000 
>>> <https://osmus.slack.com/archives/C029HV951/p1550176430103000>>>>  <>>> 
>>> https://osmus.slack.com/archives/C029HV951/p1550176430103000 
>>> <https://osmus.slack.com/archives/C029HV951/p1550176430103000>>>> >>
>>>
>>> My view is that we would be missing an opportunity to have mappers review 
>>> these locations and update the areas concerned. These nodes exist mostly in 
>>> ‘undermapped' / remote areas that could use some human mapper attention. So 
>>> I’d be in favor of trying to resolve this using some human driven cleanup 
>>> first.
>>>
>> What is the benefit, during survey, of mapped places that are not existing 
>> anymore?
>>
>> I encounter many during surveys (usually result of data getting outdated) 
>> and for me it was
>> always time sink (as I needed to check is it actually gone) and never useful 
>> in any way.
>>
>> Note that it is not obvious, especially for beginner or data users, that all 
>> of this places
>> are not existing anymore.
>>
>
>
> Instead of deleting the features that don't exist anymore, couldn't they be 
> moved over to OHM?
>
Moving data to OHM from OSM requires
(1) deleting data in OSM
(2) importing data to OHM

And importing GNIS to OHM would work better if it would be imported straight 
from GNIS rather
than from partial OSM data that was transformed GNIS data.

Also, I would be surprised if OHM still has no GNIS data.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Gated communities

[Mateusz Konieczny]

access=destination for inner ways for community may be also a good idea
to give data to routers that transit traffic is not allowed (or access=private
if there is limited or no public access at all).

Though routers will use that only if there is more than one gate.

As usual - additional bicycle=*, foot=*, vehicle=*, emergency=* etc may apply.

For example some gates may have access used by emergency vehicles, allowing
them to open it and go through. Though tagging it is possible in cases where it 
is
signed.

Mar 21, 2019, 4:36 AM by ba...@ursamundi.org:

> I like this answer.  Behind the gates I tend to tag as private, but giving 
> one of the barriers access=destination should be enough for that to be the 
> default answer for going in, if implemented.
>
> Not really something common in Oklahoma, usually gated communities have only 
> one way in or out that isn't an emergency access, pedestrian or bicycle only 
> gate.
>
> On Wed, Mar 20, 2019 at 7:24 PM Evan Derickson <> derickso...@gmail.com 
> > > wrote:
>
>> What about marking the resident-only gates with access=private and the guest 
>> gate as access=destination?
>>
>> On Wed, Mar 20, 2019, 16:03 Eric H. Christensen via Talk-us <>> 
>> talk-us@openstreetmap.org >> > wrote:
>>
>>> -BEGIN PGP SIGNED MESSAGE-
>>>  Hash: SHA256
>>>  
>>>  ‐‐‐ Original Message ‐‐‐
>>>  On Wednesday, March 20, 2019 6:38 PM, Frederik Ramm <>>> 
>>> frede...@remote.org  wrote:
>>>  
>>>  > Should all roads inside the gated community be access=private?
>>>  
>>>  I wouldn't necessarily mark all the roads as private as I think that would 
>>> hinder the routing engines.
>>>  
>>>  > What tags should be applied to (a) the main gate where visitors and
>>>  > delivery services are expected to report, and (b) resident-only gates?
>>>  
>>>  I've mapped a neighborhood like this before and I think I got the routing 
>>> to work properly by using gates at non-manned areas with access=private and 
>>> something else at the guard houses with access=designated or something to 
>>> that affect.  I think that fits the model...
>>>  
>>>  Eric "Sparks"
>>>  -BEGIN PGP SIGNATURE-
>>>  Version: ProtonMail
>>>  Comment: >>> https://protonmail.com 
>>>  
>>>  wsFcBAEBCAAGBQJcksYxAAoJEIB2q94CS7PREZoQALxqnyFgf57KuZ8btd9G
>>>  Rh/ttSnL2ut/P3JBddk++vM3qvxD0N6dAEQDF5X1mMYvYtwkjJ3JUm5WeFSL
>>>  MTt3teOV1KIJWb7fk8VsysJUatz3Q3Ksty9fevG1t5W2l+9tkXn6eNzMIL5c
>>>  Ztdabtgrlx/6I04IpQnPcqAjJUh48g5aQYCitfMQf3A/67/CRt0YnsYEa/79
>>>  0WmOUmtxLSDdofwOwi3g6CCma6oWiAttnrCfHLQhqbALSlM9e0+VLGICT2ma
>>>  c3eV0tzE7qvv6Xw3ngos6uVwsnJ5ppnslBax+ZDyRlc5De0ka+XAep/VWJQc
>>>  oU5Yd6gYj+7xiP+loFRLQoOR2gPSf1C/nPIVBKiD0tWgiEkPK/zHA8jA6C83
>>>  a+ZR+BNZ5LXQsSbHGn/4R5jyXBmRSRlsQ3UajVfcaDOteRKsvW2zNQUxQJn/
>>>  uzCPE6H1ZkuMjNzr2qT4/IT8TXc8Qyx+rZB/q0OiJfFa1QofNOmy9rsXkxzm
>>>  bDdcH+swBAe6eXz1snM/hYW8HDn0aba/TPYCK5+q5B3D9ynrIH9HktPVcIs9
>>>  wbt4/+qhBe4bxihA5A2vntZyrQJeHqObiMHvN8a4Zs1AiMvzEw70JAth6uYo
>>>  0oNrFCnHC3GZrEHZzyyGK/pjKlcevupEn4NIUZvWO1T6ph3rMLiAr241eSSy
>>>  xykO
>>>  =y2bt
>>>  -END PGP SIGNATURE-
>>>  
>>>  
>>>  ___
>>>  Talk-us mailing list
>>>  >>> Talk-us@openstreetmap.org 
>>>  >>> https://lists.openstreetmap.org/listinfo/talk-us 
>>> 
>>>
>> -- 
>>
>>
>> --
>>  Evan Derickson
>>  (360) 402-6494
>>
>>
>> ___
>>  Talk-us mailing list
>>  >> Talk-us@openstreetmap.org 
>>  >> https://lists.openstreetmap.org/listinfo/talk-us 
>> 
>>

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

Mar 21, 2019, 4:46 AM by m...@rtijn.org:

>
>
>> On Mar 20, 2019, at 9:01 AM, Mateusz Konieczny <>> matkoni...@tutanota.com 
>> <mailto:matkoni...@tutanota.com>>> > wrote:
>>
>> I plan to run an automated edit that will revert part of the GNIS
>> import that added them and delete objects that never had any reason to
>> appear in the OSM database in any form, at least according to GNIS data.
>>
>> Please comment no matter what you think about this idea! I will not
>> make the edit without a clear support so please comment if you think
>> that it is a good idea and if you think that it should not be done.>>  
>>
>
> Thanks for bringing the idea up. It actually did come up fairly recently on 
> Slack > https://osmus.slack.com/archives/C029HV951/p1550176430103000 
> <https://osmus.slack.com/archives/C029HV951/p1550176430103000>>  
>
> My view is that we would be missing an opportunity to have mappers review 
> these locations and update the areas concerned. These nodes exist mostly in 
> ‘undermapped' / remote areas that could use some human mapper attention. So 
> I’d be in favor of trying to resolve this using some human driven cleanup 
> first.
>
What is the benefit, during survey, of mapped places that are not existing 
anymore?

I encounter many during surveys (usually result of data getting outdated) and 
for me it was
always time sink (as I needed to check is it actually gone) and never useful in 
any way.

Note that it is not obvious, especially for beginner or data users, that all of 
this places
are not existing anymore.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Gated communities

[Mateusz Konieczny]

Mar 20, 2019, 11:38 PM by frede...@remote.org:

> Hi,
>
> DWG have been contacted by a resident of a gated community in Florida.
> They were unhappy about our routing which apparently leads people
> through an unmanned "residents only" gate where they won't get in,
> instead of to the manned main gate.
>
> I wonder how to deal with this, firstly from a "what is correct on the
> ground" perspective, but then also from a "what is useful routing-wise"
> perspective.
>
> Should all roads inside the gated community be access=private?
>
> What tags should be applied to (a) the main gate where visitors and
> delivery services are expected to report, and (b) resident-only gates?
>
> Bye
> Frederik
>
It depends on gated community.

For start, "residents only" gate is for me clearly access=private.

"manned main gate" - is access strongly restricted?
If nearly everybody, including vehicles, is let in I would tag it access=yes.
It would also mean that access=destination would be better than access=private
for inner ways of community.

If access is strongly filtered (entrance requires permission from resident or
guard is likely to resuse) then I would tag both gates access=private.
Though it means that these gates are again not distinguishable.

In Poland many gated communities are blocking only cars (to protect
limited parking space) so I tag it as
vehicle=private, bicycle=yes
as both pedestrians and cyclists are let in by guards without restriction.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Proposed mechanical edit - remove objects that are not existing according to source of GNIS import that added them

[Mateusz Konieczny]

There are thousands of objects mistakenly imported to OSM from GNIS.
Objects proposed to be deleted were documented in GNIS database as not
existing at time of the import, but were imported anyway.

Edit would remove many nonexisting objects that are currently
misleading users of OSM data and confuse mappers. There are many
amenity=post_office, amenity=place_of_worship and other mapped in USA
that in reality are not existing. There are also thousands of object
retagged to hide them in standard rendering but this entries also
should be deleted as unwanted and usually incorrect (for example
abandoned:amenity=post_office).  

Some of them are present for a decade or more like for example
https://www.openstreetmap.org/node/357118918/history

Examples of other objects that would be deleted:
https://www.openstreetmap.org/node/358721524#map=16/33.1701/-83.2385
[https://www.openstreetmap.org/node/359023261
https://www.openstreetmap.org/node/359290731/#map=15/41.6947/-72.6189


I plan to run an automated edit that will revert part of the GNIS
import that added them and delete objects that never had any reason to
appear in the OSM database in any form, at least according to GNIS data.

Please comment no matter what you think about this idea! I will not
make the edit without a clear support so please comment if you think
that it is a good idea and if you think that it should not be done. 

Plan is as follows:

I will take full responsibility for all edits and if anything goes
wrong I will fix it.

To avoid deleting objects that were not imported from GNIS following
filters will apply
* Only objects created in specific changesets that were importing GNIS
* Only objects with name tag that has "(historical)" part (this is how
GNIS indicates nonexisting objects, see documentation page for details)
* Only objects with gnis:feature_id and name tags that were not changed
from import to 2019-03-10
* Only objects that have gnis:feature_id and name tags, where name tag
has "(historical)" part at time of edit
* Nodes that are now parts of ways or relations will be skipped, ways
and relations (if any, it seems that only nodes were imported) that are
now parts of relations will be skipped

All must apply, otherwise item will not be deleted.

List of changesets that added objects that I want to delete (most of
objects added in GNIS import will not be deleted):

* https://www.openstreetmap.org/changeset/747176 (includes notification
  of author of edits)
* https://www.openstreetmap.org/changeset/748530
* https://www.openstreetmap.org/changeset/749606
* https://www.openstreetmap.org/changeset/751242
* https://www.openstreetmap.org/changeset/755766
* https://www.openstreetmap.org/changeset/756644
* https://www.openstreetmap.org/changeset/758594
* https://www.openstreetmap.org/changeset/763672
* https://www.openstreetmap.org/changeset/764755
* https://www.openstreetmap.org/changeset/766700
* https://www.openstreetmap.org/changeset/767554
* https://www.openstreetmap.org/changeset/770127
* https://www.openstreetmap.org/changeset/774950
* https://www.openstreetmap.org/changeset/777367
* https://www.openstreetmap.org/changeset/780743
* https://www.openstreetmap.org/changeset/781903
* https://www.openstreetmap.org/changeset/783501
* https://www.openstreetmap.org/changeset/784670
* https://www.openstreetmap.org/changeset/786350
* https://www.openstreetmap.org/changeset/794649

Each changeset created by a bot will contain a single element or group
of close elements to avoid edits spanning across large areas (it is
impossible in cases where edited object itself spans very large area).

Documentation page with full info on OSM Wiki is at
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_objects_that_are_not_existing_according_to_source_of_import_that_added_them

This message will be crossposted to OSM USA slack channel 

I have experience with automatic edits. This edit will be done
carefully to avoid damage to OSM data.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove is_in:continent in USA

[Mateusz Konieczny]

Mar 20, 2019, 2:59 PM by ric...@nakts.net:

> On 20.03.19 12:14, Mateusz Konieczny wrote:
>
>>
>> Mar 20, 2019, 9:21 AM by >> frede...@remote.org 
>> <mailto:frede...@remote.org>>> :
>>
>>  Mateusz,
>>
>>  as far as I am concerned, *all* is_in tags are unnecessary at best and
>>  potentially misleading, and could be removed. I'd prefer adding these
>>  tags to the auto remove list in editors though, rather than running
>>  mechanical edits to remove them.
>>
>> Unfortunately there are some people that see value in keeping some
>> of them, that is also reason why this edit is proposed only for
>> one that is utterly broken.
>>
>
> What use do they see?
>
Cached geocoding results.

IMHO not a good reason to keep it.

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Proposed mechanical edit - remove is_in:continent in USA

[Mateusz Konieczny]

Mar 20, 2019, 9:21 AM by frede...@remote.org:

> Mateusz,
>
> as far as I am concerned, *all* is_in tags are unnecessary at best and
> potentially misleading, and could be removed. I'd prefer adding these
> tags to the auto remove list in editors though, rather than running
> mechanical edits to remove them.
>
Unfortunately there are some people that see value in keeping some 
of them, that is also reason why this edit is proposed only for
one that is utterly broken.

I was not considering auto remove list before, I will think about it
and maybe I will propose adding it to a delete list of JOSM and iD
(maybe also Vespucci if it has one).

For "prefer" - is it "against automated edit" or "against automated 
edit if auto remove list would be rejected" or "some other solution
would be better but automated edit is acceptable"?

>
> I strongly object to doing this in a *recurring* fashion for two reasons:
>
OK, I will drop recurring part. Documented:

https://wiki.openstreetmap.org/w/index.php?title=Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_is_in:continent_in_USA&diff=1823334&oldid=1823287


> If you intend to run a bot like that in regular intervals
> (which I would recommend not to do), then you need to provide a
> mechanism for individual mappers to ask the bot to keep its hands off
> something ("matkoniecz:bot=no" or so).
>
So far nobody requested it (there is opt-out section in documentation on wiki
that explicitly mentions it as a possibility), but I would implement it 
probably by
skipping objects ever edited by specific user (would require making
one more call before editing each object).

Certainly I would not require adding pointless tags to OSM database
(this would be ridiculous especially as most my bot edits are "this tag should 
be
gone as it is pointless/confusing").

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Proposed mechanical edit - remove is_in:continent in USA

[Mateusz Konieczny]

is_in:continent=* is subjective as both division Earth landmass into 
continents[1] and boundaries between continents[2] are mostly subjective. There 
are many competing ways to split world into continents and OSM is not proper 
place to record all of them or one selected system.

In rare cases where one desires to assign locations to continents it can be 
done using location data inherently included in OSM objects and explicit tags 
added to part of objects are not really useful anyway.

is_in:continent tag should be removed to avoid confusing newbies and discourage 
adding new instances of this undesirable tag.

I propose to run an automated edit restricted to USA that will remove all 
instances of this tag.

Please comment no matter what you think about this idea! I will not make the 
edit without a clear support so please comment if you think that it is a good 
idea and if you think that it should not be done.

Plan is as follows:

I will take full responsibility for all edits and if anything goes wrong I will 
fix it.

Each changeset contains a single element or group of close elements to avoid 
edits spanning across large areas (it is impossible in cases where edited 
object itself spans very large area).

This is proposed as reoccurring edit and may be made as soon as new 
is_in:continent tags appear.

Documentation page on OSM Wiki is at 
https://wiki.openstreetmap.org/w/index.php?title=Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_is_in:continent_in_USA

I have experience with automatic edits. I already made automated edits to 
remove tags across Poland and I recently processed old-style Wikipedia tags 
across USA.


This message is crosposted to OSM USA slack channel 

[1] https://en.wikipedia.org/wiki/File:Continental_models-Australia.gif
[2] https://en.wikipedia.org/wiki/Boundaries_between_the_continents_of_Earth
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us