Re: [OSM-talk] Proposed bot edit: fixing bunch of typos in tags

[Mateusz Konieczny via talk]

Mar 6, 2024, 20:00 by a...@pigsonthewing.org.uk:

>> On Wed, 6 Mar 2024, 18:15 Mateusz Konieczny via talk, 
>>  wrote:
>>
>> I propose to fix some obvious typos in tag values.
>>
>> Full list of values is at
>> https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/fix_many_obvious_typos#What
>>
>> material=woodc -> material=wood
>>
>
> This could plausibly be a typo for "wooocrete":
> https://en.wiktionary.org/wiki/woodcrete
>
>> material=metal+ -> material=metal
>>

removed from lisr

> This could mean "metal and something else"
>
>> healthcare=occupational_therapist
>>
>
> -> healthcare=occupational_therapist
>
> No change?
>
there is newline there :) Clarified it a bit.

>
> No other issues; thank you for doing this tedious cleanup work.
>
> -- 
> Andy Mabbett
> @pigsonthewing
> https://pigsonthewing.org.uk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Proposed bot edit: fixing bunch of typos in tags

[Mateusz Konieczny via talk]

I propose to fix some obvious typos in tag values. Cases were found
automatically and manually reviewed with sampling across values (in
process some were entirely retagged).

Content here is a mirror of
https://community.openstreetmap.org/t/proposed-bot-edit-fixing-bunch-of-typos-in-tags/110039
 as required by automated edits code of conduct
- if you have seen then it is likely not worth rereading it here

Typical example would be something like

state before a mechanical edit (example for a tunnel value):

    highway=footway
    tunnel=building_passage2
    layer=-1

state after an edit:

    highway=footway
    tunnel=building_passage
    layer=-1

Full list of values is at
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/fix_many_obvious_typos#What

(in case of finding more cases like this - can I just add them to bot
edit? Or should I make a new thread here and on talk mailing list)

Why it is useful? It helps newbies to avoid becoming confused. It
protects against such values becoming established. Without drudgery
that would be required from the manual cleanup. It also makes easier to
add missing surface= values and makes easier to use OpenStreetMap data,
including support in editors which explain/translate meaning of surface
values.

Why automatic edit? I have a massive queue (in thousands and tens of
thousands) of automatically detectable issues which are not reported by
mainstream validators, require fixes and fix requires review or
complete manual cleanup.

There is no point in manual drudgery here, with values obviously
fixable.

This values here do NOT require manual overview. If this cases will
turn out to be an useful signal of invalid editing than I will remain
reviewing nearby areas where bot edited.

I already skipped edits to primary tags except few blatant cases where
mistake is easy to miss (flowerbed until recently was not rendered).
Typos in primary tags that cause them to be outright missing from
typical map rendering is often coupled with other serious problems.
Probably because it indicates mapping by newbies who are likely to be
confused also by other complexities. The same goes for access tags that
I will keep fixing manually. Though typos in for example shop values
are safe to fix automatically, probably because effects are less
noticeable. Also, more obvious typos in rare, typically not rendered
amenity tags are often safe to fix.

Yes, bot edit WILL cause objects to be edited. Nevertheless, as result
map data quality will improve.

This values were found automatically based on taginfo and iD presets,
also accessed via taginfo.

Taginfo values statistics list values in OSM database, while iD presets
list which values are known for given keys.

Multiple heuristics were applies to find various typos, for example
“cuisine=bubble tea” was found to match “cuisine=bubble_tea” from iD
presets after space was replaced by underscore.

“cuisine=Thai” to “cuisine=thai” after lowercasing value.

“cuising=regional1” to “cuisine=regional” after skipping ending.

All values were looked at then manually to drop any dubious replacement
(for example healthcare=nursery to heatlhcare=nurse was skipped).

Samples was also looked at in OSM, with many values just edited. Note
that not each replacement was sampled: as many, many have just few
cases, so sampling and verifying ends with just editing all of them
manually.

If you see any values where edit would be dubious, not safe or in any
way problematic: let me know.

(BTW, one typo in iD presets was found while looking for typos, see
https://github.com/openstreetmap/id-tagging-schema/pull/1063 )

Some conversion were found manually in addition to iD presets,
currently it is only cycleway:both and shop=gun.

I also contacted community already in some cases (like sport values
with ; and in some cases of extra trailing characters) - via changeset
comments and notes.

Response confirmed that this changes are a good idea - and that just
editing will be better than asking more people.

This edit will be rerun in future as many of such typos are expected to
reappear.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Active maintenance on opening_hours tag?

[Mateusz Konieczny via talk]

Mar 3, 2024, 20:32 by iboa...@gmail.com:

>
> I was wondering, are there any automatic maintenance bots or anything that 
> run periodically to detect and maybe try to clean up errors?
>
That would require mistake opening hours that are broken and at the same 
obviously

I am not aware about either potential for fixes or about running bots.

Though if there is source data available that we can use then imports/comparing
with shop-provided data can work, and there are/were some imports like that.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] creating bbox in lua

[Mateusz Konieczny via talk]

Which part is hard for you?

Installing lua?
Downloading osm data?
Parsing OSM data?
Getting location of elements of relation?Finding bbox from lat lon list?
Something else?

24 Feb 2024, 19:16 by wambac...@posteo.de:

>
> Hi,
>
>
> is there a way to create the bbox of an object (mostly relations)  in lua?
>
>
> regards
>
>
> walter
>
> -- 
>  My projects:
>  
>  > OSM SoftwareWatchlist 
>  > OSM EmergencyMap >  (*)
>  > OSM HealthcareMap >  (*)
>  > OSM Postcode Map >  (Germany) 
>  
>  *) Europe
>___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Proposed bot edit: close notes with just "site" or "SITE" in the report

[Mateusz Konieczny via talk]

I am doing it semimanually so far (all closures are human reviewed)

For some reason it keeps being repeatedly done at relatively large scale.

I propose a bot edit that will automatically close all notes that had
"site", "SITE" or other capitalisation variant, also if there are
extra whitespace before/after (spaces, new lines etc).

Closure would look like 
https://www.openstreetmap.org/note/4089986
https://www.openstreetmap.org/note/4090027
https://www.openstreetmap.org/note/4091174
https://www.openstreetmap.org/note/4091283
https://www.openstreetmap.org/note/4091304
but without a final paragraph.

(bot actions would still be occasionally spot-checked
but not all of them)

I want to switch to unreviewed bot edits as reviewing
all closures in this case is pointless and a waste of time.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] bot edit proposal: Automatically remove obvious descriptive names (obvious cases only, not all suspect objects)

[Mateusz Konieczny via talk]

Automatically remove obvious descriptive names (obvious cases only, not
all suspect objects)

This is basically the same
https://community.openstreetmap.org/t/bot-edit-proposal-automatically-remove-obvious-descriptive-names-obvious-cases-only-not-all-suspect-objects/107393

Some minor feedback was taken into account.

There are object types where mappers relatively often add invalid name
tag that repeats object type, and it is obvious enough that can be
fixed remotely.

I was doing it with some objects, and in some cases it is often
combined with very problematic tagging nearby (can link some queries if
anyone wants).

But for some objects use of obvious descriptive names is quite popular,
to the point that manual fixing cannot keep up AND it is possible to
fix it with a bot edit AND other tagging in area is typically fine.
Sometimes there are clusters of other objects with descriptive names,
but these can be found independently.

And yes "Toilet" can be signed but it does not make it a name, like
"Toilet, 2 euro fee" is not a name either. Or sign pointing toward
bunker with "Bunker" label is not indicating that bunker has a name
Bunker.

Note
https://community.openstreetmap.org/t/is-name-toilet-even-theorethically-valid-for-amenity-toilets/105540
where it was discussed

See also approved bot edit doing this for viewpoints:
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/remove_obvious_descriptive_names_for_viewpoints_(obvious_cases_only,_not_all_suspect_objects)

I also noticed that OsmAnd edit plugin is overrepresented in adding
such bad pseudonames and tracked down problem to a bad interface
design, reported in https://github.com/osmandapp/OsmAnd/issues/18651 to
its authors. So far they decided to claim that it is not a problem, I
plan to compile some statistics making clear their editor is causing
problems in this specific area.

I propose to run automated cleanup for multiple types of objects. In
each case it would remove also capitalisation variants - so not only
name=toilet but also name=Toilet and name=TOILET). In each case only
objects tagged as a single type would be processed. For example
amenity=toilets with name=Toilet but also waterway=waterfall would not
be edited as it has an unexpected tag.


Note that this relies on assumption that object tagged like

- amenity=toilets
- name=Toilet

is always case of misusing name tag.


Objects which carry unexpected tags or tags not typical for viewpoints,
or note/fixme tags will be skipped. So for example

- man_made=cairn
- amenity=restaurant
- name=Cairn

well not be touched. In theoretical case of restaurant named "Cairn"
which is also cairn, such object will not be modified at all. 

Cases like

- tourism=viewpoint
- waterway=waterfall
- name=Viewpoint 

or

- tourism=viewpoint
- name=Viewpoint
- note=Actually named "Viewpoint"

would not be edited either as they carry extra unexpected tags.

(Though I do not expect last case to be ever validly tagged...)

Obviously objects with just

name=Toilet

would not be edited in this edit (as both object type and name is
required).

- tourism=viewpoint
- fee=yes
- name=VIEWPOINT 

would be edited. Similarly with other  that are expected attributes of
viewpoints.


Bot edit would be worldwide, with edits split in parts, edit run
separately for each object type. Edits would be repeated in future.

Note: as required by automated edits code of conduct a bot proposal
will be also posted on talk mailing list 

Comments welcome - both if you see problems with this edit and if you
support it (though upvoting also works I guess)

Following types of objects will be included in this edit (initial
series was done only for viewpoints)

- waterway = waterfall with name waterfall
  - only following additional keys are allowed, presence of any other
  tags will block an automated edit:
    - height

- amenity = bench with name bench
  - only following additional keys are allowed, presence of any other
  tags will block an automated edit:
    - backrest
    - material
    - surface
    - seats
    - capacity
    - ele
    - colour
    - inscription
    - access
    - covered
   
- leisure = playground with name playground

   
  - only following additional keys are allowed, presence of any other
  tags will block an automated edit:
   
    - surface  
    - access   
    - max_age  
    - min_age  
    - playground:theme 

- tourism = viewpoint with names viewpoint, punkt widokowy (“punkt
  widokowy” is in Polish, I am native speaker of Polish)
  - only following additional keys are allowed, presence of any other
  tags will block an automated edit:
    - direction
    - ele
    - wheelchair
    - opening_hours
    - area

- man_made = cairn with name cairn
  - only 

Re: [OSM-talk] Mechanical Edit: Merge of DB Netz AG and DB Station AG to DB InfraGO AG

[Mateusz Konieczny via talk]

Dec 14, 2023, 19:52 by osm...@michreichert.de:

> Hi Mateusz,
>
> Am 08.12.23 um 11:00 schrieb Mateusz Konieczny via talk:
>
>> Why remove operator:wikipedia=* rather than fixing them?
>>
>
> I would have to change operator:wikipedia=* to point to the new article 
> (https://de.wikipedia.org/wiki/DB_InfraGO). However, the tag is a duplication 
> if operator:wikidata=* is set. If operator:wikidata=* was set, I will update 
> it. If operator:wikidata=* was missing but operator:wikipedia=* was set, I 
> will set
> operator:wikipedia=de:DB InfraGO.
>
personally I consider it as not a full duplicate, as *wikipedia tags are
human-readable.

But not adding them and updating if present is also OK to me and in such
case I withdraw my objection.

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

Re: [OSM-talk] Mechanical Edit: Merge of DB Netz AG and DB Station AG to DB InfraGO AG

[Mateusz Konieczny via talk]

Right now I am against making this edit due to not answering this question.


Dec 8, 2023, 11:06 by talk@openstreetmap.org:

> Why remove operator:wikipedia=* rather than fixing them?
>
>
> Dec 7, 2023, 22:12 by osm...@michreichert.de:
>
>> Hi,
>>
>> as of 1 January 2024, DB Netz AG and DB Station AG will merge and 
>> renamed to DB InfraGO AG. This requires an update to lots of operator=* tags 
>> including operator:wikidata=*, and some owner=* tags. The mechanical edit 
>> will also remove existing operator:wikipedia=* from the modified objects.
>>
>> The mechanical edit affects mainly Germany, but some infrastructure is 
>> located in Switzerland, Belgium and Czech Republic. That's why I post at 
>> this mailing list at all.
>>
>> You can find the documentation at
>> https://wiki.openstreetmap.org/wiki/Automated_Edits/Nakaner-repair/DB_InfraGO_AG
>>
>> Best regards
>>
>> Michael
>>
>
>

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

Re: [OSM-talk] Mechanical Edit: Merge of DB Netz AG and DB Station AG to DB InfraGO AG

[Mateusz Konieczny via talk]

Why remove operator:wikipedia=* rather than fixing them?


Dec 7, 2023, 22:12 by osm...@michreichert.de:

> Hi,
>
> as of 1 January 2024, DB Netz AG and DB Station AG will merge and 
> renamed to DB InfraGO AG. This requires an update to lots of operator=* tags 
> including operator:wikidata=*, and some owner=* tags. The mechanical edit 
> will also remove existing operator:wikipedia=* from the modified objects.
>
> The mechanical edit affects mainly Germany, but some infrastructure is 
> located in Switzerland, Belgium and Czech Republic. That's why I post at this 
> mailing list at all.
>
> You can find the documentation at
> https://wiki.openstreetmap.org/wiki/Automated_Edits/Nakaner-repair/DB_InfraGO_AG
>
> Best regards
>
> Michael
>

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

Re: [OSM-talk] Automatically remove obvious descriptive names for viewpoints (obvious cases only, not all suspect objects)

[Mateusz Konieczny via talk]

Nov 16, 2023, 21:02 by marc_m...@mailo.com:

>
> Le 16.11.23 à 13:35, Mateusz Konieczny via talk a écrit :
>
>> Similarly with other  that are expected attributes of viewpoints.
>>
>
> Which others ?
>
source, direction, created_by, layer, ele, wheelchair, opening_hours, area

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

Re: [OSM-talk] Automatically remove obvious descriptive names for viewpoints (obvious cases only, not all suspect objects)

[Mateusz Konieczny via talk]

Nov 16, 2023, 20:51 by talk@openstreetmap.org:

> In practice MR tasks are human-executed bit edits with no actual
> review happening (they could be useful where correct solution
> needs to be selected from some available, but here it would just wait
> until someone would manually but still robotically remove
> all name tags)
>
To clarify:

- not all people active on MR skip verification or make bad edits,
some are making fine edits

- but there is enough of people doing edits without verification
in case of tasks having single possible edit action (or not doing edit),
to make MR useless for cases where verification is needed
(especially with "press to edit" mode being activated)
As there is high risk of such person appearing and making edits blindly

- MR may be useful for cases where elements needs to be edited
in multiple ways and decision needs to be taken before edit,
though there were also many cases of bad editing here
But it in general filters out people clicking "make edit"
on repeat without any verification

- MR is utterly pointless for cases where local knowledge
would be needed and aerial imagery + already present tags
are not sufficient for verification

- MR has many edits that are actually undiscussed bot edits,
just done manually by humans (still without actual review, some tasks
are not even having fig-leaf request of human needing to review anything),
done in violation of
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
- some MR tasks are undiscussed imports, breaking
https://wiki.openstreetmap.org/wiki/Import/Guidelines

- reporting challenges exists, but reports are not acted on by people 
maintaining MR ( even ones where people running bad challenges 
voluntarily closed them - still remain open at
https://github.com/maproulette/challenge-reports/issues )

---

Suggesting MR as way to verify objects before edit is pointless.
If actual verification is needed before edits that would be done
always or almost always in the same way, then MR is pointless
for that and should not be suggested as a solution.

If multiple types of edits can be done, depending on a case or
someone has bot edit approval (but is unable to mass edit
via script or JOSM or other tool) then it is a viable MR task.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automatically remove obvious descriptive names for viewpoints (obvious cases only, not all suspect objects)

[Mateusz Konieczny via talk]

Nov 16, 2023, 21:02 by marc_m...@mailo.com:

> Hello,
>
> Le 16.11.23 à 13:35, Mateusz Konieczny via talk a écrit :
>
>> this relies on assumption that object tagged like
>> - tourism=viewpoint
>> - name=Viewpoint
>> is always case of misusing name tag.
>>
>
> how could anyone possibly know that this generic name is the real name?
>
Not entirely sure what you mean here?
That you are confused why someone would tag it?
Or that it could be plausibly valid name?
(for me it is 100% clear that it cannot be real name, like natural=tree 
name=Tree is
clearly invalid one)

> I don't know of any cases for a point of view, but it seemed to me that the 
> wiki mentioned such a case, but I can't find it.
>
>> Similarly with other  that are expected attributes of viewpoints.
>>
>
> Which others ?
>
Good point, I will share listing when I will be back at home and some spare 
hobby time

>> Comments welcome
>>
>
> please run previously approved ones (like surface=*) before asking more edits.
>
good news here!
this edit is treated as approved, and was added to bot edit schedule
it runs right now, see 
https://www.openstreetmap.org/user/Mateusz%20Konieczny%20-%20bot%20account/history(note,
 link may obviously show other edits in future as it goes to simply listing of 
latest edits made from that account)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Automatically remove obvious descriptive names for viewpoints (obvious cases only, not all suspect objects)

[Mateusz Konieczny via talk]

Nov 16, 2023, 20:01 by a...@pigsonthewing.org.uk:

> On Thu, 16 Nov 2023 at 12:35, Mateusz Konieczny via talk
>  wrote:
>
>> invalid name tag that repeats object type, and it is obvious enough that can 
>> be fixed remotely.
>>
>> "Viewpoint, entry 5 euro"
>>
>> "Viewpoint, no wheelchair access".
>>
>
> Such names should not be removed until the additional data has been
> transferred to a more suitable tag.
>
I agree.

Such names will NOT be removed in this bot edit.

Only name=viewpoint, name=Viewpoint and name=VIEWPOINT would be,
and only on objects tagged solely as viewpoints and not as other object types.

>> Note that this relies on assumption that object tagged like
>>
>> - tourism=viewpoint
>> - name=Viewpoint
>>
>> is always case of misusing name tag.
>>
>
> I dispute that that is always the case.
>
Can you give example of situation where viewpoint is named "Viewpoint"?
Or toilet named "Toilet"?

(note filtering described by me, not all names from viewpoints will be removed,
names on objects tagged as not only viewpoints will not be touched either)

>> - tourism=viewpoint
>> - fee=yes
>> - name=VIEWPOINT
>>
>> would be edited.
>>
>
> Again, not 100% reliable.
>
>
> Overall I think this would be best made into some sort of gamified
> challenge, like MapRoulette, where each case can be reviewed
> individually.
>
how MR would help here? How someone would review
object with

tourism=viewpoint
name=Viewpoint

tags?

In practice MR tasks are human-executed bit edits with no actual
review happening (they could be useful where correct solution
needs to be selected from some available, but here it would just wait
until someone would manually but still robotically remove 
all name tags)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Automatically remove obvious descriptive names for viewpoints (obvious cases only, not all suspect objects)

[Mateusz Konieczny via talk]

note:
this was posted already at 
https://community.openstreetmap.org/t/automatically-remove-obvious-descriptive-names-for-viewpoints-obvious-cases-only-not-all-suspect-objects/105892if
 you have seen that then rest of the post has no new content

posting also here as required by
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
-

There are object types where mappers relatively often add invalid name tag that 
repeats object type, and it is obvious enough that can be fixed remotely.

I was doing it with some objects, and in some cases it is often combined with 
very problematic tagging nearby (can link some queries if anyone wants).

But for some objects use of obvious descriptive names is quite popular, to the 
point that manual fixing cannot keep up AND it is possible to fix it with a bot 
edit AND other tagging is typically fine. Sometimes there are clusters of other 
objects with descriptive names, but these can be found independently.

And yes "Viewpoint" can be signed but it does not make it a name, like 
"Viewpoint, entry 5 euro" is not a name either. Or "Viewpoint, no wheelchair 
access".

Note 
https://community.openstreetmap.org/t/is-name-toilet-even-theorethically-valid-for-amenity-toilets/105540
 where it was discussed

I propose to run automated cleanup for viewpoints. It would remove 
name=viewpoint (and name=Viewpoint and name=VIEWPOINT) from objects tagged only 
as viewpoints. 


Note that this relies on assumption that object tagged like

- tourism=viewpoint
- name=Viewpoint

is always case of misusing name tag.


Objects which carry unexpected tags or tags not typical for viewpoints, or 
note/fixme tags will be skipped. So for example

- tourism=viewpoint
- amenity=restaurant
- name=Viewpoint

well not be touched. In theoretical case of restaurant named "Viewpoint" which 
is also viewpoint, such object will not be modified at all. So

- tourism=viewpoint
- waterway=waterfall
- name=Viewpoint 

or

- tourism=viewpoint
- name=Viewpoint
- note=Actually named "Viewpoint"

would not be edited either.

(Though I do not expect last case to be ever validly tagged...)

Obviously objects with just

name=Viewpoint

would not be edited in this edit.

- tourism=viewpoint
- fee=yes
- name=VIEWPOINT 

would be edited. Similarly with other  that are expected attributes of 
viewpoints.

Bot edit would be worldwide, with edits split in parts. Edits would be repeated 
in future.

Comments welcome - both if you see problems with this edit and if you support 
it.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed bot edit: automatic replacement of surface values where it is safe

[Mateusz Konieczny via talk]

Nov 2, 2023, 15:05 by a...@pigsonthewing.org.uk:

> On Wed, 1 Nov 2023 at 22:42, Mateusz Konieczny via talk
>  wrote:
>
>>
>> I proposed some time ago to fix some surface values.
>>
>
> I support this in general, but the following may be worthy of further
> consideration:
>
>> surface = U → surface = unpaved
>>
>
> Are we sure this is what is meant?
>
pretty sure, turns out that failed autocomplete is commons
feel free to research remaining cases, if there is any noticeable amount of
paved surfaces there I will drop it

>> surface = unhewn_cobblestones → surface = unhewn_cobblestone
>>
>
> How is this different from surface = cobblestone ?
>
See https://wiki.openstreetmap.org/wiki/Tag:surface%3Dcobblestone
and
https://wiki.openstreetmap.org/wiki/Tag:surface%3Dunhewn_cobblestone
>> surface = a → surface = asphalt
>>
>> surface = AS → surface = asphalt
>>
>> surface = ea → surface = earth
>>
>
> Are we sure these are what is meant?
>
>
>> surface = unpavedNo → surface = unpaved
>>
>
> Are we sure that this does not mean "not unpaved", i.e. "paved"
>
see surface=U comment, in this cases I checked decent sample of cases

>> there are also many low-use values with one or two or three extra bogus 
>> characters, for example
>> surface = artificial_turf22 → surface = artificial_turf
>>
>> would be also OK to migrate them without listing them
>> for review here and just add them to replace list later?
>>
>
> OK by me.
>
:)

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

