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

2023-02-11 Thread Mike Thompson
On Sat, Feb 11, 2023 at 5:23 PM Greg Troxel wrote: > > > The terms cover data distribution, ie downloading from > > planet.openstreetmap.org so you need to go through those terms to obtain > > OSM data regardless of the ODbL. > > Really? That's huge news compared to the data being under ODbL.

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

2023-02-11 Thread Greg Troxel
Andrew Harvey writes: > On Sat, 11 Feb 2023, 2:09 am Greg Troxel, wrote: > >> rob potter writes: >> >> As others pointed out those are website terms. You want to use the >> data, not the website, and you should read the Open Database License. >> > > The terms cover data distribution, ie

Re: [talk-au] NSW Fire Station names

2023-02-11 Thread cleary
I have one further comment about obsolete information on the DCS NSW Base Map. Located at 744 Carnarvon Highway, just north of Moree is a building that is labelled on the Base Map as OTC Satellite Earth Station. As far as I could find out, it ceased to have that purpose about 35 years ago but

Re: [talk-au] NSW Fire Station names

2023-02-11 Thread cleary
The DCS NSW Base Map is a great resource but some aspects do not seem to get updated e.g. roads that were once public but are now private may still appear on the map to have former status (e.g. parts of unincorporated area in western NSW), re-named roads may still show old names, waterways show

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

2023-02-11 Thread Marc_marc
Le 11.02.23 à 19:38, john whelan a écrit : Has the mapper changed their practices already?  Getting fifty emails telling someone they used upper case two years ago might just put them off mapping. who is talking about sending an email to a user ? I was talking about getting a warning from the

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

2023-02-11 Thread Martin Koppenhoefer
sent from a phone > On 11 Feb 2023, at 18:49, Mateusz Konieczny via talk > wrote: > > Nevertheless, as result > map data quality will improve. agreed for these cases, the problem is always when people become overeager to fix all kinds of values thereby “normalizing” what should not

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

2023-02-11 Thread Tobias Knerr
On 11.02.23 18:41 Mateusz Konieczny wrote: I propose to replace following surface tags by doing an automated edit I wholeheartedly support this proposal, thank you for your work! ___ talk mailing list talk@openstreetmap.org

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

2023-02-11 Thread 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

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

2023-02-11 Thread 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

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

2023-02-11 Thread john whelan
At first glance this seems a good idea but based on my experience as a HOT validator you have to be careful. Has the mapper changed their practices already? Getting fifty emails telling someone they used upper case two years ago might just put them off mapping. A better solution would be

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

2023-02-11 Thread stevea
On Feb 11, 2023, at 9:41 AM, Mateusz Konieczny via talk wrote: > I propose to replace following surface tags by doing an automated edit: > ... To ma dla mnie sens, Mateusz. (Makes sense to me). ___ talk mailing list talk@openstreetmap.org

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

2023-02-11 Thread Zeke Farwell
sounds good to me On Sat, Feb 11, 2023 at 1:17 PM john whelan wrote: > Sounds wonderful. > > John > > On Sat, Feb 11, 2023, 12:49 Mateusz Konieczny via talk < > talk@openstreetmap.org> wrote: > >> I propose to replace following surface tags by doing an automated edit: >> >> obvious typos: >> >>

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

2023-02-11 Thread Marc_marc
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

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

2023-02-11 Thread john whelan
Sounds wonderful. John On Sat, Feb 11, 2023, 12:49 Mateusz Konieczny via talk < talk@openstreetmap.org> wrote: > I propose to replace following surface tags by doing an automated edit: > > obvious typos: > > `surface=paving stones` → `surface=paving_stones` > `surface=Paving_stones` →

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

2023-02-11 Thread Brian M. Sperlongano
I agree with the proposed edits. On Sat, Feb 11, 2023 at 12:58 PM Mateusz Konieczny via talk < talk@openstreetmap.org> wrote: > 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

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

2023-02-11 Thread 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

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

2023-02-11 Thread 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:

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

2023-02-11 Thread 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

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

2023-02-11 Thread Graeme Fitzpatrick
On Sat, 11 Feb 2023 at 20:37, Warin <61sundow...@gmail.com> wrote: > 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). > Yeah, I've previously seen comments from people in the US that

[talk-au] NSW Fire Station names

2023-02-11 Thread Warin
Hi, I came across this while separating amenity=fire_station from their building=*. The object is to map the amenity with all the name, operator, etc tags on the amenity and leave the building alone. The names on the DCS Base Map do not match some of the names on the OSM map. For Fire and

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

2023-02-11 Thread Warin
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