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

[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.  And,
> once once gets the data under ODbL, it can be redistributed, and there's
> no requirement that I see to impose the Website Terms on others.
>
 "The ODbL allows you to use the OSM data for any purpose you like. This
includes personal, community, educational, commercial or governmental." [0]

If this isn't the case, then the above referenced OSMF page should be
edited to reflect this.

Mike


[0]
https://wiki.osmfoundation.org/wiki/Licence/Licence_and_Legal_FAQ#1.3._What_can_I_do_with_the_OSM_Data
?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[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 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.  And,
once once gets the data under ODbL, it can be redistributed, and there's
no requirement that I see to impose the Website Terms on others.

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

Re: [talk-au] NSW Fire Station names

[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 it has never been 
changed on the Base Map . That is the most obsolete item that I have identified 
but it is a reminder that names on the Base Map are not necessarily current.



On Sun, 12 Feb 2023, at 8:54 AM, cleary wrote:
> 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 names contrary to those signposted at locations 
> (e.g. in Murray River LGA). As far as I can ascertain, there is no 
> regular process for updating the Base Map and it seems to depend on 
> each particular agency such as the local government body, Roads and 
> Maritime Services, Rural Fire Service or Health Service to instigate 
> changes of details for their assets. It does not always happen. 
>
> In the past I have contacted local councils about some conflicting 
> information and always have been given information that the Base Map 
> showed obsolete information. In regard to fire stations, I would think 
> the operators, Fire and Rescue NSW or the Rural Fire Service would be 
> the most authoritative sources regarding names for their facilities.
>
> The Base Map is a wonderful resource that I have used extensively but I 
> have learned that if there is contradictory information from another 
> source, especially survey or the operators of the facilities, then the 
> information from the other source should prevail.
>
>
>
> On Sat, 11 Feb 2023, at 9:58 PM, Warin wrote:
>> 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 Rescue NSW the DCS base map has, for example ‘Lane Cove 
>> Fire Station’ while OSM has ‘Fire and Rescue NSW Station 167 Lane Cove 
>> (in the tagging guidelines). The number appears to be a ‘station number’ 
>> – see https://www.fire.nsw.gov.au/station_list/ The names there on the 
>> station list comply with the DCS Base Map … and it is how I would ask 
>> for them at the pub/in the street. I think the number may be best 
>> entered under the tag ‘ref=*’ and the name as per the DCS Base Map. So 
>> I'd like to change the names to comply wit the DCS Base Map.
>>
>> Additional notes?
>>
>> The name tag is for 'the common name'.
>>
>> The long winded name looks to be some 'public service' name for pollies 
>> to use  ..
>>
>> And we have official_name ... "Useful where there is some elaborate 
>> official name, while a different one is a common name typically used"
>>
>>
>> The quoted text comes from the OSM wiki.. honest.
>>
>> --
>>
>> For the Rural Fire Service some names are ‘Nowhere Rural Fire Service’ 
>> where the DCS Base Map would have ‘Nowhere RFB’ (‘Nowhere’ is an example 
>> – don’t have one to hand). I take ‘RFB’ to be an abbreviation of ‘Rural 
>> Fire Brigade’, where as  Rural Fire Service is an abbreviation of the 
>> operator.
>>
>>   I think ‘Nowhere Rural Fire Brigade’ is the correct name.
>>
>> Thoughts??
>>
>>
>> ___
>> 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

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

Re: [talk-au] NSW Fire Station names

[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 names contrary to 
those signposted at locations (e.g. in Murray River LGA). As far as I can 
ascertain, there is no regular process for updating the Base Map and it seems 
to depend on each particular agency such as the local government body, Roads 
and Maritime Services, Rural Fire Service or Health Service to instigate 
changes of details for their assets. It does not always happen. 

In the past I have contacted local councils about some conflicting information 
and always have been given information that the Base Map showed obsolete 
information. In regard to fire stations, I would think the operators, Fire and 
Rescue NSW or the Rural Fire Service would be the most authoritative sources 
regarding names for their facilities.

The Base Map is a wonderful resource that I have used extensively but I have 
learned that if there is contradictory information from another source, 
especially survey or the operators of the facilities, then the information from 
the other source should prevail.



On Sat, 11 Feb 2023, at 9:58 PM, Warin wrote:
> 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 Rescue NSW the DCS base map has, for example ‘Lane Cove 
> Fire Station’ while OSM has ‘Fire and Rescue NSW Station 167 Lane Cove 
> (in the tagging guidelines). The number appears to be a ‘station number’ 
> – see https://www.fire.nsw.gov.au/station_list/ The names there on the 
> station list comply with the DCS Base Map … and it is how I would ask 
> for them at the pub/in the street. I think the number may be best 
> entered under the tag ‘ref=*’ and the name as per the DCS Base Map. So 
> I'd like to change the names to comply wit the DCS Base Map.
>
> Additional notes?
>
> The name tag is for 'the common name'.
>
> The long winded name looks to be some 'public service' name for pollies 
> to use  ..
>
> And we have official_name ... "Useful where there is some elaborate 
> official name, while a different one is a common name typically used"
>
>
> The quoted text comes from the OSM wiki.. honest.
>
> --
>
> For the Rural Fire Service some names are ‘Nowhere Rural Fire Service’ 
> where the DCS Base Map would have ‘Nowhere RFB’ (‘Nowhere’ is an example 
> – don’t have one to hand). I take ‘RFB’ to be an abbreviation of ‘Rural 
> Fire Brigade’, where as  Rural Fire Service is an abbreviation of the 
> operator.
>
>   I think ‘Nowhere Rural Fire Brigade’ is the correct name.
>
> Thoughts??
>
>
> ___
> 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] [automated edit] replace some obviously mistaken surface values by their clear intended meaning

[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 iD/josm/... validatorwhen 
you edit an object and you are about to reintroduce one of these errors


A better solution would be overpass the database for these sort of edits 
done in the previous seven days.  Then flip one automated email noting 
the accepted practice is XYZ but a bot will correct their edits.  If you 
can grab the language of the mapper that might help here.


concerns 1)
the one who edited the object is not necessarily the one who made the 
typeface


concern 2)
why wait 7 days to inform a user if the validator of his editor
is able to do it before uploading, by generating a message
in the language of the editor?
warning a user after upload is only useful/necessary in the case
of errors that an editor does not want to add a validation rule (e.g.
a team refused one or other of my proposals because of errors that were 
not frequent (anymore) enough, so next time I would submit the proposal 
before mass editing or in 1 year's time when the number will have 
increased again




___
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

[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
___
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

[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
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] [automated edit] replace some obviously mistaken surface values by their clear intended meaning

[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 overpass the database for these sort of edits
done in the previous seven days.  Then flip one automated email noting the
accepted practice is XYZ but a bot will correct their edits.  If you can
grab the language of the mapper that might help here.

Cheerio John

On Sat, Feb 11, 2023, 13:24 Marc_marc  wrote:

> 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
>
> Regaards,
> 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] replace some obviously mistaken surface values by their clear intended meaning

[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
https://lists.openstreetmap.org/listinfo/talk

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

[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:
>>
>> `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
>>
> ___
> 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] [automated edit] replace some obviously mistaken surface values by their clear intended meaning

[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 mass editing
I don't know if it is possible but 2 rules could group many cases:
surface= uppercase -> lowercase
surface= space -> underscore

Regaards,
Marc



___
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

[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` → `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
>
___
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

[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 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
>
___
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] Adoption of OSM geometry as state mapping base

[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 their
Counties Emergency Services use OSM as it shows all the back roads & so on

Thanks

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

[talk-au] NSW Fire Station names

[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 Rescue NSW the DCS base map has, for example ‘Lane Cove 
Fire Station’ while OSM has ‘Fire and Rescue NSW Station 167 Lane Cove 
(in the tagging guidelines). The number appears to be a ‘station number’ 
– see https://www.fire.nsw.gov.au/station_list/ The names there on the 
station list comply with the DCS Base Map … and it is how I would ask 
for them at the pub/in the street. I think the number may be best 
entered under the tag ‘ref=*’ and the name as per the DCS Base Map. So 
I'd like to change the names to comply wit the DCS Base Map.


Additional notes?

The name tag is for 'the common name'.

The long winded name looks to be some 'public service' name for pollies 
to use  ..


And we have official_name ... "Useful where there is some elaborate 
official name, while a different one is a common name typically used"



The quoted text comes from the OSM wiki.. honest.

--

For the Rural Fire Service some names are ‘Nowhere Rural Fire Service’ 
where the DCS Base Map would have ‘Nowhere RFB’ (‘Nowhere’ is an example 
– don’t have one to hand). I take ‘RFB’ to be an abbreviation of ‘Rural 
Fire Brigade’, where as  Rural Fire Service is an abbreviation of the 
operator.


 I think ‘Nowhere Rural Fire Brigade’ is the correct name.

Thoughts??


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

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

[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 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).


See https://www.openstreetmap.us/2021/06/map-for-emergency/

On Fri, 10 Feb 2023 at 12:24, Andrew Harvey  
wrote:


Hi Rob,

Interesting point you raise!

While on the surface you'd think terms (from the OSMF Terms of Use

https://wiki.osmfoundation.org/wiki/Terms_of_Use#III._Unlawful_and_other_unauthorized_uses)
only ask you not to use OSMF services like the website, API for
those purposes and not the data, it includes "data distribution".

I suggest you raise this on the legal talk mailing list
https://lists.openstreetmap.org/listinfo/legal-talk and/or
directly with the OSMF legal-questi...@osmfoundation.org
(https://wiki.osmfoundation.org/wiki/Contact).

On Fri, 10 Feb 2023 at 11:41, rob potter  wrote:

Hi,

I am representing the state transport department Department of
Transport and Planning (Victoria, Australia) - OpenStreetMap
Wiki


 and
we are looking to consume the OSM road & rail networks for our
operations.

*Lawyers have raised a concern about these conditions, as the
road data use is supplied to our emergency services fire and
ambulance.  We have not started using the information but we
are implementing a system of validation and change detection,
then produce an authoritative version for other agency
consumption.*
/*_Unlawful and other unauthorized uses_ include a clause
"Operate dangerous businesses such as emergency services or
air traffic control, where the use or failure of the Services
could lead to death, personal injury or significant property
damage;" and "Store data available through the Services in
order to evade these Terms (including aiding anyone else in
doing so); or"*/
/
/
Please any advice would be greatly appreciated, ultimately we
will enhance the overall content of OSM in the Victoria, but
really do not want to cause problems later.

Thanks,

Rob
___
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___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au