Re: [OSM-talk] Proposed bot edit: automatic replacement of surface values where it is safe

[Mateusz Konieczny via talk]

I will review this list.

Rare obvious values I will just retag.
Some may appear in future proposal.
Some are proposed in this one (holz)
Some are too complex (pflastersteine) and I will rather create notes for them
as it can be not only sett
https://community.openstreetmap.org/t/proposed-bot-edit-automatic-replacement-of-surface-values-where-it-is-safe/105361/5
Nov 2, 2023, 08:11 by md...@xs4all.nl:

> I have a few suggestions too:
>  
> verdichtet => compacted
> straatstenenc => paving_stones
> bestraat => paving_stones
> niet-bestraat => unpaved
> niet-bestraat2 => unpaved
> niet-bestraat33 => unpaved
> щебеночное_покрытие => gravel
> no_paved => unpaved
> concreteas => concrete
> Pflastersteine => sett
> pflastersteine => sett
> Bosbodem => dirt
> klinkers => sett
> sans_revêtement => unpaved
> schotter => gravel
> Turf => turf
> holz => wood
> грунт => dirt
> terre_battue => gravel
> плитка => paving_stones
> pavingstones => paving_stones
> não_pavimentado => unpaved
> Waldboden => ground (literally forest soil)
> permukaan tanah dan Beton means ground and concrete
>  
> And I want to point attention to surface=앿
> https://www.openstreetmap.org/way/1185643877
> Seems someone is adding this in Taiwan a lot. I think it means unpaved.
>  
>
>> Op 01-11-2023 23:42 CET schreef Mateusz Konieczny via talk 
>> :
>>  
>>  
>> I proposed some time ago to fix some surface values.
>>  
>> Edit is documented at
>> https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/fixing_malformed_surface_tags
>>  
>> I propose to expand this by fixing also values listed below.
>>  
>> Please comment if any of proposed replacements are dubious in any way and 
>> do not qualify for a replacement with an automated edit.
>>  
>> Please also comment if you checked values proposed to be edited and they 
>> seem fine!
>>  
>> Edit will affect around 2200 objects.
>>  
>> It is preferable to use standard tag values where possible,
>> and in many cases unusual values can be migrated without any data loss.
>> The list below is supposed to contain only such cases.
>>  
>> If anyone wants I can help them to find affected objects or present listing 
>> of
>> edits which added this tags or list people who added this values onto 
>> currently
>> tagged osm objects.
>>  
>> Samples of this values were tested. I also asked for review at >> 
>> https://forum.openstreetmap.fr/t/review-requested-before-proposing-bot-edit-for-automated-fixing-of-surface-values/18419
>>  
>> Tried to use them as detectors of bogus data, neither were really useful for 
>> this purpose.
>> We have many better ways to find OSM data requiring human review.
>>  
>> So I am proposing following changes
>>  
>> tags with highest use, among ones that will be retagged
>> surface = astroturf with 297 uses
>> surface = timber with 122 uses
>> surface = paving with 179 uses
>> surface = U with 82 uses
>> surface = enrobé with 276 uses
>> surface = terre with 383 uses
>>  
>>  
>> surface = astroturf → surface = artificial_turf
>> surface = timber → surface = wood (see >> 
>> https://www.openstreetmap.org/changeset/66866027>>  >> 
>> https://www.openstreetmap.org/changeset/126078123>>  >> 
>> https://www.openstreetmap.org/changeset/126078123>>  >> 
>> https://www.openstreetmap.org/changeset/68461319>>  >> 
>> https://www.openstreetmap.org/changeset/69445813>>  >> 
>> https://www.openstreetmap.org/changeset/57280475>>  >> 
>> https://www.openstreetmap.org/changeset/126800407>>  )
>> surface = DIRT → surface = dirt
>> surface = paving → surface = paved
>> surface = U → surface = unpaved
>>  
>> French from >> 
>> https://lists.openstreetmap.org/pipermail/talk/2023-April/088164.html
>> review at >> 
>> https://forum.openstreetmap.fr/t/review-requested-before-proposing-bot-edit-for-automated-fixing-of-surface-values/18419
>>  
>> surface = enrobé → surface = asphalt
>> surface = béton_bitumineux → surface = asphalt
>> surface = béton_bitumimeux → surface = asphalt
>> surface = bitumen → surface = asphalt
>> surface = enrobes → surface = asphalt
>> surface = bitume → surface = asphalt
>> surface = goudronné → surface = asphalt
>> surface = gourdon → surface = asphalt
>> surface = plastique → surface = plastic
>> surface = banc_de_sable → surface = 

Re: [OSM-talk] Proposed bot edit: automatic replacement of surface values where it is safe

[Mateusz Konieczny via talk]

Nov 2, 2023, 10:06 by marc_m...@mailo.com:

> Hello,
>
> Le 01.11.23 à 23:42, Mateusz Konieczny via talk a écrit :
>
>> French from 
>> https://lists.openstreetmap.org/pipermail/talk/2023-April/088164.html
>>
>
> wouldn't it be a good idea to make the changes you've already agreed
> to first? because this is the 3rd time we've reviewed the list.
> or you can make a request separating the new values from the old ones
>
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct 
requires changes to be reviewed at talk mailing list

I also posted French words on French forum to give people not active
on English forums to review French words.

I also posted on community forum as many are present there - no
entries were added compared to that posting.

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

[OSM-talk] Proposed bot edit: automatic replacement of surface values where it is safe

[Mateusz Konieczny via talk]

I proposed some time ago to fix some surface values.

Edit is documented at
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/fixing_malformed_surface_tags

I propose to expand this by fixing also values listed below.

Please comment if any of proposed replacements are dubious in any way and 
do not qualify for a replacement with an automated edit.

Please also comment if you checked values proposed to be edited and they seem 
fine!

Edit will affect around 2200 objects.

It is preferable to use standard tag values where possible,
and in many cases unusual values can be migrated without any data loss.
The list below is supposed to contain only such cases.

If anyone wants I can help them to find affected objects or present listing of
edits which added this tags or list people who added this values onto currently
tagged osm objects.

Samples of this values were tested. I also asked for review at 
https://forum.openstreetmap.fr/t/review-requested-before-proposing-bot-edit-for-automated-fixing-of-surface-values/18419

Tried to use them as detectors of bogus data, neither were really useful for 
this purpose.
We have many better ways to find OSM data requiring human review.

So I am proposing following changes

tags with highest use, among ones that will be retagged
surface = astroturf with 297 uses
surface = timber with 122 uses
surface = paving with 179 uses
surface = U with 82 uses
surface = enrobé with 276 uses
surface = terre with 383 uses


surface = astroturf → surface = artificial_turf
surface = timber → surface = wood (see 
https://www.openstreetmap.org/changeset/66866027 
https://www.openstreetmap.org/changeset/126078123 
https://www.openstreetmap.org/changeset/126078123 
https://www.openstreetmap.org/changeset/68461319 
https://www.openstreetmap.org/changeset/69445813 
https://www.openstreetmap.org/changeset/57280475 
https://www.openstreetmap.org/changeset/126800407 )
surface = DIRT → surface = dirt
surface = paving → surface = paved
surface = U → surface = unpaved

French from 
https://lists.openstreetmap.org/pipermail/talk/2023-April/088164.html
review at 
https://forum.openstreetmap.fr/t/review-requested-before-proposing-bot-edit-for-automated-fixing-of-surface-values/18419

surface = enrobé → surface = asphalt
surface = béton_bitumineux → surface = asphalt
surface = béton_bitumimeux → surface = asphalt
surface = bitumen → surface = asphalt
surface = enrobes → surface = asphalt
surface = bitume → surface = asphalt
surface = goudronné → surface = asphalt
surface = gourdon → surface = asphalt
surface = plastique → surface = plastic
surface = banc_de_sable → surface = sand
surface = terre → surface = earth
surface = Terre → surface = earth
surface = terre_boue → surface = mud
surface = terre_humide → surface = mud
surface = terre,_boue → surface = mud
surface = graviers → surface = gravel
surface = tere → surface = earth
surface = terre2 → surface = earth
surface = caoutchouc → surface = rubber
surface = bois → surface = wood
surface = béton_désactivé → surface = concrete
surface = terre_batue → surface = clay
surface = pavés → surface = paved
surface = carrelage → surface = tiles
surface = pelouse_et_terre → surface = grass;ground
surface = terre_touvenant → surface = ground
surface = terre;herbe → surface = ground;grass
surface = terre_naturelle,_argileuse → surface = ground
surface = gravier → surface = gravel
surface = gazon_synthétique → surface = artificial_turf
surface = béton → surface = concrete
surface = ciment → surface = concrete
surface = herbe → surface = grass
surface = gazon → surface = grass
surface = herb → surface = grass
surface = herbe_naturel → surface = grass
surface = pelouse → surface = grass
surface = pelouse_naturelle → surface = grass
surface = terre_et_rochers → surface = ground;rock
surface = béton_bois → surface = concrete;wood
surface = terre,_cailloux → surface = ground;gravel
surface = terre_et_herbe → surface = earth;grass
surface = herbe_et_sable → surface = grass;sand
surface = sable_et_terre → surface = sand;earth
surface = terre_et_sable → surface = earth;sand
surface = terre_cailloux → surface = ground;gravel
surface = terre_goudrons → surface = ground;asphalt
surface = terre_goudron → surface = ground;asphalt
surface = terre_pierres → surface = ground;gravel
surface = terre_et_pierre → surface = ground;gravel
surface = terr_et_pierre → surface = ground;gravel
surface = terre/sable → surface = ground;sand
surface = terre_et_pierres → surface = ground;gravel
surface = Herbe_et_cailloux → surface = grass;gravel
surface = terre_et_gravier → surface = ground;gravel
surface = gravillons,_béton → surface = gravel;concrete
surface = graviers_et_terre → surface = gravel;ground
surface = sable → surface = sand
surface = Sable → surface = sand
surface = cailloux → surface = gravel
surface = pierre → surface = gravel
surface = gravier0 → surface = gravel

surface = asphalt_on_concrete_sub-base → surface = asphalt 

Re: [OSM-talk] software requirements for OSM Editor: Firefox

[Mateusz Konieczny via talk]

6 paź 2023, 13:57 od tr...@gmx.de:

> On 23-10-06 13:41, Tom Hughes wrote:
>
>> On 06/10/2023 12:12, Martin Trautmann wrote:
>>
>>> On 23-10-06 12:55, Tom Hughes via talk wrote:
>>>
 No it was released in June 2020. October 2021 was the last
 security patches.

 To answer the original question there have been any deliberate
 changes that I know but given the error it's entirely possible
 that FF has fixed something in what CSP rules it checks for what
 requests.

>>>
>>> I doubt that since FF did not see any changes here for some time,
>>> unfortunately. So it appears to be from an OSM editor's change.
>>>
>>
>> I think you misunderstood what I was saying.
>>
>> My hypothesis is that something in iD has started using a data URL
>> where it didn't before and that is triggering a latent bug in your
>> version of firefox (in that it is checking that URL against the
>> media-src rule in our security policy) while newer versions of
>> firefox are checking it against some other rule.
>>
>
> Thanks - that does clarify the issue. But as you say, "something in iD
> has started" - so it's a change within OSM's editor, which does break
> old systems.
>
> Maybe it's a reasonable and necessary change for ID - but maybe it isn't!
>
>
>> Without knowing more about which load is being blocked it's not
>> really possible to say more and I might be totally wrong as I'm
>> just guessing from the limited information available.
>>
>
>
> I agree - but I don't know where else to report this malfunction. It's
> obvious that one part of this bug is an outdated FF version. But that
> does not mean that those have to be excluded.
>
>
If you track down which exact change 
changed things then maybe it would make sense to report it
(You can try older iD versions and revisions)

In general I would strongly recommend
not using such ancient and insecure browser.

You can setup dual booting, get new see
computer, move that setup to VM, replace that software...___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] software requirements for OSM Editor: Firefox

[Mateusz Konieczny via talk]

6 paź 2023, 15:42 od talk@openstreetmap.org:

> On 06/10/2023 14:23, Martin Trautmann wrote:
>
>> On 23-10-06 14:24, Tom Hughes wrote:
>>
>>>
>>>
>>> Maybe it would be easy to avoid and maybe it wouldn't but until
>>> we know what the actual problem is we can't tell and none of the
>>> developers are likely to have such an old browser to reproduce
>>> it even if they wanted to so unless you can provide more details
>>> somehow it's not clear what can be done.
>>>
>>
>>
>> Apart from the info given before I do see an
>>
>> Uncaught SyntaxError: expected expression, got '='
>>
>> https://www.openstreetmap.org/assets/id-859874f88bc2e65931793d0d2edfb626917168cd008d86196e5b6fe2c88b39d5.js
>>
>> :29:19029 
>> 
>>
>
> That's far more likely to be the main problem but you'd need to
> ask the iD developers if they have any clue what it might be.
>
I really would not bother asking people
about bugs present only in ancient, EOL
browsers (unless some project promises to
support browser not supported by even
maker of this browser)___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] software requirements for OSM Editor: Firefox

[Mateusz Konieczny via talk]

Firefox 78 EST has reached end of life over year ago, see 
https://endoflife.date/firefox

It was released in October 2021.

I would strongly encourage to update it for security reasons.
And would not be surprised if random things are breaking.

Oct 6, 2023, 11:54 by tr...@gmx.de:

> Have there been any changes for a minimum software version to use the 
> openstreetmap editor?
>
> I can still browse with my old firefox version 78.15.0esr, but when I try to 
> edit anything, the editor's area remains empty.
>
> Inspecting the pages names "The page’s settings blocked the loading of a 
> resource at data: (“media-src”)."
>
> id-container does not load any more, I suppose.
>
> Anything from 
> https://www.openstreetmap.org/assets/id-859874f88bc2e65931793d0d2edfb626917168cd008d86196e5b6fe2c88b39d5.js
>  causes an error here.
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] Various POI extracts from the web ... What to do?

[Mateusz Konieczny via talk]

Adding them to https://github.com/alltheplaces/alltheplaces seems a potential 
solution

Or publish geojson/leaflet, I did it with missing bicycle parkings for my city:

https://matkoniecz.github.io/miejsca_do_odwiedzenia_w_Krakowie_by_mapowac/

https://community.openstreetmap.org/t/chce-ktos-liste-miejsc-do-odwiedzenia-w-krakowie-by-parkingi-rowerowe-mapowac/8904/7

Sep 30, 2023, 16:34 by facebook_140f8d4e-9d8f-4d51-a5a7-320f53afc...@vollbio.de:

>
> Hi there
>
>
> I am sometimes faced with websites that have collected a lot of  GPS POIs 
> that are of interest to me but not available in OSM,  e.g.:
>
>
>>
>> https://mundraub.org/map>>  (a website for free fruits)
>>
>>
>> https://drive.google.com/open?id=1gFCcfcdvdQr4e0dKmyNnsn-4q7ATlCix=sharing>>
>>   (rest places in Japan)
>>
>>
>> https://www.titsa.com/index.php/atencion-al-cliente/puntos-de-venta-y-recarga>>
>>   (a website with a map of recharge points of bus money cards in
>> Tenerife ... currently not working)
>>
>>
>
> I often will run a script to scrap/extract the GPS and other  information 
> and then put it into a GPX, which I can use in OsmAnd.  Now, I wouldn't 
> put all these points into OSM, both due to  licencing questions and 
> accuracy of POIs.
>
>
> However, I was wondering how these GPS POIs could be made  available to 
> other users that might find these POIs relevant? I  wouldn't want to 
> create OsmAnd tiles, but I was looking for  something like OSM Traces, 
> just for POIs.
>
>
> Does anyone have an idea hoer to spread such information?
>
>
> Many thanks
>
>
> Klaus
>
>

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

Re: [OSM-talk] When two bots go to war

[Mateusz Konieczny via talk]

Sep 12, 2023, 10:41 by marc_m...@mailo.com:

> Le 12.09.23 à 08:23, Snusmumriken via talk a écrit :
>
>> I recently happen to witness an edit war between two bots, that changed
>> a tag on an object back and forth once a day
>>
>
> id of the object ?
>
https://www.openstreetmap.org/changeset/141053368

for example https://www.openstreetmap.org/node/8537345577
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] When two bots go to war

[Mateusz Konieczny via talk]

Sep 12, 2023, 09:45 by talk@openstreetmap.org:

