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/Mechan
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
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
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)
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
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
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 articl
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
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=*,
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, w
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
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.
&
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&q
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
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
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 Konie
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 chan
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
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
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
>>>
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
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/
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 ?
>
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
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
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
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
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
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
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,
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
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
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
>> wil
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://overpa
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
>
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 ta
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
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 fr
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
>> >
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
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 h
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
>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:
>
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
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
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?
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
>> 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.
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 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
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
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?
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
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
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
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
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 =
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?
>>
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.
&g
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 s
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,
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
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
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
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
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
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
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:
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
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:
>
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
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, th
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
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
: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> >
> 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
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
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
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
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
>>
>>
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.
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 c
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
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"
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 *hid
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
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
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
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"
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
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?
>>
>>
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
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
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
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?
>>
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
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.
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
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
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>
>
1 - 100 of 1090 matches
Mail list logo