> Well, this one came to light only because it happened in a big city
> where a local mapper happened to notice it. Who knows if there are
> other bot wars going on in Siberia or elsewhere where there are very
> few local mappers.
>
To be less cryptic, it happened with bot edit I was running,
and thanks for spotting this.

I am always investigating some sample of bot edits so I would
notice it sooner or later. Especially once initial run would complete
and only new edits would appear
(but again thanks for spotting it and allowing it to fix relatively quickly!)

> And I don't mean that a bot never should be allowed to edit an object a
> second time, just that the bot owner should have to review it if that
> bot tries to change an object twice.
>
note that at least for contervandalism bots it still makes no sense,
in cases when vandal attacked again

or all edits from some user are rolled back

also, if new bot edit is distinct from old one

(but maybe I should add detector of such case into my code?
though that is first time it happened...)


> On Tue, 2023-09-12 at 09:16 +0200, Casper Kersten wrote:
>
>> I think we can rely on reason and logic here instead of extra
>> guidelines. This was obviously not intentional and we don't need to
>> write guidelines against it.
>>
>> (Re-sent because I accidentally replied privately instead of to the
>> mailing list)
>>
>> Op di 12 sep 2023 om 08:30 schreef Snusmumriken via talk
>> :
>> > I recently happen to witness an edit war between two bots, that
>> > changed
>> > a tag on an object back and forth once a day. It stopped once I
>> > pointed
>> > it out. 
>> > 
>> > These are the guidelines for bots
>> > https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
>> > 
>> > Shouldn't they be amended with something like; "A bot should not
>> > edit
>> > the same object twice"
>> > 
>> > ___
>> > talk mailing list
>> > talk@openstreetmap.org
>> > https://lists.openstreetmap.org/listinfo/talk
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] Adding automated trees to OSM

[Mateusz Konieczny via talk]

Aug 8, 2023, 20:19 by hsomaya2...@gmail.com:

> Thanks for the link. Answering your question below:
>
> 1) what is the source of tree data--- from an open source app that allows 
> users to capture images of trees
>
what is the license of this data?
how old is the oldest data you want to use? (say, tree recorded X years ago)

> 2) can you give samples of tree data that would be added?-- an example would 
> be trees that are around my residential house, healthy trees
>
I am not looking for description of data, but some representative sample of 
actual data
and how it matches reality (for example is it offset from actual tree positions)

> 3) where it would be added-- for now, mainly the US area
> 4) how you will prevent duplication with existing trees-- code makes sure 
> that no two trees at the same GPS can be added
>
what if there is another tree close to it? Maybe the same offset by 10cm?
What if there is a tree row nearby?

> 5) which tags will be used-- species, genus, maybe height, image of tree, 
> maybe wikipedia tree about species, tree type (broadleaf versus not)
> 6) have you verified quality of data you want to add-- In terms of verify, we 
> make sure it is a healthy tree that has not already been added
>
how accurate is tree location?

>
> On Tue, Aug 8, 2023 at 2:12 PM Mateusz Konieczny via talk <> 
> talk@openstreetmap.org> > wrote:
>
>> 1) what is the source of tree data
>> 2) can you give samples of tree data that would be added?
>> 3) where it would be added
>> 4) how you will prevent duplication with existing trees
>> 5) which tags will be used
>> 6) have you verified quality of data you want to add
>>
>> Also, I want to echo comments from
>> https://community.openstreetmap.org/t/osm-tree-automation-worldwide/102197/2
>>
>>
>> Aug 8, 2023, 20:06 by >> hsomaya2...@gmail.com>> :
>>
>>> Hello! Hope everything is well. I am trying to add trees to OSM in an 
>>> automated way via python. Of course, these are real trees that I do not 
>>> want to add manually. I am planning to run the script every 30 minutes to 
>>> process about 100 trees at a time, creating 7 changests for every run/30 
>>> min interval. Hence, every 30 minutes 7 changesets will be created, each 
>>> having about 14 trees/nodes. These trees will be relatively close around a 
>>> central GPS point. The comment would be similar to "Adding 14 trees all 
>>> clustered around X GPS coordinate." Does the community have any concern or 
>>> suggestions for this? Thank you, and I look forward to hearing from you all 
>>> soon. 
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> ___
>>  talk mailing list
>>  >> talk@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
> --
> With gratitude,
> Harsha
>
> <https://colby.edu/>
>
>
> Harsha Somaya
>
>
> (She/her)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>   <https://www.instagram.com/colbycollege/>
> <https://www.linkedin.com/in/harsha-somaya-16aa7b224/>
>
>
>
>
>

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

Re: [OSM-talk] Adding automated trees to OSM

[Mateusz Konieczny via talk]

1) what is the source of tree data
2) can you give samples of tree data that would be added?
3) where it would be added
4) how you will prevent duplication with existing trees
5) which tags will be used
6) have you verified quality of data you want to add

Also, I want to echo comments from
https://community.openstreetmap.org/t/osm-tree-automation-worldwide/102197/2

Aug 8, 2023, 20:06 by hsomaya2...@gmail.com:

> Hello! Hope everything is well. I am trying to add trees to OSM in an 
> automated way via python. Of course, these are real trees that I do not want 
> to add manually. I am planning to run the script every 30 minutes to process 
> about 100 trees at a time, creating 7 changests for every run/30 min 
> interval. Hence, every 30 minutes 7 changesets will be created, each having 
> about 14 trees/nodes. These trees will be relatively close around a central 
> GPS point. The comment would be similar to "Adding 14 trees all clustered 
> around X GPS coordinate." Does the community have any concern or suggestions 
> for this? Thank you, and I look forward to hearing from you all soon. 
>
>
>
>
>
>
>
>
>
>
>
>
>
>

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

[OSM-talk] Removing opening_hours:covid19 duplicating opening_hours - worldwide bot edit

[Mateusz Konieczny via talk]

opening_hours:covid19=* tags are problematic, confusing and should not be 
promoted. 
The original idea was to have them temporary, for duration of Covid - and sadly,
 "temporary, until Covid19 goes away" has become an oxymoron. 

While say opening_hours:covid19=closed provides some info and indicates need
to resurvey location, some provide no useful info at all. 

Especially
- opening_hours:covid19=open
- opening_hours:covid19=same
- opening_hours:covid19=* with value the same as opening_hours=*  

This tags can be safely removed with an automated edit. 

And I am proposing to run such edit worldwide.

Edit would be repeated in case of new such tags appearing (if there is 
opposition
to that - this edit can be also run once and terminated).

Such bot edit is operational in USA and Poland, see

https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/removing_Covid_from_USA

https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/removing_Covid_from_Poland

For previous discussions see list at
https://wiki.openstreetmap.org/wiki/Key:opening_hours:covid19#External_links_and_discussions

Yes, this edit will cause objects to be edited. But removal of this tags is 
helpful for
anyone editing tags directly as it reduces confusion and drops irrelevant info.

This is nice especially for newbies and I believe that we should try to make 
editing
raw tag lists as accessible as possible.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] area:highway=pedestrian signalled in Inspector as an object without tag features

[Mateusz Konieczny via talk]

Yes, it is a bug in QA tool

See https://github.com/geofabrik/osmi_simple_views/issues
where you can report it to developers, though some similar issues
appear to be not fixed
(based on https://wiki.openstreetmap.org/wiki/OSM_Inspector )

Jul 18, 2023, 12:50 by onec...@hotmail.com:

> This tag is well described in a OSM wiki page
>
> https://wiki.openstreetmap.org/wiki/Tag:area:highway%3Dpedestrian
>
> The OSM Inspector tagging view reports an object labelled like this as "> 
> Name/description without important tags". The object in question is a 
> pedestrian area with a name.
> Usage per tag info is around 7.6K
> https://taginfo.openstreetmap.org/tags/area%3Ahighway=pedestrian#overview
>
> Opposed the highway=pedestrian + area=yes raises no flags
>
> A tag like area:highway=traffic_island is neither considered a problem and 
> has as of now about 15.9K use
> https://taginfo.openstreetmap.org/tags/area%3Ahighway=pedestrian#overview
>
> JOSM nor from what I recollect ID Editor are flagging area:highway=pedestrian 
> as a problem. JOSM in fact colours the closed way with the correct style 
> albeit not as an area. Does do so when adding the redundant area=yes tag 
> which it does not flag as redundant.
>
> Is this a false positive needing adding to the valid list?
>
> Rob (SekeRob in OSM world)
>

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

Re: [OSM-talk] ODbl concerns

[Mateusz Konieczny via talk]

Jul 3, 2023, 18:08 by marc_m...@mailo.com:

> Le 03.07.23 à 16:10, Cj Malone a écrit :
>
>> On Mon, 2023-07-03 at 00:05 +, Robert C Potter (DTP) via talk
>> wrote:
>>
>>> Google, Tomtom and Apple.
>>>
>>
>> Maybe it's not their preferred license, but they already use odbl data.
>>
>
> for Tomtom and Appel, of course they use it, including osm.
>
> but any reference about "google using ODBl" ?
>
https://wiki.openstreetmap.org/wiki/Google

https://wiki.openstreetmap.org/wiki/File:OpenStreetMap_data_used_by_Google_Maps.png
Use for overlay public transport data.

public transport company in Warsaw uses OSM, published
timetable/route feed with required attribution, Google attributed OSM
and Warszawski Transport Publiczny as data source___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed bulk removal of service=driveway2

[Mateusz Konieczny via talk]

Jun 25, 2023, 03:08 by marc_m...@mailo.com:

> Le 25.06.23 à 01:02, Brian M. Sperlongano a écrit :
>
>> nine months later, we see that not only has the work not gotten done, but 
>> while we all squabbled away with our pet views about automated editing, we 
>> find that we agreed to nothing, and the mapper has quietly continued to add 
>> this nonsense tag to the database unabated:
>> https://taginfo.openstreetmap.org/tags/service=driveway2#chronology
>>
>
> I don't remember anyone opposing this mechanical edit but "prefer 
> maproulette/osmose  given the number is quite manageable".
> I don't remember anyone opposing the goal of this mechanical edit (get rid of 
> highwway=service2)
>
> if someone has objected, take their opinion into account by exluding
> the area that this contributor is willing todo for a given lapse of time.
> in the meantime perform the operation outside the contributor's "manual zone".
>
> after "a certain period of time", I think it is reasonable to consider that 
> the objection has been overcome...
> I even think that this "a certain period of time" has already elapsed :
> no one is doing this on a case-by-case basis to add a precise value
> to replace this nonsense, as the chronology graph clearly shows.
>
> so, imho, go ahead next week (or 2) unless someone suddenly start
> obecting and doing it himself case-by-case
>
Given that this tag name is misleading, conflicts with established and
useful tags, is unclear, poorly defined if defined at all, it is highly 
confusing
and its existence is based on someone misunderstanding OSM tagging 
and Florida law and a lot of effort was taken to communicate with
its promoter:

- I support removal of all its presence
- given scale of damage it makes sense to do it with an automated edit
(especially as despite declaration noone reviewed it manually, at least on
scale necessary to bring numbers down)

Maybe it would be useful to check whether this tags were added to
ways without service=* tags or have they removed valid service=* values

But overall just mass removing it would be helpful already.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mateusz Konieczny via talk]

May 16, 2023, 19:22 by ajt1...@gmail.com:

> On 24/04/2023 16:57, Mateusz Konieczny  via talk wrote:
>
>>
>>
>> Apr 22, 2023, 14:10 by >> ajt1...@gmail.com>> :
>>
>>
>>> More generally, anyone with half a brain consuming OSM shop  data 
>>> (or actually, _any_ external data from _anywhere_) will  look at 
>>> the values contained in it***.
>>>
>> And that is exactly what lead to proposing thisedits - I was writing 
>> code to handle OSM
>> data and researched tagging situation. And oneof[1] effects was 
>> discovering numerous
>> cases of tags that seem to be exact duplicates ofmore standard ones, 
>> and retagging
>> them seems to clearly improve OSM data as far as Ican see
>>
>>
>
> Your continued tagfiddling here is making it much harder for  local 
> mappers to find problem values in OSM data.
>
>
> No-one's going to complain about you changing "shop=shoe" to  
> "shop=shoes" - they clearly have the same meaning, so changing the  less 
> common form to the more common form is a net benefit.
>
>
> However, your recent changes have gone much further than this,  included 
> changing shops with values you don't understand into  "shop=yes".  
>
>
For start: no such changes will be made, if requested I can revert changes
of shop=fixme to shop=yes if it is disputed.

---

But I do not really agree with some claims made here and want to explain why.

For start there is a long list of shop values which meaning I do not understand
(for example, from start of list of exactly such values:
shop=grossery, shop=towing, shop=showroom, shop=salon, shop=garage,
shop=pond, shop=consignment...)

This change was made because it was carrying no real info and was obscure value
unlikely to be found and handled by mappers.

> As an example, consider > https://www.openstreetmap.org/way/353944525>  .  It 
> was previously  "shop=retail", an unusual and rare tag that would likely 
> flag up  the interest of a passing local mapper.  You changed it to  
> "shop=yes", of which there are 180,000 of in OSM.  
>
Except people using JOSM validator*, iD, StreetComplete and other tools with 
special
support for shop=yes as feature tag. Note that this tools are more or less 
proactive
while shop with unusual values will be spotted solely by manual checks
(as listing all unusual shop values is far from helpful and requires a long
filtering to skip undocumented values, aliases, confusing values carrying some 
info)

*and therefore also Osmose, though I would not recommend this QA tool

> No-one is going to spot that as an "unusual" shop at all.  
>
Thousands/tens of thousands were fixed already, at least 10 000 would be 
definitely not spotted and not fixed if they would be just one of 10237 rare 
shop values.


> This one's actually a  charity shop, and a question about it on IRC would 
> have got that  response in only a few minutes (or a glance at 
> taginfo/overpass: > 
> https://taginfo.openstreetmap.org/tags/name=Lighthouse%20Charity%20Shop#overview>
>   / > https://overpass-turbo.eu/s/1v3j>  ).
>
> Changing "invalid" (by whatever definition) values to "valid but  
> incorrect" ones does not improve the quality of OSM, and it  actually 
> hides problems so that they are much harder to fix in the  future.
>
>
I would describe this change as "invalid unusual value" to "invalid common 
value,
supported by QA tools and more likely to be fixed or specially supported"

>
> In the case of the changesets that I've seen just now and  commented on 
> (see > https://resultmaps.neis-one.org/osm-discussion-comments?uid=3199858>  
> ) many are by longstanding contributors to OSM.  In many cases a  comment 
> on a previous changeset would have got the answer "yes,  obviously that 
> should be a shop=xyz" (rather than you just setting  it to shop=yes). 
>
>
I am doing also this - and maybe opening notes/making changeset comments first
in all such cases would be preferable.

>  I thought that after the discussion on > 
> https://www.openstreetmap.org/changeset/134837986>  that you weren't  
> going to mass-change actual values to shop=yes any more, but  clearly I 
> was wrong.
>
So you would consider any and all changes to shop=yes as making things worse?


> (for the avoidance of doubt, writing in a personal capacity)
>
the same

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

Re: [OSM-talk] (small) automated edit of name:fiu-vro -> name:vro

[Mateusz Konieczny via talk]

Apr 25, 2023, 17:06 by jules.bou...@gmail.com:

>
> 10 > years>  ago, manymultilingual country names were imported from > 
> wikipedia> /> wikidata> .
>
>
Has anyone checked licensing situation when it was done?

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

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mateusz Konieczny via talk]

Apr 22, 2023, 14:10 by ajt1...@gmail.com:

> On 21/04/2023 12:46, Mateusz Konieczny via talk wrote:
>
>> when you search for tea shop and it was marked as
>> shop=herbata ("herbata" is Polish for tea) then even a well written search 
>> tool
>> will fail to reliably find it.
>>
>
> Where something is an _absolute direct equivalent_ (but in another language) 
> it makes no sense to use a distinct term (no-one's going to suggest 
> "highway=autoweg" for motorways in the Netherlands, for example), but where 
> there are genuine differences it does make sense to try and capture that 
> somehow.
>
I agree, but what about cases where the same meaning may be represented by more
standard tags? Would you agree that for example

shop = dog_grooming → shop = pet_grooming pet = dog 
shop = dog_beauty → shop = pet_grooming pet = dog 
shop = disused:bakery → disused:shop = bakery 
shop = pharmacy → amenity = pharmacy 
shop = hookah_lounge → amenity = hookah_lounge 

are helpful edits increasing usefulness and quality of OSM data (also when
done as automated bot edit - assuming that bot went through discussion)

> This also applies where English has borrowed a word that means something else 
> elsewhere - for example, I bet all the "shop=boutique" at > 
> https://overpass-turbo.eu/s/1u5H>  don't match the OSM wiki's definition, but 
> do match the French meaning of the word "boutique", which means "shop".
>
> Even "poorly written" data consumers need to be aware of the data they are 
> consuming.  With OSM, there is no single definition**. Someone trying to 
> interpret data for the part of Togo that I linked above would surely say that 
> > https://www.openstreetmap.org/node/5001651960>  (tagged only 
> "shop=boutique") is just "some sort of shop".
>
shop=boutique seems to be a bit different problem, basically
https://en.wikipedia.org/wiki/Skunked_term that should be deprecated and not 
used

> More generally, anyone with half a brain consuming OSM shop data (or 
> actually, _any_ external data from _anywhere_) will look at the values 
> contained in it***.
>
And that is exactly what lead to proposing this edits - I was writing code to 
handle OSM
data and researched tagging situation. And one of[1] effects was discovering 
numerous
cases of tags that seem to be exact duplicates of more standard ones, and 
retagging
them seems to clearly improve OSM data as far as I can see

Every data consumers spending massive time on building own alias list for tags
and adding exceptions for say shop = disused:florist  does not seem to be a
superior solution to me - and for values listed here I think that bot edit is 
better
than asking people in changeset comments or opening notes or doing nothing.

Though maybe for

shop = vaping → shop = e-cigarette
shop = vape_store → shop = e-cigarette
shop = vape → shop = e-cigarette
shop = Vape_Store → shop = e-cigarette

asking people in changeset comments who added this tags what they think about
shop = e-cigarette would  be a good idea? Rather then retagging in this 
proposed 
edit?



[1] other results included improvements of OSM Wiki, improvements of iD presets
like https://github.com/openstreetmap/id-tagging-schema/pull/884
"stop assuming that all shop=organic are supermarkets" that just got merged
and removed certain dubious deprecation and some discussions and
recommendations to use an alternative tagging.

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

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mateusz Konieczny via talk]

Apr 20, 2023, 21:50 by marc_m...@mailo.com:

> Le 20.04.23 à 20:50, Mateusz Konieczny via talk a écrit :
>
>> For start I want to propose to people to review shop tags in their area
>> with undocumented shop values or ones documented as problematic.
>> See http://overpass-turbo.eu/s/1u2o <http://overpass-turbo.eu/s/1u2o>
>>
>
> I find that this point has no place in a mass edition and it makes
> your proposal less understandable
> making 2 topics, one with mechanical editing of cases that do not require 
> individual review and the other with a call for review of objects, would be 
> more readable
>
heh, some time ago someone complained about fixation on bot edits and ignoring
need to document/research things despite that they happened and took far more
time than bot edit itself

next time I will limit to proposed changes, without fluff

>> tags with highest use, among ones that will be retagged
>> shop = chandler with 113 uses
>>
> ..
>
> and witch fix for thoses values ?
>
mentioned later (this is just mention which higher use value are affected),
though I have withdrawn this specific case.

>
>
>> shop = local_shop → shop = yes (though looking at
>> https://www.openstreetmap.org/node/6771559662/history 
>> <https://www.openstreetmap.org/node/6771559662/history> and other - maybe
>> this import should be reverted due to dubious quality?)
>>
very dubious names (name=Retailer Shop), suspicious amount of hardware shops
( https://www.openstreetmap.org/changeset/74344116 ) with name=hardware shop
name=local shop ( https://www.openstreetmap.org/node/6787735195 ) etc, adding
shop in mass looking like import etc.

>> would it be fine to do it also with other known valid values
>> (snip '_shop', ' shop', ' store', '_store', '_products', ' products'
>>
>
> you meaning removing space and _ at both begin and end ?
> if so yes
>
Here it is about transformation of say shop=butcher_shop to shop=butcher

>> shop=patisserie
>>
>
> shop=bakery
>
not shop=pastry ?

https://wiki.openstreetmap.org/wiki/Tag:shop%3Dpastry
>> shop=bijouterie
>>
>
> shop=jewelry
>
> Regards,
> Marc
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mateusz Konieczny via talk]

Apr 21, 2023, 17:45 by a...@pigsonthewing.org.uk:

> On Fri, 21 Apr 2023 at 13:06, Mateusz Konieczny via talk
>  wrote:
>
>> Apr 20, 2023, 21:54 by a...@pigsonthewing.org.uk:
>>
>> shop = vaping → shop = e-cigarette> shop = vape_store → shop = e-cigarette
>>
>> "vape" seems to be the more widely-used term, in the UK.
>>
>> but it is the same shop type, right?
>>
>
> There is clearly a high degree of overlap. I don't use either, so
> cannot say whether there is synonymy, nor which, if any, might be a
> subset of the other.
>
>> Note that https://wiki.openstreetmap.org/wiki/Tag:shop=e-cigarette is 
>> established
>> value - do you think it is bad/misleading/unclear enough that we should have 
>> both
>> shop = vape and shop = e-cigarette despite them being synonymous?
>>
>
> I don't believe that the wiki is regarded by the community as
> authoritative. Do you have evidence that it is? Or that the particular
> page which you cie is the result of a community consensus?
>
> [other responses acknowledged]
>
Wiki should not be mindlessly obeyed but it at least tends to be right.

And if shop=e-cigarette and vape shops or vaping shops are not actually
exactly the same thing and such edit is unhelpful then it means that this
page should be significantly rewritten.

Do you have any reason to expect that this things are not the same?

My research so far confirmed that this specific page is right,
though I can ask at https://community.openstreetmap.org/ or 
tagging mailing list or US Slack or somewhere else if there is any real
chance that these are distinct shop type.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mateusz Konieczny via talk]

Apr 21, 2023, 15:08 by dieterdre...@gmail.com:

>
>
> Am Fr., 21. Apr. 2023 um 14:08 Uhr schrieb Andy Townsend <> 
> ajt1...@gmail.com> >:
>
>> On 21/04/2023 12:17, Mateusz Konieczny via talk wrote:
>>  We're actually talking about the "long tail" of shop values - genuine, 
>>  perfectly descriptive, perfectly valid values, like "shop=whisky" that 
>>  someone mentioned on IRC this morning. Changing that to something 
>>  generic without recording the extra detail somewhere (and communicating 
>>  to data consumers where that extra detail has moved to) is essentially 
>>  low-grade vandalism - removing detail from OSM.  It devalues the hard 
>>  work of the people who surveyed these things in the first place.
>>
>
>
> whole-heartedly agree, it also makes it hard to impossible to "organically" 
> introduce new classes/types via mapping, because as soon as you add it 
> someone monitoring some qa tool comes along and changes the specific value to 
> something established but not so specific or sometimes even not fitting. 
> These activities are sometimes called "gardening", but in OSM it isn't 
> completely clear what is weed and what is crop, so we better make it even 
> clearer that this kind of "gardening" should not be performed.
>
I agree!

shop=whisky (or shop=beer) should be either
- documented as valid and welcome
- handled by something like shop=alcohol alcohol=beer
- left alone

Retagging them to shop=alcohol and losing detail is not good way to spend time,
flattening to shop=yes would be obviously even worse

but we do not need (theorethical examples ahead this time)
both shop=beer and shop=beers
shop=piwo (shop=beer I guess)
shop=monopolowy (shop=alcohol)
shop=alkohol (shop=alcohol)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mateusz Konieczny via talk]

Apr 21, 2023, 14:09 by ajt1...@gmail.com:

> On 21/04/2023 12:17, Mateusz Konieczny via talk wrote:
>
>> It helps because maintaining lists of many many many rarely used meaningless 
>> values
>> in every single QA tool and validator and tool doing this is annoying at 
>> best.
>>
>
>
> For the avoidance of doubt we are NOT talking about meaningless values here.
>
In this section it was about specifically values having no info, like 
shop=retail
or shop=local_shop or shop=??? (unless it actually has some value that would
be lost? like in shop=luxury case? but that is why I am asking here)

not that this note was NOT about long tail like shop=coffins or shop=oysters
or shop=nut_store that carry some value that would be lost
by flattening it to shop=yes

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

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mateusz Konieczny via talk]

Apr 20, 2023, 21:54 by a...@pigsonthewing.org.uk:

> On Thu, 20 Apr 2023 at 19:50, Mateusz Konieczny via talk
>  wrote:
>
>> shop = chandler → shop = ship_chandler
>>
>
> In the UK at least, chandlers are more likely to cater for boats than ships.
>
removing from list then

>> shop = vaping → shop = e-cigarette> shop = vape_store → shop = e-cigarette
>>
>
> "vape" seems to be the more widely-used term, in the UK.
>
but it is the same shop type, right?
Note that https://wiki.openstreetmap.org/wiki/Tag:shop=e-cigarette is 
established
value - do you think it is bad/misleading/unclear enough that we should have 
both
shop = vape and shop = e-cigarette despite them being synonymous?

>> shop = collectibles → shop = collector
>>
>
> I have yet to see a shop that sells collectors; "collectibles" seems fine
>
the same: see https://wiki.openstreetmap.org/wiki/Tag:shop=collector
>> shop = unattended → shop = vacant
>>
>
> "Unattended" is not "vacant"; it can mean a place where one pays in an
> "honesty box", or uses vending machines.
>
good point that it should not be repeated without checking again
but currently every single use was added in meaning shop=vacant
(single mapper)

>> shop = for_rent → shop = vacant
>>
>
> Or is this a shop where one rents equipment? Or an apartment?
>
removed from list, back to asking mappers what they meant
(not sure when I will get to it, feel free to ask on changeset comments/via 
notes)

>> shop = beauty33 → shop = beauty
>>
>
> Is "Beauty33" a name or brand?
>
very unlikely, trailing 2 or 3 after actual value is a common typo for some 
reason
as one of very low use values with extra trailing debris I just fixed it
in https://www.openstreetmap.org/way/803800872/history
and removed from bot list


>> shop = herbs → shop = herbalist
>>
>
> Not necessarily the same; a herbalist does not sell cooking herbs.
>
removed from list, will ask mappers whether they meant
shop=herbalist or shop=spices (somewhere in year 2033 probably at 
current rate, so feel free to find who added it and ask them
before I will do this)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mateusz Konieczny via talk]

Apr 21, 2023, 10:17 by dieterdre...@gmail.com:

>
>
> Am Fr., 21. Apr. 2023 um 09:47 Uhr schrieb Jochen Topf <> joc...@remote.org> 
> >:
>
>> On Thu, Apr 20, 2023 at 10:11:49PM +0100, Andy Townsend wrote:
>>  > To change "shop=veryrarevalue" where it was correct to
>>  > "shop=lessrarevalue"without preserving the detail somehow loses detail 
>> from
>>  > OSM and is therefore by definition a Bad Thing.  Some of the entries on 
>> your
>>  
>>  I disagree with that blanket "Bad Thing". It is much more likely that a
>>  general map will show shop=lessrarevalue with a specific icon than
>>  shop=veryrarevalue. So if you are using shop=veryrarevalue instead of
>>  shop=lessrarevalue you might lose detail in the database, but in
>>  practice you will gain detail in actual use.
>>
>
>
> what we actually want is both, a reasonably generic/specific value for a 
> "main" class, and potentially additional tag(s) for details.
> Rather than just replacing shop=veryrarevalue with shop=moregenericvalue, we 
> should probably also add moregenericvalue=veryrarevalue
>
I agree, for example 

shop=socks vs shop=clothes clothes=socks
shop=firewood vs shop=fuel fuel=wood
shop=dog_grooming vs shop=pet_grooming pet=dog
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mateusz Konieczny via talk]

Apr 21, 2023, 11:18 by 61sundow...@gmail.com:

>
> On 21/4/23 04:50, Mateusz Konieczny via talk wrote:
>
>> bot proposal: shop values cleanup (low use values only, 1 used 250 times, 
>> three over 100 times, many used less)
>>
>> For quite long time I am trying to use OSM-based products as Google
>> Maps replacement. One of major issues are POIs (in many apects). Small
>> part of that are POIs marked but in way that makes them unusuable
>> anyway.
>>
>
>
> A rendering issue.
>
Not only a rendering issue, when you search for tea shop and it was marked as
shop=herbata ("herbata" is Polish for tea) then even a well written search tool
will fail to reliably find it.

Also, rendering cannot be expected to shop=florist shop=flower shop=flowers
shop=florist2 shop=floristt shop=floorist shop=kwiaty shop=blumen and all
other possible variants (even if we do not care about feedback to mappers)

>> shop = chandler → shop = ship_chandler
>> shop = chandlery → shop = ship_chandler
>> shop = chandlers → shop = ship_chandler
>>
>
>
> A 'chandler' is a person who posses a shop that is a 'chandlery'. Boats are 
> smaller than ships and more numerous.
>
> I would think 'shop=chandlery' is best as it applies to both boats and ships.
>
Either way I will leave it out of the list if that is not an obvious change.
(and I already removed this on)

>> shop = collectibles → shop = collector
>>
> No, shops these days do not sell people.
>
note https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcollector
and anyway risk of confusion here that shop=collector sells people seems not 
very likely
(and say https://wiki.openstreetmap.org/wiki/Tag:shop%3Dhairdresser )

I am not proposing here establishing shop=collector - for better or worse
it is established already

>> shop = unattended → shop = vacant
>> shop = for_rent → shop = vacant
>> shop = unused → shop = vacant
>> shop = vacancy → shop = vacant
>>
> These could be tagged disused:shop=* and retain the past use.
>
not really, as current tagging does not give info (and checking history does not
give info whether past equipment/sign/anything is still there, and it is not
important enough to open notes or bother people via changeset comments - 
and shop=vacant can be reliably handled as empty shop 
I could migrate to disused:shop=yes but in turn some people described 
disued:shop=
as not fitting for shop space that was never used
)

>> shop = bazaar → shop = yes
>>
>
>
> Humm bazaar = a market in a Middle Eastern or Asian country. These usually 
> consist of a number of shops .. May be better mapped as amenity=marketplace?
>
I though so - but all I checked were about individual shops. And shop=yes will 
be 
flagged for resurvey anyway

Can skip if it is in doubt

>> shop = sport → shop = sports
>>
>
> The secondary tag of 'sport=*' does  not have the 's' .. this may lead to 
> errors. I'd retain 'shop=sport'.
>
note https://wiki.openstreetmap.org/wiki/Tag:shop%3Dsports - again, I am not
proposing introducing new shop value

>> shop = foods → shop = food
>>
> Foods .. usually more than one.
>
we also have established shop=food tag

>> shop = paints → shop = paint
>>
> Paints .. usually more than one.
>
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dpaint is well established,
that is 14886 vs 10 uses right now

though if someone will convince OSM community to deprecate shop=paint and
switch to shop=paints then situation would be different

but until it happens having shop=paints is just confusing (such as questions
"this shop is tagged, why it is without icon?")

>> shop = door → shop = doors
>> shop = health_foods → shop = health_food
>> shop = locksmiths → shop = locksmith
>> shop = bathroom_furnishings → shop = bathroom_furnishing
>>
>> low use values based on review of other low use values with extra s,
>> this were not reviewed specifically
>>
>
>
> Most of thefollowing .. I'd reatin the 's' as they would sell more than one 
> kind.
>
also when we have established s-less value?

>> shop = farm_stand → shop = farm
>>
> A 'stand' is a particular structure .. different from a retail building, so 
> may require an additional tag 'building=stand' ???
>
I guess that someone can look anyway as shop=* not inside buildings...

> Hope that helps.
>
thanks for review!

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

Re: [OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mateusz Konieczny via talk]

Apr 20, 2023, 23:18 by ajt1...@gmail.com:

> On 20/04/2023 19:50, Mateusz Konieczny via talk wrote:
>
>> For start I want to propose to people to review shop tags in their area
>> with undocumented shop values or ones documented as problematic.
>>
>> See http://overpass-turbo.eu/s/1u2o
>>
>
> Reviewing "odd" tags before tagfiddling them away seems to me a very sensible 
> approach.  However, running that query locally finds, alongside a couple of 
> typos by me, lots that are very much correct, but just not on your list - 
> there are some very odd shops out there.
>

Note that I mentioned that many of them should be rather documented
(or new values covering them invented).

> To change "shop=veryrarevalue" where it was correct to 
> "shop=lessrarevalue"without preserving the detail somehow loses detail from 
> OSM and is therefore by definition a Bad Thing.  Some of the entries on your 
> list I'd definitely want to check onsite ("gun" and "firearms" is one obvious 
> one such, but there are others).
>
I agree in general, this batch is supposed to be listing 1:1 replacements
(I have similar list where I gather cases more suitable for shop=something + 
extra tag,
like shop=dog_groomer to shop=pet_groomer + pet=dog)

If you see any like this here, please let me know.

> Also, changing rare shop types into "yes" helps absolutely no-one.  If a data 
> consumer wants to handle a catch-all for "shop" they can; they don't need 
> them to be set to "yes" first.
>
It helps because maintaining lists of many many many rarely used meaningless 
values
in every single QA tool and validator and tool doing this is annoying at best.

For quite reasonable reasons JOSM developers do not want patches handling 
barely used
tags - if in 2025 someone uses say 50 instances of shop=needs_to_survey they do 
not
want to get a patch.

Also, there is no data loss whatsoever if confusing meaningless value (like 
shop=retail
or shop=??? gets changed into a standard meaningless value)

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

[OSM-talk] bot proposal: shop values cleanup (low use values only, 1 used 250 times, three over 100 times, many used less)

[Mateusz Konieczny via talk]

bot proposal: shop values cleanup (low use values only, 1 used 250 times, three 
over 100 times, many used less)

For quite long time I am trying to use OSM-based products as Google
Maps replacement. One of major issues are POIs (in many apects). Small
part of that are POIs marked but in way that makes them unusuable
anyway. This is also problems for mappers, especially newbies, confused
for example why nice icon is not appearing on some (and problem is for
example shop=hair_dresser vs shop=hairdresser).


For start I want to propose to people to review shop tags in their area
with undocumented shop values or ones documented as problematic.

See http://overpass-turbo.eu/s/1u2o

For each case either shop should be either


(1) retagged and shop=* changed
(2) such shop value should have its value documented at OSM Wiki (I
documented some, see for example
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcatalogue ) (3)
sometimes new value should be invented, documented and shop=* retagged
to it


https://community.openstreetmap.org/c/general/tagging/70 may be useful
for discussing new shop=* values (local discussion channel may be also
useful, but I strongly recommend asking wider community about new
values to avoid avoidable confusion). Some people go through
https://wiki.openstreetmap.org/wiki/Proposal_process - but
discussion/review step is the most useful one and you can use just this.


Tagging mailing list also exists and can be used for discussing new
tags.


https://wiki.openstreetmap.org/wiki/Creating_a_page_describing_key_or_value
may be also useful.


But some of shop values can be safely automatically replaced by another
shop value. For example shop=shoe can be safely migrated to shop=shoes
without human review.


-


Getting to the bot edit itself (and I want to note that I am more
excited about finding missing shop values and documenting them and
adding them to presets/documentation than I am about retagging):


So I am proposing to extend
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/fixing_malformed_shop_tags
by adding more tag replacements.


Please let me know if any of replacements here are dubious and values
require human review/survey to be replaced or are actualy valid. I know
that list is long, so if someone wants to review but needs more than 2
weeks - please write and I can wait for longer.


Also, let me know if anyone would want to get list of affected objects
for review or manual retagging or listing of edits that added this tags
and so on.


tags with highest use, among ones that will be retagged 
shop = chandler with 113 uses
shop = stationary with 116 uses
shop = hardware_store with 60 uses
shop = lamps with 250 uses
shop = knife with 60 uses
shop = unattended with 87 uses (see 
https://www.openstreetmap.org/changeset/130756523 - this mapper added
all* of them and is fine with such change 
*including one as a typo, that is why another mapper may
be credited with it)
shop = local_shop with 53 uses
shop = retail with 145 uses

shop = chandler → shop = ship_chandler
shop = chandlery → shop = ship_chandler
shop = chandlers → shop = ship_chandler
shop = stationary → shop = stationery
shop = hardware_store → shop = hardware (Note: there are weird clusters of
shop=hardware in some places, but that is a bit different story -
I suspect some systematic mistake or bad mapping, unless there are African
towns where 1/4 of all shops are really shop=hardware - though either way
local on the ground survey seems needed)
shop = vaping → shop = e-cigarette
shop = vape_store → shop = e-cigarette
shop = vape → shop = e-cigarette
shop = Vape_Store → shop = e-cigarette
shop = lamps → shop = lighting
shop = lamp → shop = lighting
shop = Lighting_Shop → shop = lighting
shop = knife → shop = knives
shop = collectibles → shop = collector
shop = unattended → shop = vacant
shop = for_rent → shop = vacant
shop = unused → shop = vacant
shop = vacancy → shop = vacant
shop = local_shop → shop = yes (though looking at
https://www.openstreetmap.org/node/6771559662/history and other - maybe
this import should be reverted due to dubious quality?)
shop = retail → shop = yes
shop = Retail → shop = yes
shop = Retails → shop = yes
shop = generic → shop = yes
shop = ??? → shop = yes
shop = retailer → shop = yes
shop = retails → shop = yes (again 
"SUZA Indusrtial training Resillence Academy" but this suspect data
will be more detectable as shop=yes - see say
https://www.openstreetmap.org/node/6771699918)
shop = misc → shop = yes
shop = commercial → shop = yes
shop = Generic shop → shop = yes
shop = true → shop = yes
shop = Retail Shop → shop = yes  
shop = miscellaneous → shop = yes 
(second_hand / variety_store / catalogue / department_store etc may fit)

shop = miscelanea → shop = yes
shop = bazaar → shop = yes
shop = samoobsługowy → shop = yes (Polish translation)
shop = fixme → shop = yes 
shop = egg → shop = eggs 
(both undocumented for now, but 

Re: [OSM-talk] mapboox improve the (proprietary database used as en overlay) map

[Mateusz Konieczny via talk]

>From legal point of view it depends on specifics, but yes it can be legal to
render using odbl+proprietary data.

See 
https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Horizontal_Map_Layers_-_Guideline
Warning: I am not a lawyer.


Apr 7, 2023, 14:21 by marc_m...@mailo.com:

> Hello,
>
> following a discussion on the mailing list talk-fr,
> mapbox "improve the map" now feeds their proprietary database,
> the one that is displayed on top of the osm
>
> is it acceptable in terms of licensing to render using odbl+proprietary data?
>
> ethically it's obviously very bad to appropriate user contributions
> in this way, does anyone have a contact at their end to try and get
> them to return to more ethical behaviour?
> on talk-fr, no one from mapbox has replied since this behaviour
> was pointed out
>
> Regards,
> Marc
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] Proposed automatic replacements of multiple surface values - the third edition (review welcomed!)

[Mateusz Konieczny via talk]

I am not planning to propose automatically migrating ones where situation 
remains unclear.


Mar 27, 2023, 13:21 by dieterdre...@gmail.com:

>
>
> Am Mo., 27. März 2023 um 10:32 Uhr schrieb David Haberthür <> 
> em...@davidhaberthuer.ch> >:
>
>>
>> Ciao
>>
>>
>>> I added
>>>     # translating German
>>>     'holz': 'wood',
>>>     'schotter': 'gravel',
>>>     'Gras_Laub': 'grass',
>>> to candidate list for the next one
>>>
>>
>> I’m my (Swiss German) opinion "Schotter" is much bigger than gravel, which 
>> is translated to "Kies".
>> Gravel might be passable by bike, Schotter is the foundation under railways 
>> tracks.
>> I wouldn’t want to ride my bike over Schotter!
>>
>
>
> there was a discussion recently about several of these terms, including 
> pebbles and gravel. 
> The term "Kies" usually means rounded, natural pebbles as can be found in 
> rivers, while there is also "gebrochener Kies" which means crushed stone. 
> "Schotter" also means crushed stone. You correctly point out that the largest 
> grain size is very relevant for usability, you can't cycle on 63mm Schotter, 
> but you can on 16mm (still not desirable, but a huge difference to 63mm). 
> There are various terms, and they are sometimes colloquially used with a 
> different meaning than the definition used by specialists, and they may be 
> imprecise without adding the grain sizes, so there will probably never be an 
> unambiguous translation in a single word.
>

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

Re: [OSM-talk] Proposed automatic replacements of multiple surface values - the third edition (review welcomed!)

[Mateusz Konieczny via talk]

Mar 29, 2023, 00:15 by marc_m...@mailo.com:

> Le 28.03.23 à 19:38, Mateusz Konieczny via talk a écrit :
>
>> If someone speaking French would prepare pairs from-to they confirmed
>> to be basically 100% reliable pairs (without some tricky cases where
>> given word could mean both surface=asphalt and surface=gravel)
>> then I could help replacing them.
>>
>
> I'll translate the list, it's not that the issue
>
> what i was proposing is to use the translations already done
> in the wiki instead of redoing the list in a new place.
> especially since there are probably also values in German,
> Dutch and any other language in the world
>
Well, in case of running bot edit I need to provide 
old value - new value pairs.

So yes, if such list would be used in bot it needs to be done
in a machine readable form.

(for rare values it may make more sense to track down
this single uses and fix them or ask authors,
Overpass Turbo is useful here)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed automatic replacements of multiple surface values - the third edition (review welcomed!)

[Mateusz Konieczny via talk]

If someone speaking French would prepare pairs from-to they confirmed
to be basically 100% reliable pairs (without some tricky cases where
given word could mean both surface=asphalt and surface=gravel)
then I could help replacing them.

But I do not feel comfortable to do it when I do not speak French at all
and would really on dictionary.


Mar 28, 2023, 02:28 by marc_m...@mailo.com:

> Le 24.03.23 à 19:56, Mateusz Konieczny via talk a écrit :
>
>> Is any of values below has blatantly clear meaning in your language matching
>> some established or missing surface value? And would be also eligible for 
>> such fixing?
>>
>
> looking at https://taginfo.openstreetmap.fr/keys/surface#values
> yes there are indeed 118 french words that should be converted
> see below for the list
>
> due to the number, I wonder if it wouldn't be easier to first do this:
> convert everything to lower case and underscores to space
> convert "and" to ";"
> see if the resulting value is the one listed as the first bold word on the 
> page https://wiki.openstreetmap.org/wiki/Template:FR:Map_Features:surface
> and build a converting table for remain values
>
> (and the same for any language)
>
> the list of value in french found via taginfo fr
>  terre
>  herbe
>  cailloux
>  gazon_ras
>  goudron
>  sable
>  bitume
>  terre_battue
>  pierre
>  bois
>  macadam
>  sable_et_terre
>  gazon_tres_ras
>  normal
>  sol
>  pavés
>  pelouse
>  Terre
>  resine
>  gravier
>  gazon
>  charbon
>  béton_poreux
>  béton_bitumineux
>  béton
>  terre_et_sable
>  synthétique
>  plastic_grid
>  parquet
>  multiple
>  herb
>  ciment
>  calcaire
>  cailloux_et_galets
>  terre_goudron
>  terre_et_herbe
>  "terre,_cailloux"
>  synthetique
>  plastique
>  pierres
>  herbe_synthétique
>  Herbe_et_cailloux
>  graviers
>  gravier0
>  gazon_synthétique
>  Chemin_de_terre_compactée
>  carrelage
>  brique
>  boue
>  bitumen
>  béton_désactivé
>  banquettes
>  banc_de_sable
>  terr_et_pierre
>  terre_touvenant
>  terre/sable
>  terre_roche
>  terre_pierres
>  "terre_naturelle,_argileuse"
>  terre_humide
>  terre;herbe
>  terre_goudrons
>  terre_et_rochers
>  terre_et_pierres
>  terre_et_pierre
>  terre_et_gravier
>  terre_cailloux
>  terre_boue
>  "terre,_boue"
>  terre_batue
>  terre2
>  terrain_synthétique
>  terrain_en_herbe
>  terrace
>  tere
>  Sable
>  rocheux/felsig
>  rocher
>
> "revêtement_compact,_mélange_majoritaire_en_gravier_ou_pierre,_avec_des_matériaux_mous_tels_que_sable_ou_argile"
>  polyuréthane
>  plastique_glissant
>  planches
>  pierres_sèches
>  pierre_et_terre
>  pelouse_naturelle
>  pelouse_et_terre
>  Parking non goudronné
>  neige
>  Mousse
>  métal
>  liège
>  herbe_naturel
>  herbe_et_sable
>  "gravillons,_béton"
>  gravillons
>  gravillon
>  graviers_et_terre
>  gourdon
>  goudronné
>  enrobes
>  enrobé
>  empierrée
>  diverses
>  compact1ée
>  chemin_galet
>  chemin_en_terre
>  chemin_de_terre_et_herbe
>  chemin_de_terre_et_graviers
>  chemin_de_terre
>  "champs,_herbe"
>  caoutchouc
>  cailloux_et_terre
>  caillou_+_riviere_qui_coule_dedans
>  bois_et_goudron/plastique
>  blocs_de_roche
>  béton_bois
>  béton_bitumimeux
>  artificiel
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] Proposed automatic replacements of multiple surface values - the third edition (review welcomed!)

[Mateusz Konieczny via talk]

Mar 24, 2023, 22:33 by facebook_140f8d4e-9d8f-4d51-a5a7-320f53afc...@vollbio.de:

>
> Hi
>
>
> Thanks for the comprehensive explanation. Here some answers:
>
> This first part makes sense to me.
>
Thanks!

> Regarding your questions to document previous values, I wouldpropose 
> to use "material=..." as mentioned under: > 
> https://wiki.openstreetmap.org/wiki/Key:surface#See_also
>
which "previous values" you mean?
> "tierra" and "terra" ... the answer is obvious: "ground".
> Also, for other languages, which are not clear, I would usethe 
> "material=..." key and just put "surface=unpaved", to be onthe safe 
> side.
>
If unclear, I will just not touch it (especially as some unclear may describe 
paved surface)
> Btw. I saw some German word: holz=>wood,schotter=>gravel, 
> verdichtet=>paved (it means"compacted"), Gras/Laub=>grass,
> pflasterstein=>cobblestones
>
Could surface=verdichtet be actually surface=compacted?

Is surface=pflasterstein a surface=cobblestone (underdefined one) or
can it be assumed to be in every single case surface=sett or 
surface=unhewn_cobblestone ?

See https://wiki.openstreetmap.org/wiki/Tag:surface%3Dcobblestone

I added
    # translating German
    'holz': 'wood',
    'schotter': 'gravel',
    'Gras_Laub': 'grass',
to candidate list for the next one (I will also review is any of them typically 
wrong
- using aerial images - and is connected to any obvious issues not already
automatically detectable)

> Regarding regular reruns of this, I would put some qualitygates into 
> that, like:
> Were previous automatic corrections reverted and why?
> Does a certain type reoccur often and why?
> Do new categories appear and should they become official?
>
I inspect some sample of bot edits and before I run it I get info how many will 
be changed
- so in case of large volume of cases (re)appearing I would investigate what is 
going on.

I am also monitoring PMs and changeset comments on bot account - and I think
that someone thinking that it made a bad edit would write.

Does it seem enough for you? (I can also run this edit once and once enough new
or repeated cases gather then appear here again with similar listing)


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

Re: [OSM-talk] Automated Edit - Bus stops status link & Bus lines timetable link (Tenerife)

[Mateusz Konieczny via talk]

 

>> This scripts exist already, and were writtenmultiple times already
>> one more would not change much
>>
>
> @Mateusz: Any help regarding the script would be greatly  appreciated. I 
> have worked with databases before (PostgreSQL,  MySQL, SAS) and am aware 
> of the pitfalls.
>
>
> Best, Klaus
>
>
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account#Active_tasks
 lists my bot edits, what includes source code




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

Re: [OSM-talk] Automated Edit - Bus stops status link & Bus lines timetable link (Tenerife)

[Mateusz Konieczny via talk]

Mar 24, 2023, 20:40 by valin...@gmx.net:

>
>
>> What do you think about this idea? What would be the best way to achieve 
>> this in an automated way?>>  
>>
>
> If these urls are following a fixed scheme like you mentioned then I see no 
> need to add the urls. There is no need to store them if you can create them 
> from a combination of the hard coded
>
Well, as template for links is not present then it is not a good reason against 
it.
I would be more concerned whether links will be stable or change format soon.

> It requires knowledge how databases work in general, why normalization & 
> abstraction is important and at last you need to be developer.
>
OSM map database is not normalized (at least as far as tags are concerned) 

> is actually a good thing as it an obstacle to not make it too easy for 
> "children" (in double quotes for reasons) and protects us from edit spaming. 
>
this really could be phrased better without making it insulting
and it does not really protect as strongly, though maybe it could be worse

> This is the reason why I currently abstain from writing a python3 script to 
> make it easier to write editing bots.>   
>
This scripts exist already, and were written multiple times already
one more would not change much
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] proposed bot edit for surface=granite, surface=marble and similar

[Mateusz Konieczny via talk]

If anyone has opinion either way (this edit should be done/this edit should not 
be done)
that is a good moment to express them - before I will make it.

Mar 14, 2023, 20:26 by talk@openstreetmap.org:

> There is noticeable (but not very high) number of surface=granite /
> surface=marble and other similar tagging type of stone into surface tag.
>
(...)

> So I am proposing following replacements:
>
> surface = granite → material = granite
> surface = granit → material = granite
> surface = marble → material = marble
> surface = sandstone → material = sandstone
> surface = laterite → material = laterite
> surface = limestone → material = limestone
> surface = limerock → material = limerock
> surface = chalk → material = chalk
> surface = basalt → material = basalt
>
> Edits will be not made where there is already material /
> paving_stones:material tag with a mismatching info.
>
> Edits will be made where such surface tags are present now or will
> appear in future.
>

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

[OSM-talk] Proposed automatic replacements of multiple surface values - the third edition (review welcomed!)

[Mateusz Konieczny via talk]

I proposed some time ago to replace some surface values.

The initial script run was recently done,.

Edit is documented at
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/fixing_malformed_surface_tags

I propose to expand this by replacing also surfaces listed below.

Please comment if any of proposed replacements are dubious in any way and
do not qualify for a replacement with an automated edit.

Edit will affect around 2500 objects.

If anyone wants I can help them to find affected objects or present listing of
edits which added this tags or list people who added this values onto currently
tagged osm objects.

Samples of this values were tested.

Tried to use them as detectors of bogus data, neither were really useful for 
this purpose.

So I am proposing following changes

surface = unpaved33 → surface = unpaved

# added by TendaiNkomo - see https://www.openstreetmap.org/changeset/67017223 
where I tried to contact them
surface = unpaved_minor → surface = unpaved
surface = unpaved_major → surface = unpaved

# surface=dirt would be incorrect, "dirt road" refers also to surface=compacted
surface = dirt road → surface = unpaved

# https://www.openstreetmap.org/changeset/48215497 
https://www.openstreetmap.org/changeset/67215079 
https://www.openstreetmap.org/changeset/25703937
surface = cobbled → surface = cobblestone

# apparently autocomplete accident
surface = un → surface = unpaved
surface = compact → surface = compacted

# low use, detected via detector of values very likely to by typoed or having 
shiFt accident
# still verified whether indicating obvious issues
surface = Concrete → surface = concrete
surface = GRAVEL → surface = gravel
surface = Compacted → surface = compacted
# surface=bamboo is not documented, this replacement is still useful
surface = Bamboo → surface = bamboo

# also reviewed, no special comments
surface = unsealed → surface = unpaved
surface = synthetic_grass → surface = artificial_turf
surface = asphalt_no_1 → surface = asphalt
surface = asphalt deg 3 → surface = asphalt
surface = planks → surface = wood
surface = cobblestone_flattened → surface = cobblestone:flattened
surface = Hard_Court → surface = hard_court
surface = groun → surface = ground
surface = groud → surface = ground
surface = groundw → surface = ground
surface = ground2 → surface = ground
surface = paved2 → surface = paved
surface = gravel2 → surface = gravel
surface = asphalt22 → surface = asphalt
surface = concrete2 → surface = concrete
surface = unpaved3 → surface = unpaved
surface = unpaved22 → surface = unpaved
surface = asphalt2 → surface = asphalt
surface = compacted_gravel → surface = compacted
surface = unsurfaced → surface = unpaved
surface = plank → surface = wood
surface = wooden_planks → surface = wood
surface = wood_chip → surface = woodchips

# more surface values with trailing letter/number
# especially 2 and q are common - missclick of tab button? Similarly 1 and 3
# and c - missclick of ctrl+c?
# and C - missclick of ctrl+c and using shift+c?

surface = unpavedc → surface = unpaved
surface = grounds → surface = ground
surface = gravelc → surface = gravel
surface = unpaveds → surface = unpaved

# I have not reviewed this values specifically - but I reviewed many other 
single-extra-letter-cases
# all values here are low use, some may be used once
# I expect that reliability here will be the same as sample which I verified 
based on aerial images
# for obvious mistake or indicators of problems
surface = unpaved* → surface = unpaved
surface = asphalt3 → surface = asphalt
surface = asphaltd → surface = asphalt
surface = asphalt; → surface = asphalt
surface = asphalts → surface = asphalt
surface = asphaltz → surface = asphalt
surface = asphaltc → surface = asphalt
surface = asphaltN → surface = asphalt
surface = asphaltn → surface = asphalt
surface = asphaltl → surface = asphalt
surface = asphalth → surface = asphalt
surface = asphaltC → surface = asphalt
surface = asphaltu → surface = asphalt
surface = asphalt- → surface = asphalt
surface = asphaltr → surface = asphalt
surface = asphalt1 → surface = asphalt
surface = concretef → surface = concrete
surface = concretev → surface = concrete
surface = concrete6 → surface = concrete
surface = concretee → surface = concrete
surface = concretew → surface = concrete
surface = concretec → surface = concrete
surface = concrete` → surface = concrete
surface = concreteo → surface = concrete
surface = concrete5 → surface = concrete
surface = concretex → surface = concrete
surface = concreted → surface = concrete
surface = concrete3 → surface = concrete
surface = concretem → surface = concrete
surface = concrete- → surface = concrete
surface = concreteŒ → surface = concrete
surface = sand1 → surface = sand
surface = sand] → surface = sand
surface = sandw → surface = sand
surface = sand` → surface = sand
surface = sand- → surface = sand
surface = sands → surface = sand
surface = sand3 → surface = sand
surface = sandq → 

Re: [OSM-talk] Duplicate Buildings

[Mateusz Konieczny via talk]

Mar 16, 2023, 14:54 by sainokawara.sisyp...@gmail.com:

> By the way, it was extremely difficult to detect & delete these "extra" Ways 
> manually using JOSM.
>
Have you tried https://josm.openstreetmap.de/wiki/Help/Dialog/Validator ?

Have you disabled validator warnings about duplicated ways?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] proposed bot edit for surface=granite, surface=marble and similar

[Mateusz Konieczny via talk]

Mar 15, 2023, 10:21 by dieterdre...@gmail.com:

> I'd prefer "surface:material" compared to "material", it is in modest use 
> (800) > https://taginfo.openstreetmap.org/keys/surface%3Amaterial
> because the "highway" represents not just the surface.
>
material represents primary material of object and surface of road/path/square
seems to fit here well.

What would be benefit for surface:material over material anyway?
Which other tags would be added that are infeasible with material?
If someone really wants they can add surface:curb:left=granite 
and surface:cycleway:left:curb:right=concrete anyway to
highway=residential material=granite (not advocating or advising mapping curb 
material here).

>
> Generally, maybe another subtagging step like "surface:material=stone" 
> "stone=granite" could make sense? It could also be used for material and 
> similar tags:
> material=stone and stone=granite
>
not really planning to invent such tagging, I just want to solve problem
of material tags squatting surface key without loss of what someone mapped.
But I do not plan to spend time on inventing elaborate tagging schemes
for something that I am not mapping, not using and not planning either.

Especially as entire use of surface:material and stone=* is much smaller
than what will[1] be retagged by even this tiny bot edit.

[1]Unless people will protest against it and there will be no consensus to run 
it.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] proposed bot edit for surface=granite, surface=marble and similar

[Mateusz Konieczny via talk]

There is noticeable (but not very high) number of surface=granite /
surface=marble and other similar tagging type of stone into surface tag.

---

There was some discussion on
https://community.openstreetmap.org/t/type-of-stone-in-surface-surface-granite-and-similar/9424

---

Surface=granite blocks distinguishing between

surface=paving_stones
surface=sett
surface=unhewn_cobblestone
surface=rock
etc

surface=granite may be any of following:

Exposed raw rock (surface=rock / surface=raw_rock)
   https://wiki.openstreetmap.org/wiki/File:Half_Dome_ropes_4.jpg

Natural stone machined into a flat surface (surface=paving_stones)
   
https://commons.wikimedia.org/wiki/File:Pretty_natural_stone_used_for_paving.jpg

Flattened stone, but still not entirely flat and not covering entire
surface (surface=sett)
https://commons.wikimedia.org/wiki/File:Granite_Setts.jpg

Raw cobblestone of natural, uncut, rounded stones.
(surface=unhewn_cobblestone)
https://commons.wikimedia.org/wiki/File:Ancient_road_surface.jpg

Stones or plates individually arranged in a row, allowing to walk on,
surrounded by an unpaved medium such as grass or water
(surface=stepping_stones)
https://commons.wikimedia.org/wiki/File:River_Rothay_stepping_stones_120508w.jpg
https://wiki.openstreetmap.org/wiki/File:Stepping_stones_-_geograph.org.uk_-_832601.jpg

surface=gravel and surface=pebblestone and maybe some other would be
valid.

(note: specific photos above may be not necessarily depict granite, but
`surface=granite` could also take such forms) (if you have a better
photo then improving
https://wiki.openstreetmap.org/wiki/Tag:surface%3Dgranite would be
highly welcome)

---

So instead of surface=granite using material=granite would be
preferable.

For example instead of:
highway=pedestrian surface=granite

following tagging would be better:
highway=pedestrian material=granite

This makes space for tagging surface=sett or surface=unhewn_cobblestone
or surface=paving_stones etc

I think that it would be much better to tag and such migration can be
done with an automatic edits.

So I am proposing following replacements:

surface = granite → material = granite
surface = granit → material = granite
surface = marble → material = marble
surface = sandstone → material = sandstone
surface = laterite → material = laterite
surface = limestone → material = limestone
surface = limerock → material = limerock
surface = chalk → material = chalk
surface = basalt → material = basalt

Edits will be not made where there is already material /
paving_stones:material tag with a mismatching info.

Edits will be made where such surface tags are present now or will
appear in future.

There are also surface=steel, surface=aluminium and surface=iron but
these are trickier and not proposed to be edited here (I guess that
leaving surface=metal would be useful and surface=iron should only be
changed to surface=metal as it is really unlikely to be correct)

Why it is useful? It helps newbies to avoid becoming confused. It
protects against such values becoming established. Without drudgery
that would be required from the manual cleanup. It also makes easier to
add missing surface= values

Why automatic edit? I have a massive queue (in thousands and tens of
thousands) of automatically detectable issues which are not reported by
mainstream validators, require fixes and fix requires review or
complete manual cleanup.

There is no point in manual drudgery here, with values obviously
fixable.

This values here do NOT require manual overview. If this cases will
turn out to be an useful signal of invalid editing than I will remain
reviewing nearby areas where bot edited.

Yes, bot edit WILL cause objects to be edited. Nevertheless, as result
map data quality will improve.

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

Re: [OSM-talk] Proposed automatic replacements of multiple surface=* and shop=* values (review welcomed!)

[Mateusz Konieczny via talk]

Feb 27, 2023, 08:19 by 61sundow...@gmail.com:

>
>
>
> On 26/2/23 20:59, Mateusz Konieczny via  talk wrote:
>
>>
>>
>>
>> Feb 26, 2023, 10:20 by >> 61sundow...@gmail.com>> :
>>
>>>
>>> On 26/2/23 06:08, Mateusz Konieczny via talk wrote:
>>>
>>>> shop = opał → shop = fuel
>>>>
>>>
>>>
>>> Opal is also a gemstone, Australia being a leading source.  It is 
>>> also a fuel in Australia ... but that would not be sold  in shops 
>>> but petrol stations.
>>>
>> note that it is not opal, it is opał with >> 
>> https://en.wikipedia.org/wiki/%C5%81>>  at the end
>>
>
> Not in Australia. Opal with an L. 
>
>
And these will not be affected by my proposed edit (I have not
listed this replacement, right?)

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

Re: [OSM-talk] Proposed automatic replacements of multiple surface=* and shop=* values (review welcomed!)

[Mateusz Konieczny via talk]

Feb 26, 2023, 10:20 by 61sundow...@gmail.com:

>
> On 26/2/23 06:08, Mateusz Konieczny via talk wrote:
>
>> shop = opał → shop = fuel
>>
>
>
> Opal is also a gemstone, Australia being a leading source. It is also a fuel 
> in Australia ... but that would not be sold in shops but petrol stations.
>
note that it is not opal, it is opał with https://en.wikipedia.org/wiki/%C5%81 
at the end

>> shop=map -> shop=maps
>> or maybe it would be better to change in opposite direction?
>> it is not too late as it is a rarely used tag
>>
> There are few shops selling maps these days .. unfortunately.
>
still, managed to find and map two :)

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

Re: [OSM-talk] Proposed automatic replacements of multiple surface=* and shop=* values (review welcomed!)

[Mateusz Konieczny via talk]

Feb 25, 2023, 22:50 by a...@pigsonthewing.org.uk:

> On Sat, 25 Feb 2023 at 19:08, Mateusz Konieczny via talk
>  wrote:
>
>> shop = Bag_shop → shop = bag
>>
>
> Is this a shop that sells bags, or "things by the bagfull"?
>
>> shop = watch → shop = watches
>>
>
> This could plausibly mean watch as in "monitor" - in other words
> "please watch for developments".
>
Not really convinced that either applies, but I will not replace them 
automatically and iff I will decide to use my hobby time in this way
I will ask people who added them what they intended (or change 
manually based on the context).

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

Re: [OSM-talk] Proposed automatic replacements of multiple surface=* and shop=* values (review welcomed!)

[Mateusz Konieczny via talk]

Feb 25, 2023, 23:11 by dieterdre...@gmail.com:

>
>
> Am Sa., 25. Feb. 2023 um 22:07 Uhr schrieb Mateusz Konieczny via talk <> 
> talk@openstreetmap.org> >:
>
>>
>>
>> So shop = laundromat → shop = laundry + self_service=yes would be needed?
>>
>
>
>
> it could be seen as equivalent, personally I would see a case for different 
> main tags because these are quite different features, better not intervene in 
> an automatic way (although admittedly there is 1000 times less usage for 
> laundromat one could also say that 40 laundromats are not worth discussing). 
> Maybe set up a proposal for laundromat? For 25% of all laundries there is 
> "self_service" information (and 85% of these are self service=yes which could 
> suggest that the default is self_service=no). I'd rather go for 
> amenity=laundromat (it has 7 uses now)
>
OK, I will not change this

> For 25% of all laundries there is "self_service" information 
> (and 85% of these are self service=yes which could suggest that the default 
> is 
> self_service=no)

Note that over 2900 self_service tags were added by StreetComplete
(checking distribution of this edits may give hint how many shop=laundry are 
laundromats)

See AddSelfServiceLaundry in 
https://piebro.github.io/openstreetmap-statistics/#6773___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed automatic replacements of multiple surface=* and shop=* values (review welcomed!)

[Mateusz Konieczny via talk]

Feb 25, 2023, 22:00 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 25 Feb 2023, at 20:13, Mateusz Konieczny via talk 
>>  wrote:
>>
>> There is no point in manual drudgery here, with values clearly
>> replaceable by better matches.
>>
>> This values here do NOT require manual overview. If this cases will
>> turn out to be an useful signal of invalid editing than I will remain
>> reviewing nearby areas where bot edited.
>>
>
>
> forgot to say I applaud to this initiative, thank you for tackling this and 
> documenting the process. I agree that there are many cases that can be fixed 
> automatically, and your list shows good examples, but of course we must be 
> very careful to not iron everything flat when there might be subtle 
> differences. This is why it is important to have many eyes on such bot edits 
> and document the details.
>
BTW, if someone would prepare similar list for some key 
(replacements of value A by value B within the same key, without 
any additional checks/replacements/conditions,
with explanations why such replacements are obviously useful), 
AND they confirmed that this tags are not very good at indicating places
where intensive cleanup/reverts are needed
AND list would be in general reasonably reviewed
AND publish bot proposal on this mailing list, like this one
then I can run such edit.

Preparing it is time-consuming, running bot itself is easy.

(lets say that offer is active for the next 30 days so noone will try this in 
say 6 years
from now, may be revoked earlier if people will try to post really badly 
prepared lists)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Proposed automatic replacements of multiple surface=* and shop=* values (review welcomed!)

[Mateusz Konieczny via talk]

Feb 25, 2023, 21:14 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 25 Feb 2023, at 20:13, Mateusz Konieczny via talk 
>>  wrote:
>>
>> shop = laundromat → shop = laundry
>>
>
>
> I think the laundromat is about a diy place while shop=laundry can also be a 
> service where you drop off your laundry and they’ll take care of everything. 
> Wiki suggests adding self_service=yes for the former.
>

So shop = laundromat → shop = laundry + self_service=yes would be needed?

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

Re: [OSM-talk] Proposed automatic replacements of multiple surface=* and shop=* values (review welcomed!)

[Mateusz Konieczny via talk]

Note: I want to mention for context that this was preceded with

> If you reached here: I have some question about shop values that
> I am NOT proposing to edit right now.


Feb 25, 2023, 21:27 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>
>> On 25 Feb 2023, at 20:13, Mateusz Konieczny via talk 
>>  wrote:
>> shop=eggs -> shop=food food=eggs
>>
>> maybe such migration would be a good idea?
>> having top value for every single shop type specializing in a given food
>> seems hopeless - we would need shop=pumpkin, shop=apples, shop=basil,
>> shop=pierogi...
>> That is nighmarish for data consumers.
>>
>
>
> maybe for these pumpkin or apple or basil shops a more generic category 
> (there is > https://wiki.openstreetmap.org/wiki/Tag:shop%3Dfarm>  ) can make 
> sense, with a subtag for the kind of produce they sell, but food is very 
> important for all of us and we do indeed mostly tag dedicated classes for 
> these, like bakery, butcher, greengrocer, wine, deli, supermarket, 
> convenience, so if there are dedicated pierogi shops I would tag them as 
> this. You would not want to find them if you search for “food”, you search 
> for pierogi if you wanted to find them. There is shop=pasta where I think 
> pierogi could fit, “food” is too generic.
>
Shops selling pierogi are definitely not shop=pasta

and I was thinking about shop=food food=pierogi or something similar
for places like https://www.openstreetmap.org/node/3033173319

maybe shop=food main_food=pierogi to avoid food key ending with
multiple uses?

or shop=prepared_meals (almost ready for eating but requiring heating/boiling)

there is shop=frozen_food not fitting shops selling food that is prepared and 
not
frozen
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Proposed automatic replacements of multiple surface=* and shop=* values (review welcomed!)

[Mateusz Konieczny via talk]

I proposed some time ago to replace some surface values.

The initial script run was recently done, after waiting for a potential 
feedback.
Edit is documented at
https://wiki.openstreetmap.org/wiki/Mechanical_Edits/Mateusz_Konieczny_-_bot_account/fixing_malformed_surface_tags

I propose to expand this by replacing also surface and shop tags listed below.
Shop edit would get own wiki documentation page, surface replacements would
be added to existing page and it would link to both discussions.

Please comment if any of proposed replacements are dubious in any way and 
do not qualify for a replacement with an automated edit.
List previously was really short, this one is longer - let me know if either 
format is preferred.
Either way, I will not make any bot edits before 11 III in my time zone.
(I wait for about two weeks after proposing bot edits, as usual).

overpass query listing where surface would be edited: 
https://overpass-turbo.eu/s/1rKh - 2084 objects right now



surface replacements:

surface = artificial_grass → surface = artificial_turf
See 
https://community.openstreetmap.org/t/surface-artificial-grass-vs-surface-artificial-turf/6295

surface = barkchips → surface = woodchips
surface = bark_wood → surface = woodchips
opened notes for some of them and some turned out to not be even made
of actual bark when checked by local mappers...

something went wrong with autocomplete:
surface = as → surface = asphalt
surface = asp → surface = asphalt
surface = grav → surface = gravel
surface = pebb → surface = pebblestone

seems like name in a different language, but with a clear meaning
surface = asfalto → surface = asphalt

in several languages "beton" is word for concrete, so far I was opening notes
for a long time and asking in changesets and in every single case it was a 
clearly correct replacement
surface = beton → surface = concrete

translating from Polish
surface = ziemna → surface = earth

we do not have unpaved_dirt either
surface = unpaved_gravel → surface = gravel

clear typos
surface = ashpalt → surface = asphalt
surface = Asphalt → surface = asphalt
surface = ashalt → surface = asphalt
surface = aspahlt → surface = asphalt
surface = ashphalt → surface = asphalt
surface = paving_stone → surface = paving_stones
surface = Paving Stone → surface = paving_stones
surface = paving_stoness → surface = paving_stones
surface = wood_chips → surface = woodchips
surface = woodchip → surface = woodchips
surface = wood chips → surface = woodchips
surface = wood_chippings → surface = woodchips
surface = peeblestone → surface = pebblestone
surface = pebbles → surface = pebblestone
surface = pebblestones → surface = pebblestone
surface = pebbelstone → surface = pebblestone
surface = pepplestone → surface = pebblestone
surface = pebble → surface = pebblestone
surface = pavedq → surface = paved
surface = pavedc → surface = paved
surface = pavedw → surface = paved
surface = unapved → surface = unpaved
surface = groundц → surface = ground
surface = groundmm → surface = ground
surface = grround → surface = ground
surface = groundc → surface = ground
surface = gorund → surface = ground
surface = grounD → surface = ground
surface = concreate → surface = concrete
surface = concrete\ → surface = concrete
surface = gravelw → surface = gravel
surface = Gravel → surface = gravel
surface = fine gravel → surface = fine_gravel
surface = fine_gravelC → surface = fine_gravel
surface = Boardwalk → surface = boardwalk
surface = Metal → surface = metal
surface = gras → surface = grass
surface = grasss → surface = grass
surface = concrete:plate → surface = concrete:plates
surface = Cobblestone:flattened → surface = cobblestone:flattened
surface = cobbelstone:flattened → surface = cobblestone:flattened
surface = cobblestone:flatten → surface = cobblestone:flattened
surface = cobblestone:flattended → surface = cobblestone:flattened
surface = cobblestone:flattend → surface = cobblestone:flattened
surface = cobblestone:flatened → surface = cobblestone:flattened





--





proposed migration of shop=* values:
https://overpass-turbo.eu/s/1rLI for current listing of objects - 1117 right now

various ways of saying that we lack info about shop type
shop = user defined → shop = yes
shop = user_defined → shop = yes
shop = lack_of_info → shop = yes
shop = other → shop = yes
shop = unknown → shop = yes
shop = * → shop = yes
shop = Shop → shop = yes
shop = shop → shop = yes
shop = stuff → shop = yes
shop = store → shop = yes

shop=* and shop = user defined are used literally - and not catchalls.
see https://taginfo.openstreetmap.org//search?q=shop%3Duser+defined

synonyms or synonyms in this context
sometimes product tagged as a shop type
shop = pawnshop → shop = pawnbroker
shop = bread → shop = bakery
shop = laundromat → shop = laundry
shop = flowers → shop = florist
shop = meat → shop = butcher
shop = glasses → shop = optician
shop = hgv → shop = truck
shop = liquor → shop = alcohol
shop = Bag_shop → shop = 

Re: [OSM-talk] Test Import of forum.osm.org to community.osm.org

[Mateusz Konieczny via talk]

Old links will continue to work, right?

Including links in posts linking other posts (that now
link to the original forum)


Feb 21, 2023, 13:27 by openstreet...@firefishy.com:

> Hi OSM Talk,
>
> In the near future we will be moving the old forum.osm.org content to
> community.openstreetmap.org
>
> If you used the old forum, please login to the test import site
> https://forum-import-test.openstreetmap.org/ to check your old posts.
>
> The imported content is at the bottom half of the test import site.
> The database snapshot used for the test is from 02 Feb 2023.
>
> The old forum has 847000+ posts by 35000+ users in 91 categories. The
> longest thread has 14700+ posts!
> The old forum used fluxbb bbcode markdown, while
> community.openstreetmap.org uses discourse's flavour of markdown.
> The import markdown conversion can never be 100%, but it now appears
> to have reached "good enough".
>
> We heavily extended the original fluxbb discourse importer with
> additional features:
> * Significantly improved fluxbb bbcode -> discourse markdown
> converter, including fixes.
> * Added Permalink support (To test for now use old forum url path +
> parameters on forum-import-test.openstreetmap.org)
> * OSM specific old forum to community account merging allowing
> seamless login using osm.org account oauth flow.
> * Added unit tests
>
> We are trying to contribute the improvements upstream where appropriate.
>
> There will also be a few tasks the forum governance team will be
> responsible for post final import, notably:
> * Manually merge duplicate categories (eg: country categories)
> * Mark old abandoned categories as read-only.
> * Manually merge duplicate users where the importer did not
> automatically merge (very limited cases).
>
> Big thank you to Harry Wood, Tom Hughes and others who have helped
> write code, fix bugs or assisted in other ways.
>
> Kind regards,
>
> Grant
> Part of the OpenStreetMap Ops Team
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] "Stadium" map roulette challenge causing issues

[Mateusz Konieczny via talk]

Feb 14, 2023, 19:53 by a...@pigsonthewing.org.uk:

> Is a bulk revert possible?
>
Is bulk reverted needed? I tried using it and it does not seem to
be misconfigured or encouraging bad edits.

Maybe more clear description would be helpful.

Have you tried using this challenge?

Are bad edits limited to specific user accounts?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [automated edit] replace some obviously mistaken surface values by their clear intended meaning

[Mateusz Konieczny via talk]

Feb 11, 2023, 19:23 by marc_m...@mailo.com:

> Le 11.02.23 à 18:41, Mateusz Konieczny via talk a écrit :
>
>> I propose to replace following surface tags by doing an automated edit:
>>
>
> II agree with this automated edit.
>
> however, the most common cases should still be reported
> to the editors so that the error is corrected before sending
> and not by mass editing
> I don't know if it is possible but 2 rules could group many cases:
> surface= uppercase -> lowercase
> surface= space -> underscore
>
In general I do this
(see for example
https://josm.openstreetmap.de/query?status=closed=fixed=Core+validator=~mkoniecz=1000=id=summary=status=component=type=priority=milestone=time=2=id
though there is also benefit of running 100% safe edits as it prevents wasting 
time 
of JOSM mappers and confusion of mappers encountering it before it is fixed
- including indirect encounters)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [automated edit] replace some obviously mistaken surface values by their clear intended meaning

[Mateusz Konieczny via talk]

Feb 11, 2023, 19:23 by marc_m...@mailo.com:

> Le 11.02.23 à 18:41, Mateusz Konieczny via talk a écrit :
>
>> I propose to replace following surface tags by doing an automated edit:
>>
>
> II agree with this automated edit.
>
> however, the most common cases should still be reported
> to the editors so that the error is corrected before sending
> and not by mass editing
> I don't know if it is possible but 2 rules could group many cases:
> surface= uppercase -> lowercase
> surface= space -> underscore
>
In general I do this
(see for example
https://josm.openstreetmap.de/query?status=closed=fixed=Core+validator=~mkoniecz=1000=id=summary=status=component=type=priority=milestone=time=2=id
though there is also benefit of running 100% safe edits as it prevents wasting 
time 
of JOSM mappers and confusion of mappers encountering it before it is fixed
- including indirect encounters)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] replace some obviously mistaken surface values by their clear intended meaning

[Mateusz Konieczny via talk]

Errata: paragraph 4 from the bottom should be

"There is no point in manual drudgery here, with values clearly
replaceable by better matches."

sorry, I copied wrong bot edit justification template.

Feb 11, 2023, 18:48 by talk@openstreetmap.org:

> I propose to replace following surface tags by doing an automated edit:
>
> obvious typos:
>
> `surface=paving stones` → `surface=paving_stones`
> `surface=Paving_stones` → `surface=paving_stones`
> `surface=paving_stones:` → `surface=paving_stones`
>
> different form than standard surface value:
>
> `surface=wooden` → `surface=wood`
> `surface=cobblestones` → `surface=cobblestone`
>
> Polish name to English one:
>
> `surface=żwirowa` → `surface=gravel`
> `surface=kostka` → `surface=paving_stones`
> `surface=gruntowa` → `surface=unpaved`
>
> English vs very close to English but actually different:
>
> `surface=asfalt` → `surface=asphalt`
>
> Edit would be automatic, rerun from time to time, split into small
> changeset by geographic areas and run by
> https://www.openstreetmap.org/user/Mateusz%20Konieczny%20-%20bot%20account/history%20bot%20account
>
> Why it is useful? It helps newbies to avoid becoming confused. It
> protects against such values becoming established. Without drudgery
> that would be required from the manual cleanup. It also makes easier to
> add missing surface= values
>
> Why automatic edit? I have a massive queue (in thousands and tens of
> thousands) of automatically detectable issues which are not reported by
> mainstream validators, require fixes and fix requires review or
> complete manual cleanup.
>
> There is no point in manual drudgery here, with values completely useless.
>
> This values here do NOT require manual overview. If this cases will
> turn out to be an useful signal of invalid editing than I will remain
> reviewing nearby areas where bot edited.
>
> And I fixed some manually and they were not a great sign of a problematic 
> data.
>
> Yes, bot edit WILL cause objects to be edited. Nevertheless, as result
> map data quality will improve.
>

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

[OSM-talk] replace some obviously mistaken surface values by their clear intended meaning

[Mateusz Konieczny via talk]

I propose to replace following surface tags by doing an automated edit:

obvious typos:

`surface=paving stones` → `surface=paving_stones`
`surface=Paving_stones` → `surface=paving_stones`
`surface=paving_stones:` → `surface=paving_stones`

different form than standard surface value:

`surface=wooden` → `surface=wood`
`surface=cobblestones` → `surface=cobblestone`

Polish name to English one:

`surface=żwirowa` → `surface=gravel`
`surface=kostka` → `surface=paving_stones`
`surface=gruntowa` → `surface=unpaved`

English vs very close to English but actually different:

`surface=asfalt` → `surface=asphalt`

Edit would be automatic, rerun from time to time, split into small
changeset by geographic areas and run by
https://www.openstreetmap.org/user/Mateusz%20Konieczny%20-%20bot%20account/history%20bot%20account

Why it is useful? It helps newbies to avoid becoming confused. It
protects against such values becoming established. Without drudgery
that would be required from the manual cleanup. It also makes easier to
add missing surface= values

Why automatic edit? I have a massive queue (in thousands and tens of
thousands) of automatically detectable issues which are not reported by
mainstream validators, require fixes and fix requires review or
complete manual cleanup.

There is no point in manual drudgery here, with values completely useless.

This values here do NOT require manual overview. If this cases will
turn out to be an useful signal of invalid editing than I will remain
reviewing nearby areas where bot edited.

And I fixed some manually and they were not a great sign of a problematic data.

Yes, bot edit WILL cause objects to be edited. Nevertheless, as result
map data quality will improve.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] Adoption of OSM geometry as state mapping base

[Mateusz Konieczny via Talk-au]

Feb 11, 2023, 11:38 by 61sundow...@gmail.com:

>
>
>
> On 10/2/23 12:30, Andrew Harvey wrote:
>
>> Hi legal-questions, 
>>
>> I'm forwarding this interesting question about the OSMF  Terms of 
>> Use preventing anyone from obtaining OSM data for  emergency 
>> services use. This is in direct conflict with the  ODBL terms which 
>> contain no such restriction, and also include  a limitation of 
>> liability clause. Surely other emergency  services organisations are 
>> using OSM data without issue.
>>
>
> I too think it is a legal cop out for liability.
>
>
> I think there are some emergency services in Europe using OSM  data 
> already .. so if I am correct then it is possible (as it  should be in a 
> reasonable world). 
>
>
It was (and maybe still is) in production use for emergency services in Poland.

Partially replacing official data, partially supplementing it.

Legal situation got better in Poland but at some point official mapping agency 
was
legally required to charge prohibitive fees, also from emergency services.

And - as far as I know - there is no government register of fire hydrants or 
AED in Poland.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Gravel roads surface tagging

[Mateusz Konieczny via Talk-au]

though this round is about surface=fine_gravel (previous was about 
surface=gravel)
while surface=gravel old page claimed that it is for track ballast-sized chunks,
current surface=fine_gravel page describes it as duplicate of surface=compacted


Jan 7, 2023, 03:03 by fors...@ozonline.com.au:

> Hi all
>
> Gravel was discussed on talk_au back in March 2021. For anybody interested 
> its back in discussion at 
> https://community.openstreetmap.org/t/surface-fine-gravel-is-it-for-loose-gravel-or-duplicate-of-surface-compacted/7533/3
>
> Tony
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Mateusz Konieczny via talk]

Jan 6, 2023, 11:50 by valin...@gmx.net:

> To sum up: Coordinates can be used in the same wrong way as OSM id as
> they're both not sufficient enough for the use case most people are
> using it (indirectly).
>
But coordinates can be used correctly (shop updating their location
when their location moves).

It is impossible to guarantee it with OSM ids (in theory they could check
OSM object daily to check whether its id changed but that would be absurd)

> There is no visible reason to me why adding another unstable
> identifier like the osm id is a bad idea.
>
Coordinates are stable, information attached to coordinates can become
outdated (shop relocated, landmass moved etc) but coordinate itself is stable.

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

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Mateusz Konieczny via talk]

Jan 2, 2023, 21:59 by ajt1...@gmail.com:

> On 02/01/2023 20:44, Mateusz Konieczny via talk wrote:
>
>> way/node/relation ids in OSM are unstable, not promised to be stable and
>> anything relying on their stability can break at any point
>>
> Unfortunately, that sort of "black and white" answer doesn't really answer 
> the question of whether it's useful to link to OSM data like that.
>
It is often useful, but we should try to avoid implying that this ids will stay 
stable forever.

https://www.openstreetmap.org/node/1325892214 works well as link for such cases,
making some official uri scheme is implying things that we should not be 
implying.


> It's certainly possible (as I've said in that discussion) to use OSM IDs as 
> "stable enough to do real work with" - I do it all the time.
>
I also do this, but without expectations of id stability. 
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

[Mateusz Konieczny via talk]

Jan 2, 2023, 18:57 by valin...@gmx.net:

>
> Our own parameter could have the following syntax:
>
>
>
>
> osmid=(N|W|R)
>
>
>
>
> What do you think?
>
>
way/node/relation ids in OSM are unstable, not promised to be stable and
anything relying on their stability can break at any point

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

Re: [OSM-talk] razed railways and other things that don't exist today

[Mateusz Konieczny via talk]

I would mention

- it is OK to temporarily map ones not visible on aerial images but likely to 
be mistakenly
remapped
- "can safely be removed" - would change that it not only can be removed, but 
also
should be removed


5 gru 2022, 11:26 od 61sundow...@gmail.com:

> I have placed what I believe is a summary of this discussion on the OSM wiki 
> for lifecycle
>
> It reads
>
> "The following tags function is to reduce the possibility of a mapper 
> remapping the feature from existing satellite imagery that shows the old 
> state of the feature. Once the OSM available satellite imagery does not show 
> the feature the feature can safely be removed from OSM. Renders cannot rely 
> on OSM preserving physically vanished history."
>
> There after follow the tags 'demolished', 'removed', 'destroyed' and 'razed'.
>
> https://wiki.openstreetmap.org/wiki/Lifecycle_prefix#Stages_of_decay
>
>
> If there are any further thoughts or even corrections to my text above then 
> please post them here.
>
>
> My own thoughts?
>
> I have not placed any warning about mechanical edits to seek these out as 
> enough warning is evident in the requirement for it to be not shown in the 
> OSM satellite imagery, which would discourage me so I think it will work with 
> others.
>
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [talk-au] listing of objects wikipedia/wikidata/etc tags with some problems

[Mateusz Konieczny via Talk-au]

Processing this issues is welcome! And it will take some time, I started
cleaning data in Poland years ago, many other people helped and it
is still not completed :)

Updated process is run automatically, but with manual startup of it.

It runs on my laptop, so for example in case of going for holidays
or some other limitations updates may be paused.

I would expect updates about once a week, maybe once two weeks.
Though areas with more edits are boosted to update more often.
Also, adding new areas delays updates as initial scan takes far more
time than later ones. And is far more likely to fail due to encountering
data broken in new entertaining ways not seen before and not handled.

Note that after some part of country are fully processed I will enable
more - right now only part of Australia is being checked.
So look for number of cleared areas, not for error count.

30 lis 2022, 10:22 od daniel.ocon...@gmail.com:

> This seems useful. How often do your reports re-run? (manually?) Would be 
> good to chip away at issues and get a sense of progress.
>
> On Mon, Nov 28, 2022 at 4:44 PM Mateusz Konieczny via Talk-au <> 
> talk-au@openstreetmap.org> > wrote:
>
>> I have created >> 
>> https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/
>> which lists OSM objects that have some problems requiring review
>>
>> There is a report for number of areas, including for Australia:
>>
>> https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia.html
>> (merged report for Australia)
>>
>> Or more specifically for parts of Australia (links later).
>>
>> If anyone is interested: feel free to use this list to fix this bogus 
>> wikipedia/wikidata links.
>>
>> Please, let me know if anything is confusing, incorrect, invalid or broken.
>> Or if you want some specific area/country not listed so far.
>>
>> 
>>
>> There are also reports at 
>> https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia%20-%20obvious.html
>> which are about a bit different issues, but they depend on a local data
>> or community and some may need upgrade to human review and
>> some may need to be hidden:
>>
>> Is OSM data for wikipedia/wikidata tags good enough that
>> following wikipedia redirects (where wikidata matches) could be 
>> done automatically?
>> Or is it requiring human review (because someone added wikidata
>> of redirect targets with bot, for example)?
>> https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia%20-%20obvious.html#wikipedia%20wikidata%20mismatch%20-%20follow%20wikipedia%20redirect
>>
>> Would you expect wikipedia tags to link English language Wikipedia 
>> where possible? Or is linking any language version OK?
>>
>> Would you consider useful to add wikipedia tag where only wikidata tag
>> is present as useful (for increased human readability of tags)?
>>
>> Would you consider useful to add wikidata tag where only wikipedia tag
>> is present as useful (for increased stability of tags and to allow
>> fixing redirects if wikipedia article changes title in the future)?
>>
>> 
>>
>> specific areas (once this issues are fixed I will enable more areas,
>> until entire Australia is being checked)
>>
>> Tasmania - 25 reported issues
>> https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20Tasmania.html
>>
>> New South Wales - 29 issues
>> https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20New%20South%20Wales%20(Nowa%20Po%C5%82udniowa%20Walia).html
>>
>> Queensland (found 36 problems)
>> https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20Queensland.html
>>
>> And also following with 0 reported issues right now, thanks to
>> people who fixed them!
>> Australia Capital Territory
>> https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia%20Capital%20Territory.html
>>
>> Christmas Island
>> https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20Christmas%20Island%20(Wyspa%20Bo%C5%BCego%20Narodzenia).html
>>
>> Cocos Islands
>> https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20Cocos%20(Keeling)%20Islands%20(Wyspy%20Kokosowe).html
>>
>> Northern Territory
>> https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20Northern%20Territory%20(Terytorium%20P%C3%B3%C5%82nocne).html
>> ___
>>  Talk-au mailing list
>>  >> Talk-au@openstreetmap.org
>>  >> https://lists.openstreetmap.org/listinfo/talk-au
>>

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

Re: [OSM-talk] QA tool for finding nameless highways that are armchair-fixable

[Mateusz Konieczny via talk]

> I can't really think what the Osmose people (in this example) could do to 
> make people
>  NOT blindly make changes in this way
>
Add ability to ban accounts from using Osmose?
And use it to ban people misusing it?

In theory there can be also some sort of fake elements
clearly labelled as "mark as false positive if you actually review reported 
errors"
and ban people who will ignore it and blindly click "proceed with edit".

(not saying that either is worth doing, not sure how large is the problem
and whether either would substantially help)

Maybe just reporting abuse of Osmose to DWG for zero-hour blocks (or
longer for repeated offenders) is the best solution.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[talk-au] listing of objects wikipedia/wikidata/etc tags with some problems

[Mateusz Konieczny via Talk-au]

I have created https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/
which lists OSM objects that have some problems requiring review

There is a report for number of areas, including for Australia:

https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia.html
(merged report for Australia)

Or more specifically for parts of Australia (links later).

If anyone is interested: feel free to use this list to fix this bogus 
wikipedia/wikidata links.

Please, let me know if anything is confusing, incorrect, invalid or broken.
Or if you want some specific area/country not listed so far.



There are also reports at 
https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia%20-%20obvious.html
which are about a bit different issues, but they depend on a local data
or community and some may need upgrade to human review and
some may need to be hidden:

Is OSM data for wikipedia/wikidata tags good enough that
following wikipedia redirects (where wikidata matches) could be 
done automatically?
Or is it requiring human review (because someone added wikidata
of redirect targets with bot, for example)?
https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia%20-%20obvious.html#wikipedia%20wikidata%20mismatch%20-%20follow%20wikipedia%20redirect

Would you expect wikipedia tags to link English language Wikipedia 
where possible? Or is linking any language version OK?

Would you consider useful to add wikipedia tag where only wikidata tag
is present as useful (for increased human readability of tags)?

Would you consider useful to add wikidata tag where only wikipedia tag
is present as useful (for increased stability of tags and to allow
fixing redirects if wikipedia article changes title in the future)?



specific areas (once this issues are fixed I will enable more areas,
until entire Australia is being checked)

Tasmania - 25 reported issues
https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20Tasmania.html

New South Wales - 29 issues
https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20New%20South%20Wales%20(Nowa%20Po%C5%82udniowa%20Walia).html

Queensland (found 36 problems)
https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20Queensland.html

And also following with 0 reported issues right now, thanks to
people who fixed them!
Australia Capital Territory
https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia%20Capital%20Territory.html

Christmas Island
https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20Christmas%20Island%20(Wyspa%20Bo%C5%BCego%20Narodzenia).html

Cocos Islands
https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20Cocos%20(Keeling)%20Islands%20(Wyspy%20Kokosowe).html

Northern Territory
https://matkoniecz.github.io/OSM-wikipedia-tag-validator-reports/Australia:%20Northern%20Territory%20(Terytorium%20P%C3%B3%C5%82nocne).html
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] Jhulto Pul/ Morbi bridge

[Mateusz Konieczny via talk]

Nov 12, 2022, 11:18 by marc_m...@mailo.com:

>> The reverting changeset
>>
>
> https://www.openstreetmap.org/way/604295549
> highway=construction for a very damaged bridge is very strange,
> it look like tagging for the render
>
I am also unsure, but unfamiliar with situation.

Maybe  reconstruction started already and person who added/recreated
this way has some info?

So I opened https://www.openstreetmap.org/note/3435508
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Jhulto Pul/ Morbi bridge

[Mateusz Konieczny via talk]

That would be more fitting for OSM note ( see 
https://wiki.openstreetmap.org/wiki/Notes )

And definitely would benefit from link to
- location in OSM
- confirmation that it happened

If you identified specific problem you can also simply edit this location

Nov 6, 2022, 20:25 by a...@pigsonthewing.org.uk:

> Someone has deleted the way for the pedestrian bridge at Morbi, India.
>
> This seems to be in error, as - despite the recent tragic collapse -
> the superstructure is largely still in place, and still spans the
> river, according to press coverage
>
> The way had been marked as impassable. Can someone restore that, please?
>
> -- 
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] razed railways and other things that don't exist today

[Mateusz Konieczny via talk]

Oct 26, 2022, 12:05 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 26 Oct 2022, at 11:45, Mateusz Konieczny via talk 
>>  wrote:
>>
>> Note that when you found some gone railway
>> mapped in OSM then it is useful
>>
>> - edit OSM object to note which traces are left if any
>> (ideally, it would be done by original mapper)
>>
>> - or delete nonexistent sections without traces
>>
>
>
> what is the scale/resolution  for determining a “non-existent” section? If 
> you do it too fine grained, it would be like mapping a dashed divider line, 
> with yes/no alternating every 2 meters.
>
If road was rebuild and as result there is 10m wide gap where embankment 
was obliterated then I would delete such section of 
railway=abandoned/railway=razed

But if someone would initially map it then I would not complain about it

> Is a former station a trace that is valid in this sense?
>
if train station/platform trace remains then mapping them is fine

but if railway track between them is obliterated without trace then such track
is not mappable and should be deleted if it is mapped

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

Re: [OSM-talk] razed railways and other things that don't exist today

[Mateusz Konieczny via talk]

Which OSM Wiki pages you checked to find out
reason for existence of things like demolished:building=yes?

Recently demolished building may be visible on aerial images

Using lifecycle prefixes it is possible to clearly mark that specific object 
must not be
remapped without proper verification.

Once there is no real risk of remapping them by person thinking that this 
objects
are still existing such elements should be deleted from OSM.

Fully gone elements (for example levelled railway embankment replaced by
residential buildings) should be deleted from OSM.

Is there any OSM Wiki page claiming otherwise?

> it is used by Open Railway Maps (ORM)

If they want to display also fully gone railway tracks -
then they need to use OpenHistoricalMap dataset

If they use OSM then they will show only recently
demolished one and ones that left traces.

Some incorrectly mapped ones may be displayed,
but they may be correctly deleted at any moment
once this mistakes are spotted.

-

Note that when you found some gone railway
mapped in OSM then it is useful

- edit OSM object to note which traces are left if any
(ideally, it would be done by original mapper)

- or delete nonexistent sections without traces
and review edits that added them.
It is common to see changeset adding
400km of destroyed railway without any verification
in place, in such case entire changeset should be
reverted.
Obviously in case of any doubt - comment using
changeset comment and create OSM note,
then get back to it in some time
( https://www.openstreetmap.org/note/3412415
is my latest one, spotted it while mapping something else)

Without doing this mappers of railways gone without
any trace will easily win. They copy from old
maps and can easily mark hundreds of kilometers
in one edit.
Sometimes they demand to prove nonexistence
of railways.
But it is fine to remove entire edit if it was done
without survey and added features not
existing in any way on the ground.

Oct 25, 2022, 09:42 by 61sundow...@gmail.com:

> Hi,
>
> Question:
>
> If OSM is about mapping what exists today .. why have the tags that mean 
> there is nothing left of it?
>
>
> demolished:*=*
>     Not existing anymore because of active removal
>  removed:*=*
>     Not existing anymore because of active removal (possible duplicate of 
> demolished:*=*)
> razed:*=*
>     Not existing anymore because of active removal (duplicate of removed:*=*, 
> possible duplicate of demolished:*=*)
> destroyed:*=*
>    Destroyed by an event other than active demolition
>
> I think these tags would be of use in Open Historic Map (OHM) and that is 
> possibly why they are in the OSM wiki?
>
> Possibly the OSM wiki should recommend that the data with these tags be moved 
> to OHM?
>
>
> The argument for mapping these things from the 'old railway' people is that;
>
> 1) it does not render on the 'standard map' so it is not a problem.
>
> 2) it is used by Open Railway Maps (ORM)
>
>
> My contention is;
>
> 1a) This is a problem when people try to map new things, the old things lead 
> to mapping things that never existed like railway=crossing where a new 
> footway/highway is also mapped over a now non existent railway line.
>
> 1b) People mapping new things may not see the old stuff on the new imagery .. 
> and simply delete it, leading to edit wars.
>
> 1c) People map things like an old embankment for old railway lines .. right 
> through existing roads
>
> 3) Old data should be mapped into OHM so it can be preserved .. together with 
> the start and stop dates .. these 2 tags are fairly well ignored in OSM.
>
> 2) ORM should take current data from OSM and old data from OHM. This would 
> add the start/end dates that could be used in ORM to select the time period. 
> Thus those only interested in the present could have that, and those 
> interested in some past date could have that.
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] Proposed automated edit - remove image=https://westnordost.de/p/* tags (and similar)

[Mateusz Konieczny via talk]

Sep 30, 2022, 18:21 by marc_m...@mailo.com:

> Le 27.09.22 à 21:48, Mateusz Konieczny via talk a écrit :
>
>> Sep 26, 2022, 13:49 by marc_m...@mailo.com:
>>
>>  is it possible to have a list by country? i would be willing to go
>>  through a series of images and contact one or the other person concerned
>>
>> Are you interested in specific area?
>>
>
> Belgium, France, Luxembourg, Switzerland
> no idea about the number of that. 100 is enough
> if there are many more, I'll see if there are people to share the work
>
Below are links to surviving photos.

You can try to find OSM elements with Overpass or notes with
https://ent8r.github.io/NotesReview/ or 
https://antonkhorev.github.io/osm-note-viewer/
or other note search.

Belgium
https://westnordost.de/p/112839.jpg
https://westnordost.de/p/114075.jpg
https://westnordost.de/p/63408.jpg
https://westnordost.de/p/111807.jpg
https://westnordost.de/p/112001.jpg
https://westnordost.de/p/111977.jpg
https://westnordost.de/p/113504.jpg
https://westnordost.de/p/114031.jpg
https://westnordost.de/p/88497.jpg
https://westnordost.de/p/22271.jpg
https://westnordost.de/p/112956.jpg

France
https://westnordost.de/p/52199.jpg
https://westnordost.de/p/31165.jpg
https://westnordost.de/p/31155.jpg

Luxembourg
https://westnordost.de/p/88497.jpg

Switzerland
none
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] remove link to Wikidata from infoboxes is a valid arg to remove it from wiki page and data items ?

[Mateusz Konieczny via talk]

Sep 30, 2022, 18:19 by marc_m...@mailo.com:

> you're deleting a *data*, an info (the match between tag
> and a wikidata item) on the wiki
>
Just to confirm:
are you aware that https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree
has matching data item https://wiki.openstreetmap.org/wiki/Item:Q4723
which contains this link to wikidata?

In which kind of use you would be unable to use "Wikidata concept" field in
https://wiki.openstreetmap.org/wiki/Item:Q4723 but you would need a
defunct wikidata parameter of infobox visible only in the edit mode?

(before Wikidata link display was removed all data was replicated to data items)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] remove link to Wikidata from infoboxes is a valid arg to remove it from wiki page and data items ?

[Mateusz Konieczny via talk]

Date: Sep 30, 2022, 18:26
From: marc_m...@mailo.com
To: talk@openstreetmap.org
Subject: Re: [OSM-talk] remove link to Wikidata from infoboxes is a valid arg 
to remove it from wiki page and data items ?


> Hello,
>
> Le 30.09.22 à 13:36, Frederik Ramm a écrit :
>
>> "Make link far less prominent" is not the same as "delete link".
>>
> Therefore the bot activity has, in my opinion, no community backing and needs 
> to be stopped and reverted. 
> Thanks for your opinion, I hope it will be a consensus
>

1) complete removal of display was approved in
https://wiki.openstreetmap.org/wiki/Proposed_features/remove_link_to_Wikidata_from_infoboxes

2) removal of now defunct wikidata parameter was approved
by 
https://wiki.openstreetmap.org/wiki/Talk:Wiki#Remove_wikidata_parameters_from_infoboxes

If you think that modification of wikicode visible only to OSM Wiki
editors (or bot edits on OSM Wiki) require more substantial
approval feel free to propose a new policy for that but note that
- it would be better to propose it on wiki
- it would be a new policy
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] remove link to Wikidata from infoboxes is a valid arg to remove it from wiki page and data items ?

[Mateusz Konieczny via talk]

Sep 30, 2022, 14:55 by marc_m...@mailo.com:

> Hello,
>
> Le 30.09.22 à 14:42, Mateusz Konieczny via talk a écrit :
>
>> Not entirely sure what should be done differently.
>>
>
> if you want to vote on "hide", use an url and a title with *hide*,
> as you did.
> but not a "it's hide but somewhere i said that hive mean I 'll
> delete it", that's unfair and imho a mistake.
>
url and title had "remove"

What other word should be used to make it more clear?

(not a native speaker, but "remove" suggest quite strong
action as far as I know)

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

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

Re: [OSM-talk] remove link to Wikidata from infoboxes is a valid arg to remove it from wiki page and data items ?

[Mateusz Konieczny via talk]

Sep 30, 2022, 14:32 by a...@pigsonthewing.org.uk:

> On Fri, 30 Sept 2022 at 13:08, Mateusz Konieczny via talk
>  wrote:
>
>> It was proposed on
>> https://wiki.openstreetmap.org/wiki/Talk:Wiki#Remove_wikidata_parameters_from_infoboxes
>> and noone was against, so I have run it
>>
>
> As you are well aware, I have been strongly and consistently against
> this asinine idea since it was first proposed; I don't have the energy
> to repeat myself in every new forum where you repeat it.
>
I am still waiting for reply to
https://lists.openstreetmap.org/pipermail/tagging/2022-April/064293.html
(just being against without stating reason is not worth much)

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

Re: [OSM-talk] remove link to Wikidata from infoboxes is a valid arg to remove it from wiki page and data items ?

[Mateusz Konieczny via talk]

Sep 30, 2022, 14:08 by frede...@remote.org:

> Hi,
>
> On 30.09.22 13:36, Frederik Ramm wrote:
>
>> You can't have people vote on one thing and then do something else.
>>
>
> It occurs to me that this is what usually happens in politics. Still, we 
> should aim to be better ;)
>
And to be clear: my intention was NOT to mislead people and I am really sorry
if I was insufficiently clear in any part.

Not entirely sure what should be done differently. Maybe initial 
mistake was not making clear that ceasing to display wikidata link
makes this parameter defunct and that it should be removed?

It was titled "remove link to Wikidata from infoboxes" and had
"this proposal will not result in a data loss, as everything in OSM Wiki
was synchronized to data items" and 
"wikidata parameter in infoboxes on wiki pages would become inactive"
and so on.

But now I see that for many people implication may be not obvious :(
That it implies that this parameter would become removable as
dead and inactive.

That is quite sad as I put a lot of effort into attempt to make this
proposal clear. And I see that it had a major failure. Sorry for that.

---

To clarify situation:
When proposal was made all data was synchronise with data items.
Anyone using wikidata links for any purpose still have access to them
and if this data was useful at all they can continue to use them.

---

But making second large scale edit to add back defunct parameter
that is no longer present in the infobox does not seem to be a good idea.

Especially as this wiki bot edit followed stricter standards than actually 
stated 
as required.

---

And it is even more irritating as I am one of few people actually following 
rules for bot edits.

Basically all bot edits and imports operate under "hopefully noone will 
revert this, so lets ignore rules and just do it". Or at least some rules.

And I actually put quite a lot of effort into doing what is required by rules
so it is a bit irritating to run into this.

(see https://wiki.openstreetmap.org/wiki/Category:Automated_edits_log
- and it is not like I made 1/3 of all automated edits in OSM!)

And on Wiki many automated edits were running without even asking 
on Talk:Wiki
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] remove link to Wikidata from infoboxes is a valid arg to remove it from wiki page and data items ?

[Mateusz Konieczny via talk]

Sep 30, 2022, 14:08 by matkoni...@tutanota.com:

> (note that bot edits on OSM Wiki are often done without any 
> requests/proposals,
> and my habit of actually proposing it and waiting two weeks before running it
> is more than done in general)
>
See also https://wiki.openstreetmap.org/wiki/Talk:Wiki/Archive_8#Bot_policy
(maybe this discussion reveals that we should have some stricter rules?
If you have some specific idea feel free to propose them, probably the proper
place for that is https://wiki.openstreetmap.org/wiki/Talk:Wiki )
I took that discussion to imply that right now there are no requirements
but decided to mention any planned edits at 
https://wiki.openstreetmap.org/wiki/Talk:Wiki
and wait for some time to give people opportunity to give feedback or
protest.

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

Re: [OSM-talk] remove link to Wikidata from infoboxes is a valid arg to remove it from wiki page and data items ?

[Mateusz Konieczny via talk]

Sep 30, 2022, 13:36 by frede...@remote.org:

> "It will not lead to any data loss, but will make Wikidata link far less 
> prominent."
>
> "Make link far less prominent" is not the same as "delete link".
>
This proposal had
"Remove rendering of Wikidata external links from bottom of the infobox"

What "Make link far less prominent" meant is 
"you will need to get to data item to see this link"

> Therefore the bot activity has, in my opinion, no community backing and needs 
> to be stopped and reverted.
>
> You can't have people vote on one thing and then do something else.
>
This bot edit was not done on basis of this specific vote.

It was explicitly mentioned that automatic edit removing parameters
from wiki pages may be done if it will go through bot approval.

Which in case of OSM Wiki is done at Talk:Wiki page.

It was proposed on
https://wiki.openstreetmap.org/wiki/Talk:Wiki#Remove_wikidata_parameters_from_infoboxes
and noone was against, so I have run it

I also posted
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/remove_link_to_Wikidata_from_infoboxes#Removal_of_migrated_parameter_from_infoboxes_-_bot_edit

(note that bot edits on OSM Wiki are often done without any requests/proposals,
and my habit of actually proposing it and waiting two weeks before running it
is more than done in general)

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

Re: [OSM-talk] remove link to Wikidata from infoboxes is a valid arg to remove it from wiki page and data items ?

[Mateusz Konieczny via talk]

It would be better to discuss it at Wiki, but I can respond here.

> because for some tags, the item described by the tag was not the same
> as the one described by the wikidata item (in my opinion it is better
> to only delete the erroneous links instead of hiding everything)

not really

see 
https://wiki.openstreetmap.org/wiki/Proposed_features/remove_link_to_Wikidata_from_infoboxes#Rationale
for reasons, match quality is only subreason and primary is 
that it is useless for users and if someone really needs it
they can use data items

Data items are often harder to process than infobox parameter
parsing[1], but someone planning to use Wikidata identifier
will need to parse them anyway.

[1] at least in Python and JS and any other language that have wikicode parsing 
library

> therefore if I want to make an application that displays natural=tree genus 
> species
in the user's language, I don't have access to the translation base that is de 
facto
wikidata

(1) you have still access to wikidata genus species entries and it is not
being changed at all

(2) 
https://wiki.openstreetmap.org/w/index.php?title=Tag:natural%3Dtree=2409181=2386673
 
edit removed dead parameter
|wikidata=Q10884
and linking natural=tree to https://www.wikidata.org/wiki/Q10884 
is not helping at all in something that displays natural=tree genus species

(3) https://wiki.openstreetmap.org/wiki/Item:Q4723 data item still has
link to Q10884 Wikidata entry if for some reason it is needed

(4) please be aware that Wikidata quality, especially for translations
is quite dubious (if someone tried this and deployed this - let me know
so I can report systematically broken description into Polish)


> today I see that a bot is deleting the wikidata, which is not
> the same thing as "hide from the infobox"
>
to quote proposal

"wikidata parameter in infoboxes on wiki pages would become inactive.
Automatic edit removing them should obtain a separate bot approval
(it is not granted by this proposal)."

Bot edits limited to OSM Wiki are not handled by any policy, many people
run smaller or larger bot edits without any approval whatsoever.

In my case I propose them on Talk:Wiki and wait for some time.

This specific edit is also trivial to do in reverse (copy simple entry
from data item into infobox) in unlikely case of people changing their 
mind and wanting to display this tag in infobox.

If someone things that bot policy for wiki with stronger requirements
would be a good idea, feel free to design one.

> what do we gain by breaking the link between
> natural=tree and |wikidata=Q10884 ?
>
See 
https://wiki.openstreetmap.org/wiki/Proposed_features/remove_link_to_Wikidata_from_infoboxes#Rationale
for rationale

> compare osm's translation list with wikidata
> https://wiki.openstreetmap.org/wiki/Item:Q4723
> https://www.wikidata.org/wiki/Q10884
> of course for some, it's even worse, for ex genus=* 30 <> 125
> https://wiki.openstreetmap.org/wiki/Item:Q310
> https://www.wikidata.org/wiki/Q34740
>
Using nearest Wikidata item translations for describing tag
is not useful at all and often will result in highly confusing
and misleading "translations".
But if you really want, you can still do this and you are not affected
by this edits.

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

Re: [OSM-talk] change OSM documentation license to CC 4.0

[Mateusz Konieczny via talk]

Sep 11, 2022, 01:30 by o...@tobias-knerr.de:

> On 06.09.22 at 19:22, Stephan Knauss wrote:
>
>> Could we please upgrade this to a CC BY SA 4.0 license to avoid especially 
>> for US users doing slight mistakes in attribution a lawsuit claim of 150k 
>> USD?
>>
>> https://creativecommons.org/2022/02/08/copyleft-trolls/
>>
>
> Seems like a decent argument in favour of an upgrade. Maybe it's worth 
> bringing up the idea on https://wiki.osm.org/Talk:Wiki as well so more of the 
> active wiki editors see it?
>
> If there is some favorable reception, I guess a next step could be to check 
> with LWG for any potential issues and downsides.
>
See https://wiki.openstreetmap.org/wiki/Talk:Wiki#Updating_the_wiki's_license

I guess that consulting with LWG would be the next step if someone is interested
in working on this.

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

Re: [OSM-talk] Proposed automated edit - remove image=https://westnordost.de/p/* tags (and similar)

[Mateusz Konieczny via talk]

Sep 26, 2022, 13:49 by marc_m...@mailo.com:

> is it possible to have a list by country? i would be willing to go through a 
> series of images and contact one or the other person concerned
>
Are you interested in specific area? That would be easier and faster
and less resource intensive to produce than geocoding all of them.


> Maybe this would be an opportunity to have an easy way to add a picture to 
> commons for an osm constributor, I mean as easy as taking a picture for a 
> note in SC. but that's a whole other topic than your mass editing proposal 
> which I therefore partly agree with
>

I remember someone announcing work on such project recently.

Not sure is it progressing beyond an idea but I guess that you
can star repository as indicator of interest:
https://github.com/Discostu36/OSM-Photos

And there is https://github.com/Discostu36/OSM-Photos#how-can-i-help
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Proposed automated edit - remove image=https://westnordost.de/p/* tags (and similar)

[Mateusz Konieczny via talk]

StreetComplete allows to attach image to notes, which often makes 
this notes able to be remotely confirmed and fixed.

This is quite useful

Images are temporarily stored on server operated by SC author.

But some people mistakenly add them as value of image tag, unaware that
they will be gone soon after note is closed.

I propose to remove all image=https://westnordost.de/p/* values,
automatically, with bot.
And also ones added as value of website/url/etc tags.

Edit would apply to all existing ones and to new ones as they arrive.

Every single such link is dead or will be dead and therefore adds no value.

https://github.com/openstreetmap/id-tagging-schema/issues/591 and 
https://josm.openstreetmap.de/ticket/22397 were also opened to warn
people adding them

Example link to be removed: 

image=https://westnordost.de/p/17484.jpg

https://taginfo.openstreetmap.org/tags/?key=image=https%3A%2F%2Fwestnordost.de%2Fp%2F17484.jpg

there are thousands of object with such tags

(if you made edit like this: maybe image is not yet deleted and you can
upload such own image to Wikimedia Commons)
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] suspicious edits in Victoria need reverting?

[Mateusz Konieczny via Talk-au]

It seems that edit were reverted in
https://www.openstreetmap.org/changeset/124325240


Aug 1, 2022, 00:52 by nwas...@gmail.com:

> Hi
> there is some recent mapping around southern Victoria and the greater 
> Melbourne area that seem to be incorrect and need reverting but I am not 
> familiar enough with the area to be sure.
> The new roads seem fictitious but could be proposed approximate new routes I 
> suppose.
> Could mappers more familiar with the area have a look at these edits.
>
> https://www.openstreetmap.org/user/eggsbenedict/history#map=8/-37.981/146.195
> The two with road comments are of most concern.
>
> https://nrenner.github.io/achavi/?changeset=124295896
> https://nrenner.github.io/achavi/?changeset=124296506
>
> Thanks, Nev
>  
>
>  
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

Re: [talk-au] Mapping "secret" facilities?

[Mateusz Konieczny via Talk-au]

Jul 27, 2022, 10:40 by stevea...@softworkers.com:

> On Jul 27, 2022, at 1:02 AM, Warin <61sundow...@gmail.com> wrote:
>
>> On 27/7/22 17:13, Mateusz Konieczny via Talk-au wrote:
>>
>>> is it clearly signposted as cannabis factory farm at its location?
>>>
>
> I sincerely doubt this would ever happen, but if it did, you can bet their 
> security is much, much better than any bad intentions you might have.  BTW, 
> “mapping” (per se, as we do in OSM), is not a “bad intention.”  (I’d say it’s 
> a GOOD intention).
>

Mapping secret location of  shelter for women / men who are victims of spousal
abuse or Christian place of worship in Saudi Arabia would be almost
certainly a bad idea.

Though if this cannabis growers publish aerial view of own locations then 
this "secret" is likely more of branding and promotion.

(though maybe someone may want to let them know about
this inconsistency)


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

Re: [talk-au] Mapping "secret" facilities?

[Mateusz Konieczny via Talk-au]

is it clearly signposted as cannabis factory farm at its location?

If yes, then mapping it likely would be fine.

If it is clearly signposted but it is not verifiable by survey then some
more generic tagging should be fine.

If something is not really verifiable at location (anonymous note may be lying!)
then it is not really mappable (there are rare exceptions, for example for 
borders
but they do not apply here)

Jul 27, 2022, 02:31 by graemefi...@gmail.com:

> Have just spotted a Note where an anonymous user has given company name & 
> address details for a Medicinal Cannabis plant.
>
> Checking to confirm details & found a news article that said, yes, the plant 
> is near Mildura, but "Due to the nature of its business, however, it has a 
> secret location and isn’t open to the public." 
>
> The company involved doesn't have the plant address listed on it's website.
>
> Should we map it?
>
> Thanks
>
> Graeme
>

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

[talk-au] Is addr:housenumber=2/20 likely to be valid?

[Mateusz Konieczny via Talk-au]

I want to confirm report from
https://github.com/streetcomplete/StreetComplete/issues/4196

"In my area (and throughout built-up parts of Australian cities in general)
it is not uncommon to encounter blocks of townhouses which share a
primary address number but have distinct sub-address numbers.

The complete address numbers of such houses are written in the format 
/, eg "1/50", "2/50", "3/50" for the first three houses 
sharing the primary address site "50 Example St"."

Is it accurate? Is addr:housenumber=1/50 the standard and preferred
solution in such cases?

(I am asking as I know nothing about Australia addressing)

(BTW, if for some reason you want to comment on something
that is Australia and StreetComplete-specific - I will be on this mailing list
for some time, but as usual problem are better reported at the issue tracker)
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Splitting Ways for small roundabout traffic islands

[Mateusz Konieczny via Talk-au]

Nov 15, 2021, 12:14 by andrew.harv...@gmail.com:

> What I'd like to hear is from those who do split, is why? Is it just because 
> you're trying to follow the documented rules, or is there a reason for 
> splitting being better? Ideally we'd document the community preferred 
> approach along with the reasons for.
>

>From Poland:

Splitting may result in more clear maps, especially in vehicle navigation 
software

Some people like mapping everything, with extreme detail

Such mapping is required when one is using area:highway=* mapping


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

Re: [talk-au] "Removing closed or illegal trails." (in Nerang National Park)

[Mateusz Konieczny via Talk-au]

Oct 29, 2021, 12:42 by p...@wyatt-family.com:

> In most cases you are allowed to legally travel ANYWHERE, including off 
> track, within a national park (with minimal exceptions), however we do not 
> mark on the map every possibility between all known destinations. That would 
> make the map look like a spiders web. This would also not help search and 
> rescue efforts.
>
using highway=path/footway for "walking here is legal, as you can legally 
travel 
anywhere" is also clearly invalid and noone is really proposing it

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

Re: [talk-au] "Removing closed or illegal trails." (in Nerang National Park)

[Mateusz Konieczny via Talk-au]

In such case it would be worth to report this as a clear bug.

(have not verified that it actually happens)


Oct 29, 2021, 13:23 by p...@wyatt-family.com:

> I think OSMAND only works to exclude access=private, not access=no
>
> -Original Message-
> From: Warin <61sundow...@gmail.com> 
> Sent: Friday, 29 October 2021 10:05 PM
> To: talk-au@openstreetmap.org
> Subject: Re: [talk-au] "Removing closed or illegal trails." (in Nerang 
> National Park)
>
>
> Some renders can show the difference. OSMand has a setting to show access... 
> and it works.
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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