Re: [talk-au] How to efficiently improve AU address coverage?

[Simon Poole]

Except if something has massively changed, the GNAF data isn"t actually open.

Am 2. Oktober 2023 13:05:10 MESZ schrieb Daniel O'Connor 
:
>While OSM doesn't have layers, https://openaddresses.io/ more or less acts
>as the address layer. The datasets there aren't all ODBL, but they are
>generally open. It includes GNAF. Given how frequently addresses update, to
>keep it in sync with OSM would be pretty significant and hard to reconcile
>with surveyed, on the ground data.
>
>Getting addresses into OSM is useful for routing, etc, but there might be
>more niche datasets that can be of value.
>
>Maproulette is potentially a good way to generate *probably correct but
>needs verification *data.
>Are there questions you can frame that people can answer with remote
>mapping?
>
>IE:
>Company X has said they will put solar on all of their stores by (date),
>but there are no solar panels within 50m of (store.location)
>Company Y shut down, is this store still open?
>School area Z doesn't have any sports fields/buildings/etc - are there any
>to be mapped?

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Jardin Line Renaud à PARIS

[Gaël Simon]

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

Re: [OSM-talk] mapilio? (street-level imagery)

[Simon Poole]

Am 31.05.2023 um 22:08 schrieb Christian Quest:


... OSM editors integration.


That was one of the reasons why I was asking, as I have already done 
some work on a STAC layer based on the GeoVisio API.


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] mapilio? (street-level imagery)

[Simon Poole]

Christian, does this relate in some fashion to Geovisio?

And a, I suppose, obvious observation: key for adoption in OSM would be 
an easy to access API for editing apps. Does that exist/are there plans 
for one?


Simon

Am 30.05.2023 um 16:01 schrieb Christian Quest:

Le 24/05/2023 à 14:31, Greg Troxel a écrit :

I just got spam from mapilio, implying that I was a "Mapilio
contributor".  This was, to my memory, the first I had heard of them.


I have avoided most street-level imagery schemes as not being
structurally similar to OSM (open source tooling, community project and
licensing scheme).



I'm not answering directly to your post, but I think you may like my 
answer ;)



I'm currently working on the Panoramax project, co-originated by 
OpenStreetMap France and IGN (Institut Géographique National).


In the very near future, we should have a street-level imagery offer 
that matches:


- open source tooling

- community project

- (real) open licensing scheme

as well as...

- decrentralized / federated solution... to avoid having one more time 
a single point of failure with an actor hosting all the pictures !


We have not communicated much so far except in France on 
https://panoramax.fr/ as we're still working on the MVP.





OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Simon Poole]

Am 12.04.2023 um 16:20 schrieb 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


It should be noted that this guideline follows from the concept of 
Collective Databases in the ODbL and in general of the idea of works 
that can have multiple independent constituent parts. If what Mapbox is 
doing is consistent with the licence naturally depends on the specifics 
as Mateusz write, Marc, do you have a link to the discussion in question?


Simon



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


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Simon Poole]

Not quite unexpected this discussion has already gone off on a tangent 
about stable ids. My question on the other hand would be: what do you 
actually want to achieve and what would you expect an application to do 
with the parameter?


It should be noted that we already have a couple of URI schemes in use 
for OSM based tools/editors, and naturally the website object/element 
browsing support.


Simon

Am 02.01.2023 um 18:57 schrieb Sören Reinecke:


Hey,

It came into my mind to get IETF to standardize a parameter explicitly 
linking to osm objects with their corresponding type and id.


The 'geo' URI scheme is standardized as RFC 5870 
<https://www.rfc-editor.org/rfc/rfc5870> with examples of usage 
<https://www.rfc-editor.org/rfc/rfc5870#section-6>. It allows us to 
link to geospatial ressources from web pages or applications 
supporting URI schemes in general. It allows (web) developers to 
direct their users to their map browser of use e.g, Organic Maps, 
Google Maps, Apple Maps, ... The official osm.org makes use of this 
specification in the "share" feature already. Currently it only 
supports linking to geospatial ressources by their coordinates and not 
some id. As OpenStreetMap is playing an important part in the 
geospatial world, the OSMF should try to get IETF convinced.


See registered URI parameters in the 'geo' URI scheme:
'geo' URI Parameters registry at IANA.org 
<https://www.iana.org/assignments/geo-uri-parameters/geo-uri-parameters.xhtml>


Our own parameter could have the following syntax:

osmid=(N|W|R)


What do you think?

Greetings

Sören Reinecke


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


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] 'Named' EV chargers

[Simon Poole]

See https://www.openstreetmap.org/user/SimonPoole/diary/397565 while 
amenity=charging_station is not the worst offender, it is still pretty 
bad 
https://github.com/osmlab/name-suggestion-index/blob/main/data/brands/amenity/charging_station.json


Am 15.12.2022 um 04:20 schrieb Phil Wyatt:


Hi Folks,

Thoughts on 'named' EV chargers? Around 50% of chargers in Oz have 
some 'name'.


Most look to be adding the either the location or name of the operator 
etc (ie Freds Shop, XYZ carpark, Tesla supercharger etc), I suspect so 
it gets rendered on the map.


Are folks happy if I remove the names. I will ensure that no details 
are lost by making sure any operator or network details gets added to 
the correct tags.


(I will also post to Oceania Forum and Discord)

[Overpass query](https://overpass-turbo.eu/s/1p4u)

Cheers - Phil


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


OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

[Simon Poole]

Am 30.11.2022 um 18:50 schrieb Minh Nguyen:

..
The contributor terms in question state:

This Agreement shall be governed by English law without regard to 
principles of conflict of law.
[1] 
https://wiki.osmfoundation.org/wiki/Special:PermanentLink/9165#Miscellaneous


My understanding of what the board wants is simply that the terms that 
we get to utilize 3rd party data under do not conflict with the 
contributor terms, that is something very different than asking a 3rd 
party source to agree to the contributor terms. Definitely the OSMF is 
free to, negotiate terms that do not specify English law.


Simon

PS: note on the side: the ODbL doesn't specify EN law.



OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

[Simon Poole]

Am 29.11.2022 um 15:30 schrieb Greg Troxel:

...
Also, what we need is a copyright license, so that's not necessarily --
and hopefully isn't -- a contract.
Well there is this kind of underlying assumption that for most material 
in question, with the exception of actual maps, there is no copyright 
protection in the US and we are talking about contractual arrangements 
(I'm not going to dive in to the aspect that different jurisdictions 
have different implementations of how this all works, but see for 
example https://lwn.net/Articles/747563/). This is in any case just my 
take and the OSMF might have a completely different position for 
tactical reasons.

   It seems obvious that asking a US
entity to enter into a contract under foreign law (and the same is
almost certainly true for any government entity in any other
jurisdiction) is just not going to fly.


You are assuming that the OSMF would require UK law, which might or 
might not be the case.


Simon



OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

[Simon Poole]

Hi Tobias

That sounds better.

The main question is what "expect it to survive a hypothetical license 
change" implies. My expectation is that because of practical 
considerations any future licence would require downstream attribution 
of OSM so that the OSMF can continue to offer third party sources 
indirect attribution. You could naturally argue about how much the OSMF 
is committed to individual sources to keep the chain OSM attribution -> 
3rd party source attribution around, but that disruption is not worth it 
IMHO.


Simon

Am 29.11.2022 um 00:48 schrieb Tobias Knerr:

On 28.11.22 at Simon Poole wrote:

What is "OSM Contributor Terms compatibility" supposed to be?


Ok, this is clearly imprecise wording.¹

The context is that we would like to offer data donors a standard 
legal text that they can use to make their data available to OSM in 
such a way that we would expect it to survive a hypothetical license 
change. And yes, this would perhaps look similar to a CC0 waiver, 
except that it could potentially be a bit more limited (in a similar 
way the CT limits the set of licenses under which the OSMF can choose 
to publish the database).


So the column would be mostly about whether this legal text or 
something equivalent has been signed or not (+ perhaps public 
domain/CC0 data that has the ability to survive a license change by 
default could also check the box).


Tobias

¹ The wording is my fault and, iirc, was inspired by the column name 
at https://wiki.osm.org/Import/ODbL_Compatibility



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


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

[Simon Poole]

Am 29.11.2022 um 03:57 schrieb Minh Nguyen:

Vào lúc 15:48 2022-11-28, Tobias Knerr đã viết:

On 28.11.22 at Simon Poole wrote:

What is "OSM Contributor Terms compatibility" supposed to be?


Ok, this is clearly imprecise wording.¹

The context is that we would like to offer data donors a standard 
legal text that they can use to make their data available to OSM in 
such a way that we would expect it to survive a hypothetical license 
change. And yes, this would perhaps look similar to a CC0 waiver, 
except that it could potentially be a bit more limited (in a similar 
way the CT limits the set of licenses under which the OSMF can choose 
to publish the database).


So the column would be mostly about whether this legal text or 
something equivalent has been signed or not (+ perhaps public 
domain/CC0 data that has the ability to survive a license change by 
default could also check the box).


Could you clarify the "perhaps" here? If something has been explicitly 
dedicated to the public domain via CC0, a similar statement, or a 
relevant law, should it not survive any relicensing attempt? Or is 
this just about the editorial decision of whether to leave the table 
cell blank if relicensing is irrelevant for a given import? The wiki 
has a {{n/a}} template for this purpose.
I don't see a problem here,  PD works / data and CC0 licenced material 
do not restrict how you use them in any fashion so I don't see why any 
action would be required.


I've already heard concerns from a couple U.S. mappers about this 
thread, because the community here been operating under the assumption 
that public domain datasets are the best-case scenario for inclusion 
in OSM. If a local government agency has already released something 
into the public domain, irrevocably and so forth, it would be 
counterproductive to send their legal department a scary-looking 
document to fill out. I don't know how I'd convince them that they 
have the legal authority to enter into an agreement governed by 
English law. Hopefully I'm overreacting.






OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

[Simon Poole]

Am 28.11.2022 um 20:11 schrieb Amanda McCann:

Hello fellow OSMers.

As you are no doubt aware, OSM requires that data imports be listed on the OSM 
Wiki ( https://wiki.openstreetmap.org/wiki/Import/Catalogue ), including if the 
source is “ODbL OK status”.

At the Nov. 2022 OSMF Board meeting (25 Nov), the Board voted that imports 
should, from now on, list whether the data source is compatibly (or 
incompatible) with the OSM Contributor Terms¹.


The board has obviously been reading too much Greek mythology (or maybe 
Batman) and has taken to speaking in riddles :-)


What is "OSM Contributor Terms compatibility" supposed to be? 
Sub-licenseable? Neither the ODbL nor any CC licence with exception of a 
CC0 waiver allow this. Compatible with the licence change provisions? As 
an absolute that is going to be very difficult as the only requirement 
is for a new licence to be "open". It would definitely exclude all 
share-alike licences including naturally the ODbL except if the target 
licence is compatible with the original licence. Has the LWG been asked 
for an opinion, list of compatible/incompatible licences? That's just 
what immediately comes to mind.


A further note "As you are no doubt aware, OSM requires that data 
imports be listed on the OSM Wiki" has never been a formal OSMF policy. 
Yes it would have always made sense to have stricter controls on imports 
in particular not only licence compatibility but proper documentation 
including contacts. But that was politically always untenable and that 
particular horse has long bolted.


Simon


The Board has also budgeted to commission a template that OSMers can use to 
request that data sources release their data under those terms. That will obv. 
follow later. However given that OSM is mostly volunteer run, I don't know 
if/when that will be ready for you.

The minutes of the meeting have not yet been written, nor accepted, but when 
they are (in about a month), you will find the specifics here): 
https://wiki.osmfoundation.org/wiki/Board/Minutes/2022-11

¹ https://wiki.openstreetmap.org/wiki/Open_Database_License/Contributor_Terms



OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Use of "Proprietary" imagery to edit OSM

[Simon Poole]

Am 27.10.2022 um 06:17 schrieb Michael Collinson:
and note that Bing imagery is provided to us on the same basis - for 
use in OSM but not otherwise.


Mike


Bing imagery is available for inspection to everybody, for use in OSM 
terms are relaxed that would otherwise prohibit tracing etc.


Not comparable to not having access to the source at all, in this case 
we don't even know if the Lyft employee is referring to street level 
images (which might actually need processing before release), or 
aerial/sat imagery.


Simon



On 2022-10-27 00:08, Clifford Snow wrote:


On Wed, Oct 26, 2022 at 2:59 PM Mike Thompson  
wrote:


Concerning this changeset:
https://www.openstreetmap.org/changeset/128035436

Changeset comment:

added missing roads according to proprietary aerial imagery

Editing organization's follow on comment:
"Proprietary" for Lyft meaning "provided to us for use in OSM but
not the general public"

Is this acceptable?  In my mind it is not as the whole community
should have access in order to verify and build on these edits.

I look at it as if they were using local knowledge. For example, If I 
walk downtown and take pictures of business doors to capture address, 
name, and hours for use in updating OSM but don't upload those pics - 
I consider that acceptable.


For Lyft to make their imagery public they would have to insure that 
nothing private, such as faces, license plates, etc. I'm sure they 
don't want the added cost required make them public.


Clifford

--
@osm_washington
www.snowandsnow.us <https://www.snowandsnow.us>
OpenStreetMap: Maps with a human touch

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



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


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Vespucci - Proximity Alerts - Not working

[Simon Poole]

Am 12. Oktober 2022 20:04:42 MESZ schrieb Mike Thompson :
>On Wed, Oct 12, 2022 at 11:42 AM Simon Poole  wrote:
>
...
>>
>Thanks.  Unfortunately most of the time I will be surveying without a data
>connection, so this isn't going to work for me.

I would recommend using an offline data source in such a scenario, see 
https://www.openstreetmap.org/user/SimonPoole/diary/193235

>> Simon
>>
>> PS: osm-talk is not a suitable forum for support questions.
>>
>Sorry, what do you recommend?

Our github repo, or help.openstreetmap.org (and sometime in future its 
replacement).

Simon
>
>Mike

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.

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

Re: [OSM-talk] Vespucci - Proximity Alerts - Not working

[Simon Poole]

The alerts are generated when data is downloaded/merged and the device location 
is within the specified radius around the object causing the notification.

With other words you need to have one of the auto download options enabled for 
the mechanism to work (or you need to replace all the data).

Simon

PS: osm-talk is not a suitable forum for support questions.

Am 12. Oktober 2022 18:29:37 MESZ schrieb Mike Thompson :
>I am trying to get Vespucci to give me an audible alert when I travel to
>within a certain distance of a OSM map note, or a OSM object with a fixme
>tag.  I have not been able to get this feature to work, at least not in the
>manner that I would like it to work.  It does alert when I initially
>download OSM data for any notes etc. that are near my location at that
>time.  This is expected.  However, when I then travel to another location
>within the download area with a note, etc., Vespucci does not produce an
>alert.
>
>* "Generate notifications" is turned on
>* "Max distance for notifications" is 30 meters - under most conditions my
>phone's location should be more accurate than that.
>
>What am I doing wrong?
>
>Mike

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] Mapping surf breaks

[Simon Slater]

On Thursday, 25 August 2022 15:44:30 AEST Graeme Fitzpatrick wrote:
> Earlier I mentioned about the Kirra Superbank that only occurs a "few"
> times per year. While the rest of the year is perfectly acceptable, those
> few times are exceptional! (Think rides over 1 km long! :-))

I am definitely no surfer, but what about tidal bores?   Apparently Australia 
has some: https://www.australiangeographic.com.au/blogs/tim-the-yowie-man/
2020/01/surfing-the-mysterious-tidal-bores-of-australia/ 

-- 
Simon Slater

signature.asc
Description: This is a digitally signed message part.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] New OSM Discourse site: community.osm.org

[Simon Poole]

I wouldn't expect much traffic till the existing forum content has been 
migrated, currently scheduled for the end of the month. That should then 
give some slightly more definite structure to things than there is now.


Simon

Am 02.05.2022 um 05:01 schrieb Sam Wilson:


It's growing in use, I think (not with Australia-specific discussion).

It feels like a pretty good site, I check the headlines most days, and 
I think one advantage is being able to get a feel for what's being 
discussed elsewhere. Also to have location-specific discussions that 
benefit either from the input of people elsewhere or to let other 
people know how one place is doing things.


I don't like the notification system that much, but part of that is I 
think that the ratio of meta posts to real topical ones is quite large 
at the moment. It is decreasing though, as more people take part.


—Sam


On 1/5/22 06:28, Graeme Fitzpatrick wrote:

So how's it going after this first month?

Any marked advantages / disadvantages over the existing mailing list?

Thanks

Graeme


On Tue, 22 Mar 2022 at 12:52, Sam Wilson  wrote:

The new community.openstreetmap.org
<https://community.openstreetmap.org> site is up and running.

It's going to replace the old forum, including the users:
Australia <https://forum.openstreetmap.org/viewforum.php?id=24>
subforum.

I'm not sure if we should ask for an Australia category to be
created on the new site. Probably not worth it until there's some
amount of content relating to Australia.


___
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


OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

[OSM-talk-fr] Atelier Etalab licence ODBL

[Simon Réau]

Bonjour,

Etalab organise un atelier sur la licence ODBL
https://www.eventbrite.fr/e/billets-openlab-conditions-dutilisation-odbl-323792541207

Cordialement


Simon REAU
GEOVELO
www.geovelo.fr
simon.r...@geovelo.fr
1 Impasse du Palais, 37000 Tours <https://osm.org/go/0AU_thgO7?m=>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] Attribution 4.0 International (CC BY 4.0)

[Simon Poole]

Just to clarify, the OSMF doesn't just requires the waiver because it is 
being difficult.


CC BY has fundamental issues that are widely ignored, the blog post is 
simply the diplomatic summary that we hammered out together with CC (it 
says so much in the text).


Simon

Am 01.12.2021 um 07:54 schrieb Brendan Barnes:

Hey John,

The Legal Eagles of the OSMF Licence Working Group continue to ask for 
explicit permission (ie waiver) for CC BY 4.0. The rationale is at 
https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/


You can reach them via their contact details at 
https://wiki.osmfoundation.org/wiki/Licensing_Working_Group for any 
clarifications, but it appears they have already assessed the wording 
in CC BY 4.0.


I know waivers can be difficult to obtain, and government entities may 
have internal red tape or few resources available to supply one to the 
OSM community. However it's in everyone's best interest, and once we 
have a waiver on file for the agencies' datasets, they are good to use 
indefinitely.


..Brendan


On Wed, 1 Dec 2021 at 15:53, John Luan  wrote:

Hi Guys,

Had a look at this license
https://creativecommons.org/licenses/by/4.0/deed.en

Do we really need a waiver from the data provider? something like
this

https://wiki.openstreetmap.org/w/images/1/17/AADC_CC-BY_Permission_JK_signed.pdf

My feeling is that as long as we list the data provider on the
contributor list, it should be fine.

Regards,
John
___
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


OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Suburbs: Nodes, Areas, or both?

[Simon Poole]

Am 06.11.2021 um 10:22 schrieb fors...@ozonline.com.au:

Quoting Simon Poole :

PS: wondering why Gruyere has that name.


Good question.
The town is named for a variety of cheese, as the area's history is in 
the dairy industry. Cahillton Post Office first opened on 20 August 
1892. It was renamed Gruyere in 1950 and closed in 1960

Wikipedia

Yes, Gruyère is a cheese, it's named after the town of Gruyères see 
https://en.wikipedia.org/wiki/Gruy%C3%A8res, very nice place BTW. That's 
why I was wondering :-), but I suppose the dairy indsutry explains it.


Simon


Tony




OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Suburbs: Nodes, Areas, or both?

[Simon Poole]

This is a somewhat unsolved issue in OSM modelling, as both area 
(extent) and node (assuming it is not simply the centroid of the area) 
convey geometric information that the other cannot. IMHO best would be 
to have a similar concept as we do for administrative areas that works 
for "places" in a more general sense, that is that allows simple 
deduplication of the elements.


A rather epic discussion on the topic can be found here: 
https://github.com/gravitystorm/openstreetmap-carto/pull/2816


Simon

PS: wondering why Gruyere has that name.

Am 05.11.2021 um 07:53 schrieb cleary:

Ideally suburbs would have a relation for the boundary PLUS a node for the "label 
node" as part of the relation.   I'm not so familiar with Victorian locations, but 
this example for South Albury in NSW is an example:
https://www.openstreetmap.org/relation/5901488

Where there is a boundary and a separate place node, I would add the place node to the 
relation and its role would be "label node".



On Fri, 5 Nov 2021, at 2:15 PM, Dian Ågesson wrote:

Hey all,

I would appreciate the thoughts of the community with regards to suburb
representations.

In a recent change set
(https://www.openstreetmap.org/changeset/113355648) a node was
introduced for Gruyere. Gruyere is on the urban boundary, but is
technically in Metropolitan Melbourne. As such, it straddles the border
between what could be considered a bona fide suburb, and an independent
town.

Mick has correctly pointed out that many of the other localities in the
area are represented by both an area and a node.

Is this the way all suburbs should be represented? Or is it an
urban/rural distinction?



Dian

___
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


OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Lifeguards & "Swim Between the Flags"

[Simon Slater]

On Wednesday, 20 October 2021 9:54:22 AM AEDT Graeme Fitzpatrick wrote:
> A little while back, I put the emergency=lifeguard proposal through,
> together with lifeguard=yes to describe those times when there is a
> lifeguard/s on the beach, but they may not be in a fixed location.
> 
 
> Or do we just not worry about it, & work on the idea that =yes is
> sufficient?
> 
When I were a lad, we were taught to always look for the flags when going to 
any beach to swim, teaching personal responsibility and obey the flags because 
the lifesavers know that beach better.  Therefore, actual flag positions need 
to be known as variable.

However, tagging a beach that does have a SLSC is good because those 
unfamiliar with the area, tourists say, or families with young children, can 
then preferentially choose such beaches.  Similarly, the more adventurous, or 
those desiring solitude, can preferentially choose alternate locations.

-- 
Regards
Simon Slater

Registered Linux User #463789 @ http://linuxcounter.net

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

Re: [talk-au] Tagging yellow buoys

[Simon Slater]

On Thursday, 30 September 2021 1:06:31 PM AEST Ben Kelley wrote:
> where the oysters grow

Oyster leases.
-- 
Regards
Simon Slater

Registered Linux User #463789 @ http://linuxcounter.net

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

Re: [talk-au] Friend requests from 'Porn Bots'

[Simon Poole]

Am 12.09.2021 um 13:56 schrieb Andy Townsend:


It'll hopefully be deleted by the time that anyone gets to read this, 
so not much point really.



Getting their link distributed is exactly what the operators want, so 
-never- do that.




OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Import vs filtering query

[Simon Poole]

Hi

Your proposed workflow would seem to be totally OK to me and is clearly 
not an import. List the government data in the sources used in the 
changeset and IMHO you are good to go.


Simon

Am 04.09.2021 um 12:51 schrieb Little Maps:


Hi all, my understanding is that the process described below is a big 
filtering exercise rather than a data import, but since I’ve never 
been involved in an import before, I’d like to check before 
progressing. Thanks in advance for your feedback.



Goal: to update road surface tags across regional Victoria where 
necessary. Many surface tags were added 8-10 years ago and a 
surprising number of roads have been surfaced since then. (I’m only 
interested in sealed/paved vs unsealed/unpaved options, not subsets of 
these.)



Method: compare road surface data in OSM against data in the Vic 
government’s transport dataset which we have permission and waiver to 
use. All rural roads from motorways to unclassified (not residential, 
service, etc) that have different tags in OSM and the gov dataset will 
be examined against satellite imagery and Mapillary, and any decisions 
on whether to update the surface tags will be made based solely on the 
imagery. No data will be directly copied from the gov dataset. Hence, 
as I understand osm’s import guidelines, this is a big filtering 
exercise rather than an import. Is that a correct interpretation? I’ve 
added a longer explanation below to help answer any questions.



Basic assumptions: (1) I assume both datasets were made independently, 
as I’ve not seen any evidence that OSM surface tags were copied from 
the Vic data (or that the gov copied from OSM). (2) If the 2 
independent datasets both indicate the same surface then I assume it 
is most likely to be correct. If they indicate different surfaces then 
one must be in error. At the outset, I have no idea how accurate the 
Vic gov dataset is, so I’m not assuming it is infallible (it’s 
definitely not; see comment below).



Methods: for every road segment that has a different surface tag in 
the 2 datasets, I’d inspect the road using available imagery, as is 
normally done when adding or updating a surface tag. Existing OSM tags 
will either be altered or retained, as required. There’s no ambiguity 
involved in updating a tag from unpaved to paved. It’s much less 
common to need to update a tag from paved to unpaved. Again, this will 
be done based on imagery, regardless of what the Vic data says.



Some prelim observations: I’ve trialled the method in NW Vic, where 
the method works fine on longer road segments/ways. The approach would 
have to be restricted to ways > 1-2 km long, and short ways will be 
ignored. From an initial subset of about 50 roads > 5 km long in NW 
Vic, I found about 2/3 of the discrepancies between the 2 datasets did 
not warrant any change in OSM and about 1/3 did. The Vic gov data 
doesn’t seem to be as up-to-date as the imagery and isn’t by any means 
perfect. Regardless, the approach looks to be a very effective way to 
find out-of-date and inaccurate road surface data across the state.



At this stage I don’t know how many ways will be examined or changed, 
as it will depend on the minimal length of road I inspect. I’m 
envisaging about 1000 at the max, and probably fewer.



My guess is that, if the process was completed across Vic, then the 
surface data in OSM would be extremely accurate, and more accurate 
than in the Vic gov database. If I get through enough of it without 
going bonkers, I’m interesting in summarising the findings to show 
which discrepancies were most common, etc.



So, back to the original question, is this process ok to pursue, given 
that the sole function of the gov dataset is to provide a filtering 
mechanism to identify roads to investigate, and all decisions will be 
made based on legally available imagery, not the gov data?



Thanks very much for your feedback, Ian


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


OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Trouble with routing through an intersection

[Simon Slater]

On Thursday, 2 September 2021 4:03:16 PM AEST Michael James wrote:
> It's possible your change just hasn't made it's way to the routing engines
> yet.
> 
Tried again this morning in OSM and still the same.

> The only issue with the intersection is I would not have that single segment
> between the highway and the 2 slip lanes, just connect the slip lanes
> directly to the highway. This shouldn't stop a routing engine finding a
> path.
Yes, I thought that short stretch seemed odd.  I'll delete that then and join 
each side of the traffic island directly to the Calder Hwy.

With this method, will I need to do anything to not disturb Route C274 which 
uses that segment?
-- 
Regards
Simon Slater

Registered Linux User #463789 @ http://linuxcounter.net

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

[talk-au] Trouble with routing through an intersection

[Simon Slater]

G'day all,
This morning I created a route from Serpentine to Castlemaine 
and at 
one intersection the route would backtrack.  Located a way at the intersection 
with one-way set incorrectly ( I travel through this intersection often) and 
made this change https://www.openstreetmap.org/changeset/110588330 but now, a 
few hours later the routing is still wrong: 
https://www.openstreetmap.org/directions?
engine=fossgis_osrm_car=-36.59894%2C143.93811%3B-36.59984%2C143.93824
Can anyone see what is wrong at this intersection in the changeset?
-- 
Regards
Simon Slater

Registered Linux User #463789 @ http://linuxcounter.net

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

Re: [talk-au] Mapping driveways under awnings.

[Simon Slater]

On Wednesday, 11 August 2021 7:27:40 PM AEST Michael Collinson wrote:
> Simon,
> 
> Without knowing the nature of the challenge, I assume the apparent
> anomaly is a road apparently bulldozing through a building.
> 
Yes the challenge is for road/building intersections.

> Me, I'd either leave it as it is or to be squeaky clean (if I know from
> on-the-ground) I'd map the two sticky out bits as building=roof. I don't
> know if there is any consensus on whether a simple canvas awning counts
> as a "roof" or a temporary accoutrement not worthy of mapping at all -
> others may comment.
> 
In this case they are just overhangs to keep the sun off while collecting/
waiting for an order.  However, across the road, that shop splits its driveway 
with part under an awning and another which does go right through the 
building, yet neither are mapped in OSM.

Picking up on a recent thread on service roads, I wonder how the specific way 
tags affect the challenge.  I will look to see if they are tagged as road or 
driveway etc.

> This could also be an opportunity to introduce simple 3d buildings. Here
> leave the building as is but within it draw 3 building part areas: 
> building:part=roof, building:part=roof,  building:part=yes
> 
> https://wiki.openstreetmap.org/wiki/Key:building:part
> https://wiki.openstreetmap.org/wiki/Simple_3D_Buildings
> 
> Here is what Swan Hill currently looks like:
> https://demo.f4map.com/#lat=-35.3427895=143.5619395=18
> 
>From this map there are a few other similar instances that stand out.  One is 
a service station awning that shows correctly as an awning and across the road 
a motel whose driveway stops at their office awning,  not continuing through 
to their carpark.  In that same block is another major food outlet with no 
driveways or parking shown on OSM.  Actually, there is a block 2 down from us 
which has 4 shops with drive-under awnings, yet none are in OSM. More work to 
do.

> Mike
> 
> On 2021-08-11 08:23, Simon Slater wrote:
> > G'day all,
> > 
> > From a Maproulette challenge ( https://maproulette.org/browse/
> > 
> > challenges/19168 ) which had a couple of things in our area marked as VIC
> > -
> > BuildingRoadIntersectionCheck , one of which is a KFC drive-through with
> > awnings, see https://www.openstreetmap.org/#map=19/-35.34316/143.56033
> > 
> > Is this something to leave as-is, or should a change be made to either the
> > way or building or both?  If a change is needed, what type?
> 
> _______
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au


-- 
Regards
Simon Slater

Registered Linux User #463789 @ http://linuxcounter.net

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

[talk-au] Mapping driveways under awnings.

[Simon Slater]

G'day all, 
From a Maproulette challenge ( https://maproulette.org/browse/
challenges/19168 ) which had a couple of things in our area marked as VIC - 
BuildingRoadIntersectionCheck , one of which is a KFC drive-through with 
awnings, see https://www.openstreetmap.org/#map=19/-35.34316/143.56033 

Is this something to leave as-is, or should a change be made to either the way 
or building or both?  If a change is needed, what type?
-- 
Regards
Simon Slater

Registered Linux User #463789 @ http://linuxcounter.net

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

Re: [OSM-talk] Making GPS tracks in Android

[Simon Poole]

Non-open apps will typically use googles play services fused location 
provider, which as the name implies doesn't just use GNSS data. For 
generating tracks it is unsuitable in any case so a pure tracker is 
unlikely going to use it.


Simon

Am 21.12.2020 um 01:02 schrieb Alan Mackie:
I have noticed that Google Maps somehow seems to get a location at 
times when all other apps are struggling.


I'm not entirely convinced the playing field is level there.

On Sun, 20 Dec 2020, 18:18 Simon Poole, <mailto:si...@poole.ch>> wrote:


I don't expect side loading to be a thing for very much longer.
Given googles crack down on anything using location, see
https://twitter.com/vespucci_editor/status/1331541328883298306
<https://twitter.com/vespucci_editor/status/1331541328883298306>
for some of the drama, it would seem to be silly to leave that
avenue open. Definitely you are going to run in to problems as
soon as you start building against more recent SDK.

Simon

Am 20.12.2020 um 20:28 schrieb ipswichmapper--- via talk:

In this case simply use Fdroid. Its not hard and the apps on
there give you peace of mind.

--


20 Dec 2020, 19:14 by talk@openstreetmap.org
<mailto:talk@openstreetmap.org>:

Gps logger was perfect, unfortunately :
https://github.com/mendhak/gpslogger/issues/849
<https://github.com/mendhak/gpslogger/issues/849>
Yves

Le 20 décembre 2020 19:43:00 GMT+01:00, Martijn van Exel
 <mailto:m...@rtijn.org> a écrit :

Andy,

If you would like something lightweight that just does
GPS track recording, I would recommend GPS Logger
https://wiki.openstreetmap.org/wiki/GPS_Logger_for_Android
<https://wiki.openstreetmap.org/wiki/GPS_Logger_for_Android> .
A nice bonus is that you can have the app automatically
upload your tracks to OSM in whatever privacy mode you
choose. It can also sync with Nextcloud, Dropbox etc.

OSMTracker offers a little more functionality like
recording waypoints with specific, configurable notes,
and recording audio notes.
https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)
<https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)>

I’m not on Android right now but I’ve used both these OSS
apps for years.

Martijn


On Dec 20, 2020, at 5:36 AM, Andy Mabbett
mailto:a...@pigsonthewing.org.uk>> wrote:

Father Christmas came early this year, and has delivered
to me a smart
new Android phone, whose GPS is much better than on my
old one.

I want to use it to trace some tracks on a local nature
reserve. What
app(s) do you recommend for this?

-- 
Andy Mabbett

@pigsonthewing
http://pigsonthewing.org.uk <http://pigsonthewing.org.uk>

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




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

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



OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Making GPS tracks in Android

[Simon Poole]

I don't expect side loading to be a thing for very much longer. Given 
googles crack down on anything using location, see 
https://twitter.com/vespucci_editor/status/1331541328883298306 for some 
of the drama, it would seem to be silly to leave that avenue open. 
Definitely you are going to run in to problems as soon as you start 
building against more recent SDK.


Simon

Am 20.12.2020 um 20:28 schrieb ipswichmapper--- via talk:
In this case simply use Fdroid. Its not hard and the apps on there 
give you peace of mind.


--


20 Dec 2020, 19:14 by talk@openstreetmap.org:

Gps logger was perfect, unfortunately :
https://github.com/mendhak/gpslogger/issues/849
<https://github.com/mendhak/gpslogger/issues/849>
Yves

Le 20 décembre 2020 19:43:00 GMT+01:00, Martijn van Exel
 a écrit :

Andy,

If you would like something lightweight that just does GPS
track recording, I would recommend GPS Logger
https://wiki.openstreetmap.org/wiki/GPS_Logger_for_Android
<https://wiki.openstreetmap.org/wiki/GPS_Logger_for_Android> .
A nice bonus is that you can have the app automatically upload
your tracks to OSM in whatever privacy mode you choose. It can
also sync with Nextcloud, Dropbox etc.

OSMTracker offers a little more functionality like recording
waypoints with specific, configurable notes, and recording
audio notes.
https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)
<https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)>

I’m not on Android right now but I’ve used both these OSS apps
for years.

Martijn


On Dec 20, 2020, at 5:36 AM, Andy Mabbett
mailto:a...@pigsonthewing.org.uk>> wrote:

Father Christmas came early this year, and has delivered to
me a smart
new Android phone, whose GPS is much better than on my old one.

I want to use it to trace some tracks on a local nature
reserve. What
app(s) do you recommend for this?

-- 
Andy Mabbett

@pigsonthewing
http://pigsonthewing.org.uk <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


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] What is needed for something to be classified as a 'cycle route' (London)

[Simon Still]

> On 15 Dec 2020, at 17:39, Andy Allan  wrote:
> 
> es.
> 
> * Not all bike paths are part of a larger signed cycling route.
> * Not all bike lanes are part of a larger signed cycling route.

But any cycle infrastructure that DOES exist - eg short sections of protected 
cycleway - will be picked up by routing engines and prioritised for routes



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

Re: [Talk-GB] What is needed for something to be classified as a 'cycle route' (London)

[Simon Still]

> On 15 Dec 2020, at 14:35, Robert Skedgell  wrote:
> 
> If 1057 is used on a carriageway
> rather than on a lane or track, it presumably indicates a route,
> although TSRGD 2016 does not elaborate upon this - is there an LTN which
> does?

Not by any means.  1057’s are the ‘go-to’ way to DO SOMETHING for traffic 
engineers.  

- Cyclists getting hit by cars at a junction? Paint some 1057s across it ‘to 
alert drivers that there may be cyclists there” (though of course drivers 
should be conscious that there could be cyclists on any road) 

- can’t work out how to get cyclists around a bus stop or parked car? Paint a 
1057 to indicate road position. 

OSM Wiki Cycle_routes 
 
"Cycle routes or bicycle route are named or numbered or otherwise signed route” 

I would argue that a ‘route’ marked with nothing but 1057 symbols is not useful 
in any way and doesn’t meet that definition 

I have similar issues with London’s Q network - sections of un-numbered 
quietway.  However, these should indicate a certain level of service - ie that 
they meet TfL s quality criteria in terms of traffic volumes etc - but also 
have a point.  Q sections are supposed to be feeders for the strategic cycle 
network of QW and CS routes - ie follow a Q and you should soon get to a main, 
destination signposted, route.  (though again, naming and numbering being 
revised and all routes that meet *latest* quality standards will be C numbered) 
 ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] What is needed for something to be classified as a 'cycle route' (London)

[Simon Still]

See discussion on 
https://www.openstreetmap.org/changeset/95752985#map=18/51.46201/-0.12146=C
 


There appear to be a large number of sections of road in some areas of London 
tagged as ‘cycle route’ that are no more than the occasional 1057 cycle symbol 
painted on the road.

They are not signed, and do not have any route numbering.

Based on the discussion it appears
- most were added by user MacLondon 
- they were the ‘lowest level’ of route designation by some councils at some 
time in the past. Pick some ‘useful routes’ on ‘quiet roads’ and just paint 
some symbols on them for people to follow 

Some of these appear on the last 2015 TfL cycle maps in yellow (routes were 
blue) keyed as ‘other roads recommended by cyclists’ 
 
My opinion is
- these are not followable on the ground 
- they do not meet TfL or borough quality criteria (and thus do not appear on 
any more recent maps) eg - they are not shown in any way on Lambeth councils 
2017 cycle map 
https://www.lambeth.gov.uk/parking-transport-and-streets/cycling/lambeth-cycle-routes-map
 

- they decrease legibility of the map because they create a mass of dense blue 
lines from which it’s hard to pick out genuinely useful routes.
- they probably have a negative impact on routing engines as they are likely 
treated equally to actual signposted routes. 
- in many cases where they do show the most direct route through backstreets 
that is likely to be the busiest with rat running traffic as it’s where google 
and Waze will send drivers. 

Thoughts?


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

Re: [Talk-GB] Tagging bike ramp/ bike path down steps

[Simon Still]

I’d agree with your approach and I’ve raised this before, but haven’t had the 
time to come back to it.  

From a routing perspective it would be useful to be able to tag ACCESSIBILITY  
- ie sections of route that are unsuitable for some users - not related to the 
legality but so that disabled cyclists (unable to dismount), those using 
trailers  or trikes or other non-standard cycles could specify a route that 
avoided sections where they could not ride.

Yes, I think bicycle dismount is correct tagging in this case not because of 
the legality but because of the steps.  If the bridge was had a ramp, or there 
was a subway, and it *could* be ridden across (even if there was a cyclist 
dismount sign) then I think tagging the dismount would be wrong. 



> On 14 Dec 2020, at 17:19, Michael Collinson  wrote:
> 
> FYI, here's the schema I personally use in Sweden, where heavy use is made of 
> ramped staircases, though not thankfully on major cycle routes. My objective 
> is to allow routers to intelligently route for both sport/club/large group 
> riding and happy meandering or commute:
> 
> bicycle=yes only on very shallow low incline steps where it is is safe and 
> practical to cycle an ordinary bike - not common but does happen. Sometimes 
> on shallow slopes a gravelled or informal path to one side also exists.
> 
> where there is a ramp:
> ramp=yes
> bicycle=dismount   (here I am tagging on practicality rather than legalities, 
> Sweden is much more relaxed than UK)
> ramp:stroller=yes   where it is a double ramp, (a forgotten transport 
> demographic)
> 
> on short or low-incline flights of steps where an alternate route would be 
> much longer:
> bicycle=carry (informal/experimental) 
> 
> I also strongly encourage step_count=x as that gives a bicycle router more 
> quantitative input on whether to route or avoid.
> 
> And lastly from unnerving Spanish experience, some sort of hazard tagging at 
> the top of steps where a formal cycle route plunges down a steep flight of 
> steps around a corner!
> 
> Mike
> 
> On 2020-12-14 17:34, Jon Pennycook wrote:
>> resending as I think I sent it from the wrong email address.
>> 
>> However, blue advisory signs about HGVs are tagged as hgv=discouraged, not 
>> as hgv=yes despite there being a legal right of way for HGVs (sometimes, 
>> similar signs are shown for all vehicles, eg on fords or ORPAs) - see 
>> "discouraged" at 
>> https://wiki.openstreetmap.org/wiki/Key:access#Land-based_transportation 
>> 
>> 
>> https://wiki.openstreetmap.org/wiki/Bicycle#Bicycle_Restrictions 
>>  says 
>> bicycle=dismount should be used for 'signs saying "Cyclists dismount"'.
>> 
>> Any sensible router should know that most bicycles ought to dismount for 
>> most steps in the same way they might suggest getting off and walking on a 
>> short footway. Specifying bicycle=yes on steps may override the built-in 
>> default (I think it does for CycleStreets). 
>> 
>> I would suggest not having a bicycle tag at all on steps in preference to 
>> bicycle=yes on steps. Ramp:bicycle=yes/no is a useful tag though.   
>> 
>> Jon

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

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

https://www.gov.uk/guidance/sui-generis-database-rights-after-the-transition-period 
is the UKs governments guidance on this.  On re-reading I agree that the 
withdrawal agreement itself is rather ambiguous, and there is a lot of 
conflicting advice on the matter, see for example 
https://www.google.com/url?sa=t=j==s=web==rja=8=2ahUKEwiL38fux83tAhXNCuwKHYHXAjgQFjABegQIAhAC=https%3A%2F%2Fwww.herbertsmithfreehills.com%2Ffile%2F37041%2Fdownload%3Ftoken%3DOr7GPtMf=AOvVaw0jZK9j_3jP6xJNsnbzaKJ5 
or 
https://www.gevers.eu/en/tb8PacLcwp/brexit--copyright-and-sui-generis-database-right.php 
that states just like the UK governments guidance that the rights will 
continue on post end of the transition period in the EEA.


I suspect clarity on this could only come from the official EU side of 
things, not that it really matters as in any case action is required by 
the OSMF.


Simon

Am 14.12.2020 um 13:34 schrieb Tom Hummel:

Hi Simon,

My understanding is that 58.2 covers the rights of UK based entities, 
with other words it extends the directives article 11 to cover UK 
residents and entities.
From 58 II: “The following persons and undertakings shall be deemed to 
comply” … (basically) people and entities in the UK.


Does “deem to comply” mean, those persons have to comply? It reads as 
if the people mentioned in 58 II are subject to an obligation (the 
duty to obey the rights from 58 I) not the beneficiary. 58 seems to 
talk about EU entities that are, essentially, UK based or active 
within the UK.


Art 58 in general seems to be concerned with continuing EU database 
law within the the UK for EU subjects, not the other way around: 
“holder of a right in relation to a database […] maintain an 
enforceable intellectual property right in the United Kingdom, under 
the law of the United Kingdom”.


Meaning, OSMF, or any EU entity ftm, continues to hold database rights 
within the UK, but not within the EU – only under more general 
provisions. Not even art. 4 TRIPs seems to grant any more rights, 
since lack of any other more favorable agreements among trips members.


I have found an english legal opinion:
===
https://www.womblebonddickinson.com/uk/insights/articles-and-briefings/brexit-and-database-rights


Accordingly, in the event no agreement is reached […] whereby:

· the UK will continue to recognise Database Right of EU (and UK) 
qualifiers so they will not lose rights to which they were entitled 
in the UK on the date of withdrawal


· the EU will cease to recognise Database Right of UK qualifiers in 
respect of databases created *before* the date of withdrawal.

Thanks for your courtesy!

Tom









OpenPGP_signature
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-GB] Tagging bike ramp/ bike path down steps

[Simon Still]

> On 13 Dec 2020, at 19:18, Edward Catmur via Talk-GB 
>  wrote:
> On Sun, 13 Dec 2020, 19:14 David Woolley,  > wrote:
> On 13/12/2020 19:05, Edward Catmur via Talk-GB wrote:
> > Also, the steps should have bicycle=dismount, not =yes. This will allow 
> > people who can't dismount to go around by the road.
> 
> Only if it is illegal to try to cycle up and down the steps.  Otherwise 
> it is the duty of the renderer (router) to infer that this will be 
> necessary because of the steps.
> 
> The sign visible on Mapillary says (white on blue) "Steps ahead cyclists 
> dismount". That seems pretty clear to me. 
> 


White on Blue ‘cyclists dismount’ signs are only advisory.  It may be foolish 
to cycle down (or up) the steps but it’s not illegal.


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

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

My understanding is that 58.2 covers the rights of UK based entities, with 
other words it extends the directives article 11 to cover UK residents and 
entities.

Am 14. Dezember 2020 00:11:25 MEZ schrieb Tom Hummel via legal-talk 
:
>Simon,
>
>sorry for reopening.
>
>> This was the subject of the original message in this thread. The 
>> situation post December 31st 2020 is such that protection for sui 
>> generis databases will remain for database published before that date
>in 
>> the UK till the protection term runs out. In the case of OSM when the
>15 
>
>Thanks, I see you are referring to art. 58 of the withdrawal agreement
>https://eur-lex.europa.eu/legal-content/EN/TXT/?qid=1580206007232=CELEX%3A12019W/TXT%2802%29
>
>The UK government explains this as follows: “Database rights that exist
>in the UK or EEA before 1 January 2021 (whether held by UK or EEA
>persons or businesses) *will continue* to exist in the UK *and EEA* for
>the rest of their duration.”
>
>As far as I understand the article, however, there is protection within
>the UK for European entities. Yet, I can’t find a provision which
>covers the issue vice versa, i.e. an UK entity would loose protection
>within EEA.
>
>I think the accepted term for this is ’reciprocity gap’. I am not sure
>if my understanding of english legal communications is good enough for
>this.
>
>The 15y period was not intended to provide protection against change of
>law. I suppose it’s a protection of investment for a certain amount of
>time. Without EU membership the premises for the law changes. According
>to this, OSMF might loose standing in respect to the directive in
>german courts. (EEA too?)
>
>Thanks
>
>Tom
>
>
>
>___
>legal-talk mailing list
>legal-talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/legal-talk

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

Am 13.12.2020 um 22:43 schrieb Edward Bainton:

Ok, so let me rephrase about 'moving the database'.

I mean moving the domicile of OSMF, as legal owner of the database. 
This is being discussed. (See LWG minutes for September)


Does anyone have a clear idea what that would do for the protection of 
the database as it currently stands? Would it be strengthened versus 
the protection that covers the database at the moment (which is 15 
years of UK database right mimicking EU database right, under the 
Brexit 'withdrawal agreement'. It seems the start-date of those 15 
years is unclear).


Or does the current database not get any greater protection once the 
owner is domiciled in the EU?


IMHO the above questions are unanswerable at the moment, the fuzziness 
with respect to when we consider the database last published is however 
really not related to the BREXIT question, but more to the provisions in 
article 10 which I've already pointed to. Would the OSMF successor be 
required to show that it had made changes as in 10 III to the database 
after it had been founded and domiciled in the EU? There is really just 
no way to know and nobody is chomping at the bit to go to court to find out.


What does moving domicile to the EU do for the protection of the edits 
added to the database after domicile has moved into the EU - are these 
protected under the EU database rights or not? I feel this question 
reduces to,

- are the edits a new database to which EU database rights attach?
- or are they insubstantial modifications of a database that came into 
the EU without EU database rights attached, and therefore the new 
edits are not covered by EU database right?


The database as a whole is protected, not the edits (outside of 
potentially collectively being a database themself). Making 
insubstantial changes to the database doesn't change protection of its 
contents or newly added or changed data, making substantial changes will 
create a new database.




Are these questions clear?

(Not that OSMF can strictly *move* domicile: it will have to register 
a subsidiary legal person in an EU country, move its intellectual 
property into the subsidary, then possibly admit all current OSMF 
members as members of the subsidary and close the parent (ie, close 
the current London-registered OSMF. Or an equivalent process.)


If it was easy it would have been done a long time ago. The additional 
complication is that I expect (who knows what the OSMF board is 
thinking) that we would want to create a proper membership based 
organisation which, using a broad brush here, can't be subsidiaries of 
other legal entities.


Simon



On Sun, 13 Dec 2020 at 20:52, Simon Poole <mailto:si...@poole.ch>> wrote:



Am 13.12.2020 um 20:12 schrieb Tom Hummel via legal-talk:
> Hi all,
>
> Am Sonntag, 13. Dezember 2020, 15:58:48 CET schrieb Simon Poole:
>> The relevant bit of the directive is in article 11. As you can
see the
>> rights are dependent on being domiciled in the EU, not on the
physical
>> location of the "database". I would need to check up on the UK
> Do the legal contributors have formed an opinion towards this,
already?
>
> Seeing the Foundation being situated in the UK, and the absence
of any agreement acc. to art. 11 III, it looks like the foundation
is loosing its entitlement acc. to art. 11 II of the directive.

This was the subject of the original message in this thread. The
situation post December 31st 2020 is such that protection for sui
generis databases will remain for database published before that
date in
the UK till the protection term runs out. In the case of OSM when
the 15
years start is naturally a bit fuzzy, but at least the reworking
of the
database in 2012 for the licence change was clearly a substantial
change
that required a significant investment by the OSMF, so it is
reasonable
to assume that protection will remain at least till September 2026
(IMHO
there are more than enough arguments for December 2034, but I suspect
that will be moot by 26).

Simon

>
> German courts adhere to the „modified seat of management rule“
since 2002 (BGH NJW 2002, 3539), meaning some capacity to sue and
be sued. OTOTH liability for associates is personal and unrestricted.
>
> For Germany, it looks like there is some entitlement on behalf
of FOSSGIS. The governing agreement (OpenStreetMap Foundation
Local Chapters Agreement) does not grant any derivative rights
without additional agreement, § 7.1 Conduct.
>
> Am I missing something?
>
> Tom
>
>
>
> ___
> legal-talk mailing list
> legal-talk@openstreetmap.org <mailto:legal-talk@openstreetmap.org>
> ht

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

Am 13.12.2020 um 20:12 schrieb Tom Hummel via legal-talk:

Hi all,

Am Sonntag, 13. Dezember 2020, 15:58:48 CET schrieb Simon Poole:

The relevant bit of the directive is in article 11. As you can see the
rights are dependent on being domiciled in the EU, not on the physical
location of the "database". I would need to check up on the UK

Do the legal contributors have formed an opinion towards this, already?

Seeing the Foundation being situated in the UK, and the absence of any 
agreement acc. to art. 11 III, it looks like the foundation is loosing its 
entitlement acc. to art. 11 II of the directive.


This was the subject of the original message in this thread. The 
situation post December 31st 2020 is such that protection for sui 
generis databases will remain for database published before that date in 
the UK till the protection term runs out. In the case of OSM when the 15 
years start is naturally a bit fuzzy, but at least the reworking of the 
database in 2012 for the licence change was clearly a substantial change 
that required a significant investment by the OSMF, so it is reasonable 
to assume that protection will remain at least till September 2026 (IMHO 
there are more than enough arguments for December 2034, but I suspect 
that will be moot by 26).


Simon



German courts adhere to the „modified seat of management rule“ since 2002 (BGH 
NJW 2002, 3539), meaning some capacity to sue and be sued. OTOTH liability for 
associates is personal and unrestricted.

For Germany, it looks like there is some entitlement on behalf of FOSSGIS. The 
governing agreement (OpenStreetMap Foundation Local Chapters Agreement) does 
not grant any derivative rights without additional agreement, § 7.1 Conduct.

Am I missing something?

Tom



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




OpenPGP_signature
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

The relevant bit of the directive is in article 11. As you can see the 
rights are dependent on being domiciled in the EU, not on the physical 
location of the "database". I would need to check up on the UK 
equivalent, but it likely requires the same. Outside of the UK and EU 
(possibly including Russia), we rely on conventional copyright for 
creative works* and contract law.


Simon

* yes, I'm fully aware of the problematic bit here.

Am 13.12.2020 um 10:21 schrieb Edward Bainton:
Thank you for the link, now read. All you say on substantial changes 
makes sense.


So if we move the database into the EU, are we confident it would be 
all be protected under those terms? Does the hiatus from 1 Jan 2021 
cause any difficulties? I'm reading the bit that says protection runs 
from the date of completion of the database - which is either already 
done, or never to be achieved. Either way I'm struggling to be sure 
that a database imported into the EU (perhaps considered complete on 
the day of import?) would have the protection.


Or do we need two databases - the UK-based one that is protected under 
the legacy agreement (until the UK Parliament decides otherwise, I 
suppose), and the new EU one, and the servers work off them in tandem?


On Thu, 10 Dec 2020 at 23:18, Simon Poole <mailto:si...@poole.ch>> wrote:


To answer the questions caveat there is no relevant court
decisions that I know of, so this is all likely untested:
insubstantial changes to a database do not create a new one, but
substantial changes do. Where the line is drawn, or better where
the OSMF draws the line, is currently open. See article 10
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A31996L0009
<https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A31996L0009>

Simon

Am 10.12.2020 um 22:11 schrieb Edward Bainton:

A pleasure meeting you all at LWG this evening.

I saw Brexit in the minutes for September
"At the end of year we won't be losing database rights immediately."

General guidance I've seen appears to say:
- database rights accrued before 2021-01-01 persist (as I've seen
discussed in minutes)
- database rights accrued from 2021-01-01 will exist only in the
UK (if at all: I can't see any enabling legislation after a quick
look, and this may have gone into the Govt's "later" tray - so
copyright may be the only protection).

The last point suggests to me that any edits made after
2020-01-01 will have less protection than so far has been the case.

Is that your understanding? Or is the database as a whole
protected because the architecture has been built, and subsequent
edits are protected modifications of an already-protected creation?

___
legal-talk mailing list
legal-talk@openstreetmap.org  <mailto:legal-talk@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/legal-talk  
<https://lists.openstreetmap.org/listinfo/legal-talk>

___
legal-talk mailing list
legal-talk@openstreetmap.org <mailto:legal-talk@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/legal-talk
<https://lists.openstreetmap.org/listinfo/legal-talk>


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


OpenPGP_signature
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

To answer the questions caveat there is no relevant court decisions that 
I know of, so this is all likely untested: insubstantial changes to a 
database do not create a new one, but substantial changes do. Where the 
line is drawn, or better where the OSMF draws the line, is currently 
open. See article 10 
https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex%3A31996L0009


Simon

Am 10.12.2020 um 22:11 schrieb Edward Bainton:

A pleasure meeting you all at LWG this evening.

I saw Brexit in the minutes for September
"At the end of year we won't be losing database rights immediately."

General guidance I've seen appears to say:
- database rights accrued before 2021-01-01 persist (as I've seen 
discussed in minutes)
- database rights accrued from 2021-01-01 will exist only in the UK 
(if at all: I can't see any enabling legislation after a quick look, 
and this may have gone into the Govt's "later" tray - so copyright may 
be the only protection).


The last point suggests to me that any edits made after 2020-01-01 
will have less protection than so far has been the case.


Is that your understanding? Or is the database as a whole protected 
because the architecture has been built, and subsequent edits are 
protected modifications of an already-protected creation?


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


OpenPGP_signature
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] Brexit & EU database rights

[Simon Poole]

Legal talk is not the LWG list if that isn't clear, that is 
le...@osmfoundation.org


Simon

Am 10.12.2020 um 22:11 schrieb Edward Bainton:

A pleasure meeting you all at LWG this evening.

I saw Brexit in the minutes for September
"At the end of year we won't be losing database rights immediately."

General guidance I've seen appears to say:
- database rights accrued before 2021-01-01 persist (as I've seen 
discussed in minutes)
- database rights accrued from 2021-01-01 will exist only in the UK 
(if at all: I can't see any enabling legislation after a quick look, 
and this may have gone into the Govt's "later" tray - so copyright may 
be the only protection).


The last point suggests to me that any edits made after 2020-01-01 
will have less protection than so far has been the case.


Is that your understanding? Or is the database as a whole protected 
because the architecture has been built, and subsequent edits are 
protected modifications of an already-protected creation?


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


OpenPGP_signature
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [Talk-GB] Tagging of shared use paths

[Simon Still]

> On 10 Dec 2020, at 14:13, John Aldridge  wrote:
> 
> On 12/10/2020 12:41 PM, Ken Kilfedder wrote:
>> As a break from 'tagging for the renderer', I'd like to see rendering for 
>> the tags.
> 
> A long standing grump of mine!

And mine.  I think the CycleMap render has a lot of issues with clarity.

(I’ve just gone in and removed a load of sections of road in Lambeth tagged as 
‘cycle route’ which have no route markings on the ground, do not form part of 
the current generation of C or Q routes, nor a numbered London Cycle Network 
Route (and were not on the LCN maps I have).  Also considering removing some 
other sections which may have correctly been marked as un-numbered LCN but 
which are no longer visible on the street in any way - though one does now run 
through a new Low Traffic Neighbourhood so *would* be a useful route if 
signed….) 


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

Re: [OSM-talk] Please review "Community attribution advice” wiki page

[Simon Poole]

Am 08.12.2020 um 18:36 schrieb Rory McCann:

Yes, fundamentally, you're 100% correct. The ODbL licence is the thing that 
matters when it comes to what's legally required. And that says nothing about 
“device independent pixels” or “javascript popup clicks”, it only refers to the 
mental state of someone.

The Charter of Fundamental Rights of the European Union on data protection 
(Art. 8) is only about 80 words long  (DE 73, EN 82, GA 101), but the GDPR that 
implements it is 55,000 words long. I view the ODbL as like our “constitution” 
for what you can do with the data.


This analogy is clearly wrong. If anything at all, the contributor terms 
would be the constitution, the ODbL is just one of many possible ways 
the constitutional requirements could be implemented, and, if you so 
want, the guidance published by the OSMF are the ordinances that cover 
details and fix issues that the law makers didn't foresee or which are 
simply mistakes.



It will be short, but for practical real word answers you need laws & court cases 
which expand on it. One can always challenge a law for violating a constituation limit 
or requirement, and it should be the same with the ODbL & the OSMF's Attribution 
Guidelines.


But outside of the realm of not really fitting analogies, there is a 
reason why in many modern states the constitution and laws evolve, 
because the world and the circumstances in which the rules are applied 
change over time, and wise governing bodies adapt their rule book to 
changing reality. The ODbL was formulated as a generic database licence, 
independent of the subject matter and without the more than a decade 
experience with actual use cases that we have now, many of which were 
not considered at the time.


We can take a pragmatic approach to this, which was the practice over 
the last 10 years and undoubtably one of the reasons OSM has become such 
a thriving success, we can formally revise the law (one of the LWG 
proposals for getting out of the quagmire in a democratic fashion that 
wasn't responded to), or we can tie ourselves to yesteryears fights with 
overly literal reading of the rules without taking change in to account.


Naturally people tend to only be literal when it serves their specific 
political aims and allow them to maximize hubris and strife, and not 
when not. Maybe I should just be literal about the contributor terms and 
bring OSM to a screeching halt for effect.


Simon



So I think there's a lot of benefit in writing out, in my more detail, how you 
can follow §4.3, rather than speaking in generalities.

On Tue, 8 Dec 2020, at 00:08, Christoph Hormann wrote:



Rory McCann  hat am 07.12.2020 22:57 geschrieben:

But I think this attribution is too vague. It's advice seems to restate the 
relevant section from the ODbL. There are many examples of poor attribution 
where someone could argue that they meet this standard.

As i have already explained to you in

http://blog.imagico.de/the-osmf-changes-during-the-past-year-and-what-they-mean-for-the-coming-years-part-2/#comment-141145

the opposite is the case - the advise as formulated precisely explains
the criterion for valid attribution.

Attribution has the purpose to be perceived by humans.  To determine if
a certain form of attribution is acceptable you have to look at the
effect it has on human perception while interacting with the produced
work.

It is understandable that to people with a primarily technical
background this very concept appears uncomfortable and hard to grasp
and their reflex is to substitute this with something purely technical
where you can essentially program a test to verify if the attribution
is OK independent of the human user.  That cannot work.

--
Christoph Hormann
http://www.imagico.de/

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


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




OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Bridleway across field

[Simon Still]

> On 8 Dec 2020, at 14:20, SK53  > wrote:
> Personally I do not generally map PRoWs which have no on-the-ground traces 
> (particularly after my experience 
> 
>  in Carmathenshire in 2011), although I do allow a wide latitude of sources 
> to identify traces of PRoWs (overgrown stiles, rotting footpath signs, etc.) 
> when it might be useful to do so. Keeping such things invisible from the 
> regular user of OSM has advantages in that a non-existent path blighting a 
> walk is less likely. Of course if you report it as obstructed to the HA and 
> get a suitable reply then you have substantial personal knowledge about the 
> PRoW.
> Jerry


If there is a RoW surely it should be marked - these are *rights of way* 
whether or not they have been kept in good order, blocked or are rarely used.  
NOT including it on a map surely just means it less likely that it will be used 
in future.  

I’d actually say *more* of an issue with OSM is paths that are marked that ARE 
NOT a legal right of way.  Around Peaslake in the Surrey Hills there are 
various ‘mountain bike trails’ shown on OSM that are not rights of way and 
which the landowners say should not be ridden.  

> On 8 Dec 2020, at 14:10, Dave F via Talk-GB  > wrote:
> 
> IMO, this is bad mapping.
> Just because one person concludes it isn't used by staring at photograph 
> taken thousands of feet in the air doesn't mean it isn't.
> Accessibility is variable & subjective. What might be a deterrent to a 
> wheelchair user, could be considered easy by a high jumper.
> Even if it is found to be inaccessible after an on ground survey it doesn't 
> mean it's been declared disused.

Indeed - I know of bridleway across fields and bogs in the Lake District where 
the ground is too wet to retain any signs of use distinct from cattle hoof 
prints. Signposts rot, signs fall down or get obscured by undergrowth. 

There are paths I walk and trails I ride that we go out and clear of nettles 
and bracken to keep them usable in summer. ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Bridleway across field

[Simon Still]

Should be recorded as per the definitive map - lots like that across welsh 
hilltops etc.  I’ve used a gps to follow them in the fog before 

> On 8 Dec 2020, at 09:36, Mark Lee via Talk-GB  
> wrote:
> 
> Hello. I've just added a missing public bridleway 
> (https://www.openstreetmap.org/way/882278479 
> ) which is detailed on the 
> WIltshire Definitive Map. It runs across a field and doesn't appear to have 
> been in use recently, I couldn't see it on the ground in person and I can't 
> see it in any of the aerial images. It runs fairly close to a concrete track, 
> however, there is a locked gate across that track (which I've also just now 
> added). What's the OSM policy on legal ROWs that have no physical evidence 
> and no rerouting such as along a field boundary such as I've seen in other 
> cases on OSM.
> 
> Thanks,
> 
> Mark
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-de] Flyer "Ihre Öffnungszeiten wurden zu OSM hinzugefügt"

[Simon Poole]

https://osmybiz.osm.ch/#/18/47.18682/8.39773 ist eigentlich genau dazu 
gedacht Betriebe ihren eigenen Eintrag machen zu lassen, und den auch zu 
pflegen.


Am 15.11.2020 um 08:39 schrieb Markus via Talk-de:

Am 14.11.2020 um 22:15 schrieb Frederik Ramm:


Als OSM haben wir zwar nur die besten Absichten

:-)

Gibt es denn eine Öffnungzeiten-Web-Anwendung?

Daten machen nur Sinn, wenn sie simpel nutzbar sind.
Und wenn sie aktuell sind.

Wenn sie dann "besser" sind als diejenigen anderer Anbieter
(vollständiger, genauer, aktueller)
und dies sowohl bei den Kunden, als auch bei den Ladenbesitzern ankommt,
dann könnte sowas funktionieren.

Bei den Strassen und Wegen haben wir das ja auch geschafft :-) *

Gruss, Markus

* wie ist da derzeit eigentlich der Vergleich mit dem "Wettbewerb"?


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


OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-legal-talk] Data Portal License CC0 1.0 and OpenStreetMap

[Simon Poole]

Everything relevant has been documented here 
https://wiki.osmfoundation.org/wiki/Licence/Licence_Compatibility for a long 
time.

Am 6. November 2020 17:47:16 MEZ schrieb "Pierre Béland via legal-talk" 
:
> 2020-10-06 , Mateusz Konieczny wrote via legal-talk :  
>> For example Wikidata is CC0 but mostly copyright incompatible with
>OSM
>> and unusable for imports in general.
>If I understand correctly, there is quite a difference in solididy of
>license  from groups like Wikidata who import data from various sources
>vs a government agencies that produce their own data.
>
> 
>Pierre 
> 
>
>Le vendredi 6 novembre 2020 11 h 08 min 52 s UTC−5, Mateusz Konieczny
>via legal-talk  a écrit :  
> 
> See https://wiki.openstreetmap.org/wiki/Import/ODbL_Compatibility
>
>"License terms are compatible, but the licenser does not guarantee for
>it. 
>4c of the license explicitly states: "Affirmer disclaims responsibility
>for 
>clearing rights of other persons that may apply to the Work or any use
>thereof, 
>including without limitation any person's Copyright and Related Rights
>in the Work. 
>Further, Affirmer disclaims responsibility for obtaining any necessary
>consents, 
>permissions or other rights required for any use of the Work.""
>
>For example Wikidata is CC0 but mostly copyright incompatible with OSM
>and unusable for imports in general.
>
>Nov 6, 2020, 16:48 by legal-talk@openstreetmap.org:
>
>Government of Quebec has added the licence CC0 1.0 to his
>https://www.donneesquebec.ca Data portal  for import of datasets and
>never returned requests to add specific authorisation for OSM. 
>
>Looking at the history of discussions, it is not clear for me if the
>CC0 Public license is compatible with OSM. 
>
>Then my question : Does  CC0 1.0 license make the data compatible with
>OpenStreeMap Odbl llicense ?  
>
>If so, we will have access to datasets of high quality such as route,
>hydrography, address.
>
>License in french
>https://www.donneesquebec.ca/fr/licence/
>
>Deepl translation 
>---
>In order to promote collaboration, exchange and sharing, as well as the
>use of open data by all, the Government of Quebec and several
>municipalities have adopted a common licence, Creative Commons 4.0
>(CC), which comes in six variants.
>
>This licence is recognized as one of the least restrictive in terms of
>the rights to use open data, while protecting copyright.
>
>The universal Creative Commons 1.0 licence (CC0 1.0) can also be used,
>in particular to encourage the integration of data into a larger set of
>open and linked data, in which the origin of each piece of data can
>sometimes be more complex to recognise. 
>---
>
> 
>Pierre 
>
> ___
>legal-talk mailing list
>legal-talk@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/legal-talk
>  

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-talk] id Editor auto-converts split polygons into MP relation

[Simon Poole]

Am 30.10.2020 um 16:33 schrieb Dave F:



But anyway... Point slit stands: Why did iD take this authoritarian 
position.
Already pointed this out n-times now: because it synthesizes an area 
object type.



As has been noted other, editors don't make this assumption.


Other editors don't try to synthesize an area type.



A split polygon with only an outer MP is not an "area".


It is, you are really totally mistaken on this. Particularly if you are 
reusing ways that are parts of other MPs it is quite common to have an 
MP with a sole outer ring composed of multiple ways (aka a "split 
polygon"). That it is typically unnecessary in the case of a building 
doesn't make it invalid.


Simon





The correct solution to split polygons with tags on the ways is to 
rejoin those ways, not create a MP.



As I pointed out, the question is -when- to rejoin those ways.


As I pointed out, that's for the contributor to decide, not the editor.


 A MP with only one* outer is invalid.


Nope.


There's a clue in the name 'MultiPolygon' there has to be more than one.
Splitting into two serves no purpose, adds no quality. Entropy isn't 
beneficial for the OSM database.


Incomplete MP relations are not beneficial to OSM quality.

DaveF


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] id Editor auto-converts split polygons into MP relation

[Simon Poole]

Am 29.10.2020 um 00:17 schrieb Dave F:
iD editor attracts a hell of a lot of "WTFs", doesn't it? I mean, even 
its most ardent fan must occasionally raise a Roger Moore eyebrow.


bhuousel has taken the presumptive decision that the contributor's 
desired end result will always be a MP relation. This is wrong, plain 
& simple (& quite arrogant). iD editor should provide tools to allow 
contributors to make their own decisions as easily as possible & not 
take them on their behalf.


I'm not sure why you believe Bryan has or had anything to do with that 
specific design decision, but he didn't, that happened a substantial 
time before he had any formal involvement.



As has been noted other, editors don't make this assumption.


Other editors don't try to synthesize an area type.



The correct solution to split polygons with tags on the ways is to 
rejoin those ways, not create a MP.



As I pointed out, the question is -when- to rejoin those ways.

 A MP with only one* outer is invalid.


Nope.

* splitting it still means there's only one.

Relations were created to allow mapping of entities, not possible with 
just ways. They aren't meant to be the default for all objects.



See above.

Simon



DaveF

On 27/10/2020 08:11, Simon Poole wrote:
Its done that essentially since day one. As Bryce points out doing so 
keeps the object a valid "area" (and iD makes a valiant effort to 
stop you from breaking that).


It is also one of my favourite examples in talks why trying to keep 
things simple for the user is very difficult and some times 
counterproductive.


Lots of people have had the wtf moment when they come along a 
multi-polgon consisting of just one ring built from two ways. The 
problem is that once the user has split the polygon, there is no 
obvious point in time were you can be sure that the user is finished 
with it and you could simplify, particularly when you are trying to 
get the user to save often and early. So the simplification for the 
iD user comes at the expense of wtf's of everybody else.


Simon

Am 27.10.2020 um 02:05 schrieb Dave F via talk:

Hi

I don't use iD editor much, but I've just discovered it 
auto-converts closed polygons which are split (Shortcut Key = X) 
into MP relations.


I'm struggling to comprehend a logical reason for this. Is there 
one? If there's been a previous discussion which I've missed please 
post a link.


There's a couple of threads on iD's github issues, bhousel closed 
them with "wontfix - I Saw A Thing I Didn't Like (but is valid in OSM).


It may be valid, but is it desirable or helpful? I split closed 
ways, in P2, for various reasons without wanting them to be 
converted. How many newbies would even know what a MP relation is?


Having them as as split tagged ways is just as "valid". More so, 
considering splitting long ways is desirable.


DaveF




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


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




OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] id Editor auto-converts split polygons into MP relation

[Simon Poole]

Its done that essentially since day one. As Bryce points out doing so 
keeps the object a valid "area" (and iD makes a valiant effort to stop 
you from breaking that).


It is also one of my favourite examples in talks why trying to keep 
things simple for the user is very difficult and some times 
counterproductive.


Lots of people have had the wtf moment when they come along a 
multi-polgon consisting of just one ring built from two ways. The 
problem is that once the user has split the polygon, there is no obvious 
point in time were you can be sure that the user is finished with it and 
you could simplify, particularly when you are trying to get the user to 
save often and early. So the simplification for the iD user comes at the 
expense of wtf's of everybody else.


Simon

Am 27.10.2020 um 02:05 schrieb Dave F via talk:

Hi

I don't use iD editor much, but I've just discovered it auto-converts 
closed polygons which are split (Shortcut Key = X) into MP relations.


I'm struggling to comprehend a logical reason for this. Is there one? 
If there's been a previous discussion which I've missed please post a 
link.


There's a couple of threads on iD's github issues, bhousel closed them 
with "wontfix - I Saw A Thing I Didn't Like (but is valid in OSM).


It may be valid, but is it desirable or helpful? I split closed ways, 
in P2, for various reasons without wanting them to be converted. How 
many newbies would even know what a MP relation is?


Having them as as split tagged ways is just as "valid". More so, 
considering splitting long ways is desirable.


DaveF




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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] User deleting many roads in Brazil

[Simon Poole]

You need to take this up with the DWG (d...@osmfoundation.org) once 
direct contact with the mapper in question has failed. Posting to this 
and the tagging list is not going to achieve anything except that you 
will receive pointers to the DWG.


Simon

Am 24.10.2020 um 17:54 schrieb Erick de Oliveira Leal:
Good morning, a user in Brasil is deleting many roads, I think all of 
its changeset need to be reverted.

Examples of bad changesets:
https://www.openstreetmap.org/changeset/92345676 
<https://www.openstreetmap.org/changeset/92345676>
https://www.openstreetmap.org/changeset/ 
<https://www.openstreetmap.org/changeset/92345676>92703956 
<http://overpass-api.de/achavi/?changeset=92703956>
https://www.openstreetmap.org/changeset/ 
<https://www.openstreetmap.org/changeset/92345676>92610958 
<http://overpass-api.de/achavi/?changeset=92610958>


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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-legal-talk] Is listing at Contributors page qualifying as waiver for CC BY 4.0?

[Simon Poole]

Just as a note, prior to the review of CC BY 4.0 compatibility by the 
LWG (and CC fwiw), we were very clear that 4.0 licensed material should 
-not- be imported, the importers knew this and were ignoring it at their 
own risk.


Simon

Am 23.10.2020 um 10:43 schrieb Mateusz Konieczny via legal-talk:

Is

"it is good enough for us to be named as the data owner here:
http://wiki.openstreetmap.org/wiki/Contributors#Kartverket_.28Norwegian_Mapping_Authority.29 
<http://wiki.openstreetmap.org/wiki/Contributors#Kartverket_.28Norwegian_Mapping_Authority.29> 
"


(see http://lists.nuug.no/pipermail/kart/2014-August/004831.html 
<http://lists.nuug.no/pipermail/kart/2014-August/004831.html> for the 
original text)

sufficient to solve problems of CC BY 4.0?

As I understand CC BY 4.0 requires waiver for DRM related reasons, and 
that it would not

be sufficient.

For context see 
https://wiki.openstreetmap.org/wiki/Talk:Import/Catalogue/Road_import_(Norway) 
<https://wiki.openstreetmap.org/wiki/Talk:Import/Catalogue/Road_import_(Norway)>


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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [talk-au] Microsoft Australian building footprints

[Simon Poole]

Just as a comment: there is nothing so time consuming as fixing badly 
mapped buildings (essentially drawing them from scratch is nearly always 
faster), I would only import building outlines that are at a quality 
level that you would not want to change them except if the building 
itself has been modified.


Simon

PS: lives in an area which had 10s of 1000s of buildings mapped already 
in 2009 from mushy misaligned yahoo imagery.


Am 20.10.2020 um 11:12 schrieb Andrew Harvey:
On Tue, 20 Oct 2020 at 18:39, Daniel O'Connor 
mailto:daniel.ocon...@gmail.com>> wrote:


and after a bit of digging came across this ODBL data:
https://github.com/microsoft/AustraliaBuildingFootprints
<https://github.com/microsoft/AustraliaBuildingFootprints>

As fun as hand tracing data is; I'd be pretty keen to swap to
small scale imports of this, suburb by suburb in my area.

https://wiki.openstreetmap.org/wiki/Microsoft_Building_Footprint_Data
<https://wiki.openstreetmap.org/wiki/Microsoft_Building_Footprint_Data>
details the data in more general terms, and links to a few import
proposals.

Anyone feel like exploring and validating the quality of the data
in their areas?


Thanks for posting, I didn't realise they had released something for 
Australia. It says "The data will also be made available in Facebook 
RapiD." but I couldn't see buildings come through only roads. RapiD 
would probably be one of the easier options for bringing into OSM.


Areas which are already well mapped building wise best to leave what's 
there, and area where people are actively mapping with local knowledge 
and survey's best to leave what's there, but for general areas with 
almost no buildings mapped, I think it makes sense to manually import 
this to provide a good base level of coverage.


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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk] Doocracy | Re: Idea for improving mapping system

[Simon Poole]

Am 18.10.2020 um 16:49 schrieb Colin Smale:


On 2020-10-18 15:04, Simon Poole wrote:



Am 18.10.2020 um 11:07 schrieb Rory McCann:

Like mnany things in OSM, the reason it hasn't been done is because no-one has actually done it 
yet. It looks like other people find your idea of "levels" and "badges" 
interesting, so you should try attempt it yourself.


Like many things in OSM, the reason that it isn't being done, is 
because it has been tried and has failed. It looks like that other 
people don't find the idea of "levels" and "badges" interesting, so 
you shouldn't attempt it again.
...unless either the proposal, or the circumstances, have changed in 
some significant way, or unless a substantial period of time has 
passed. Never say never.


Agreed, but the point was that there is 16 years of OSM-history in which 
most stuff from the 5-minute (community) manager has been tried in one 
way or the other, and there are reasons, which might need to be 
re-evaluated if things have significantly changed, why things are not 
being done, -not- that they simply hasn't been tried.




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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Doocracy | Re: Idea for improving mapping system

[Simon Poole]

Am 18.10.2020 um 11:07 schrieb Rory McCann:

Like mnany things in OSM, the reason it hasn't been done is because no-one has actually done it 
yet. It looks like other people find your idea of "levels" and "badges" 
interesting, so you should try attempt it yourself.


Like many things in OSM, the reason that it isn't being done, is because 
it has been tried and has failed. It looks like that other people don't 
find the idea of "levels" and "badges" interesting, so you shouldn't 
attempt it again.




On Sun, 18 Oct 2020, at 4:31 AM, TheAdventurer64 wrote:

Hello everyone,

A user and I were talking about implementing a system for better
mapping, as described here:
https://osmus.slack.com/archives/C029HV951/p1602968516431900
This addition would have many benefits, including:
* More mapping. We have tons of new mappers each day, as well as a
great editor for them. However, many of these new mappers leave after
just a few edits. Examples:
https://www.openstreetmap.org/user/lukastheg03
https://www.openstreetmap.org/user/Th3Roomi3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] vine row tagging

[Simon Slater]

On Thursday, 15 October 2020 6:23:36 PM AEDT John Bryant wrote:
> This is part of a viticulture community-driven project to build consensus
> around use & sharing of data, and part of the discussion is around data
> ownership and openness. The project has the Australian Farm Data Code [1]
> as one of its guiding principles, so it's definitely on the radar. I'm not
> running the project myself, but helping to answer some of the questions
> about open geospatial (hence this query!).

For this level of detail, would a GIS be more useful, pulling roads etc. from 
OSM?  Then other things useful to the viticulturist, such as soil type, slope, 
aspect, rainfall, irrigation and drainage (natural or artificial) even 
cadastre for individual blocks, could be layered in as needed and is as much, 
or as little, detail as required.

GRASS or QGIS are readily available as FOSS if that is a requirement.

-- 
Regards
Simon Slater

Registered Linux User #463789 @ http://linuxcounter.net

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

Re: [OSM-talk] Face and license blurring (GDPR territories)

[Simon Poole]

Am 07.10.2020 um 10:25 schrieb Christian Quest:


We have tested blurring using image segmentation which allows to blur 
full parts of pictures like people and cars, not only faces and 
license plates.



Here is the result: https://takeitout.cquest.org/photo/cquest/blurred/


The code used is on github: https://github.com/tyndare/blur-persons/


We did some tests using TPU to speedup the process.


That looks (IMHO) very good and addresses some of the concerns I pointed 
out, naturally not perfect, but it is far better than simply blurring 
faces and number plates. As a tendency I would remove any colour of the 
blurred object too in particular to make cars even less identifiable.


Simon

PS: why handbags are important for OSM is a bit of a mystery though :-)



OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Face and license blurring (GDPR territories)

[Simon Poole]

Am 07.10.2020 um 01:13 schrieb Niels Elgaard Larsen:

...
You will probably have to let users add and remove blurs.
That is what Mapillary do.

They do not, they stopped providing that facility literally years ago, 
and they've gone as far as no longer storing unblurred images even for a 
limited time now.


The other important point to understand is that there is no reason to 
believe that face and licence plate blurring is sufficient to avoid 
trouble in countries with strict data protection regulation as long as 
people and vehicles can be identified and behaviour associated with 
individuals can be deduced from the images (with other words blurring 
would have to be far more complete to be on the safe side). There is 
simply no case law, because there have been, afaik, no cases that have 
actually gone to court.


tl;dr version you need to make your own risk assessment (and ask your 
own counsel).


Simon



OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-fr] Tracé GPX lignes trains Intercités ?

[Gaël Simon]

Bonsoir, peut-être filtrer sur le tag usage ? Usage = main ?

Gaël

Le 29 sept. 2020 à 19:25, Gilles  a écrit :


J'ai déjà essayé via une relation, mais c'est pas terrible : par exemple, on 
récupère toutes les ways qui représentent des voies dans les gares (et dans une 
grosse gare, ça fait un paquet de spaghettis).

C'est pour ça que je demandais s'il existait déjà les tracés sous forme de GPX 
tout propre.

On 29/09/2020 16:05, GarenKreiz wrote:
> Y quelque chose qui m'échappe. Les voies utilisées par les Intercités sont a 
> priori dans OSM, pourquoi ne pas les utiliser? Un pb de licence?
> 
> 
> 
> On Tue, 29 Sep 2020 at 15:52, Gilles  wrote:
>> On 29/09/2020 15:10, deuzeffe wrote:
>>> Pour ce qui est de la question initiale : 
>>> https://transport.data.gouv.fr/datasets/horaires-des-lignes-intercites-sncf/
>>>  + https://nlehuby.5apps.com/de-gtfs-a-osm.html ça le fait pas ?
>> Non, parce que c'est la liste des gares alors que j'ai besoin des parcours.
>> 
>> Pas grave, je vais dessiner les parcours à la main, même si ça rend moins 
>> bien que le tracé réel.
>> 
>> Merci.
>> 
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Asso: Prochain CA mardi 08 septembre - Compte rendu

[Gaël Simon]

Bravo pour ces avancées. 

Gaël

Le 15 sept. 2020 à 15:27, Frédéric Rodrigo  a écrit :

Bonjour,

Le compte rendu du dernier CA de l'association est disponible sur le Wiki :

https://wiki.openstreetmap.org/wiki/France/OSM-FR/CA_2020-09-08


Prochain CA prévu le 6 octobre et comme toujours ouvert à tout le monde.


Frédéric.


> Le 31/08/2020 à 20:24, Frédéric Rodrigo a écrit :
> Bonjour,
> 
> Selon le calendrier pré-établit le prochain CA devait avoir lieu demain. Lors 
> du CA avorté d’août, il a été décidé de reporter celui de septembre à mardi 
> prochain (8 septembre) à 21h.
> 
> Vous pouvez compléter les sujets à l'ordre du jour sur le pad :
> 
> https://annuel.framapad.org/p/hjkllkjbkjlk
> 
> Le CA est ouvert à tout le monde.
> 
> Frédéric.
> 
> 


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

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

Re: [Talk-GB] Brexit and OpenStreetMap

[Simon Poole]

There are at least three areas which need looking at when considering 
moving the OSMF, only two of them are strictly BREXIT related:


- Sui generis database protection (this is one of the underlying 
principles our licence relies on).


- Data protection compliance (this is currently not an issue, but could 
become one).


- Corporate structure and the ease of enabling tax deductible donations 
to the OSMF (while there is a bit of an BREXIT angle to this, it is 
mainly a question of the lack of options for this in the UK that is an 
issue).


As already pointed out to Martin you can find numerous discussions and 
material on the subject here


https://wiki.osmfoundation.org/w/index.php?search=brexit=Special%3ASearch=default=1

Simon


Am 14.09.2020 um 14:51 schrieb Tony Shield:

Saw this subject in WeeklyOSM 529

 https://www.weeklyosm.eu/en/archives/13734/
Has someone analyzed the effects of Brexit on OpenStreetMap and which 
responses could be undertaken to fix potential problems?


For example have you looked at the consequences, cost and effort of 
moving the OpenStreetMap-Foundation to a EU-country and on the 
problems of staying in the UK (e.g. database protection for new 
databases by UK citizens will not be given in the EU).


Could we keep the servers in the UK but provide services under a 
different jurisdiction (because the foundation seat is moved)?


Is it possible to move the foundation, and what are the requirements? 
Maybe we should ask the membership what they would think about such a 
move? Has the board voiced its standpoint?



If something has been written about the specific situation of 
OpenStreetMap I would be interested in a link. I would also be 
interested in learning about your thoughts wrt brexit and 
OpenStreetMap. Publicly it seems we have mostly avoided any related 
considerations, until last year many had been hoping that someone 
would still stop it, but now it will become effective in only 4 months.


Cheers Martin

I'm a OSM GB member not fully understanding the structure of OSM but 
here goes -


GB is soon to be like any non-EU country. Brexit occurred 31 January 
last and Withdrawal Agreement ends 31 December 2020.


The question becomes is the OSMF so dependent on EU laws that it 
cannot operate outside the EU. OSM is a global effort and operates in 
many places where laws are substantially different to those of GB and 
EU. Laws are also different within the EU.


By thinking of moving OSMF from UK to EU because of Brexit are you 
saying that OSMF may never be able to function outside the EU - what 
about Switzerland where many international organisations are based, or 
United States. These are respected countries which should be 
considered if relocation is deemed necessary.


With respect to data privacy what is to stop OSMF mandating in its 
contracts and operation that the relevant EU data laws are adhered to. 
Maintaining data integrity and security is a function of OSMF, these 
functions are mandated by EU law, OSMF wherever it is domiciled can 
base its operations on the implementation of EU law.


With respect to current operations where OSM/OSMF operate or 
communicate outside the EU what protections are necessary?


Regards

Tony Shield

aka TonyS999


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


OpenPGP_0x4721711092E282EA.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] Prendre les escaliers à vélo

[Simon Réau]

Bonjour,

Chez Geovelo nous interprétons de la même manière que toi. Escalier
interdit sauf si bicycle=yes ou ramp:bicycle=yes. Peut être peux tu les
contacter pour qu'il modifie leur algo.

Simon REAU
GEOVELO
www.geovelo.fr
simon.r...@geovelo.fr
Tél : 06 77 15 59 86
1 Impasse du Palais, 37000 Tours <https://osm.org/go/0AU_thgO7?m=>




Le sam. 29 août 2020 à 10:59, blef  a écrit :

> Les "bandes roulables à côté sans marches" sont (ou devraient être)
> taguées avec l'attribut ramp:bicycle=yes
> <https://wiki.openstreetmap.org/wiki/FR:Key:ramp>
> Mais les routeurs en question ne se limitent pas à ces (rares) cas pour
> créer leurs itinéraires.
>
> Le 28/08/2020 à 23:32, Philippe Verdy a écrit :
>
> Sauf les escaliers à marches près  peu pentues et pas trop hautes (pas
> plus que les ralentisseurs sur les rues ou aires de parking) ou ceux qui
> disposent d'une bande roulable à côté sans marches et de zones planes
> d'arrêt. Assimilables aux voies (lanes) sur les rues/routes (highways=*
> aussi) s'il n'y a pas de réelle séparation physique entre l'escalier piéton
> et la bande roulante, et donc pas forcément détaillés par des "ways" OSM
> séparés.
>
>
> Le ven. 28 août 2020 à 18:44, blef  a écrit :
>
>> Bonjour,
>>
>> Je m'aperçois qu'en faisant une recherche d'itinéraire en mode vélo, que
>> ce soit avec GraphHopper ou OSRM, on m'envoie sans vergogne sur des
>> escaliers.
>> Pourtant, d'après le wiki
>> <https://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dsteps>, le tag
>> highway=steps implique access=no + foot=yes, donc implicitement bicycle=no,
>> ce qui me semble normal, moi qui n'ai pas pour habitude de descendre (ou
>> monter) les escaliers à vélo!
>> Me confirmez vous que le tag highway=steps ne nécessite pas d'ajouter
>> bicycle=no et donc que les routeurs n'appliquent pas correctement les
>> conditions d'accès dans ce cas?
>> ___
>> Talk-fr mailing list
>> Talk-fr@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-fr
>>
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[Talk-GB] London's COVID infrastructure and Low Traffic Neighbourhoods

[Simon Still]

A couple of blog posts on London Cycling Campaign that may be of interest 

finding-your-way-on-londons-cycle-infrastructure-1 


signage-and-wayfinding 

Low traffic neighbourhoods 
(https://lambethcyclists.org.uk/a-vision-for-lambeth/low-traffic-neighbourhoods/
 
)
 present an interesting challenge for OSM based routing algorithms. 

The generally offer a significant upgrade to the cycling experience within 
their boundaries by significantly reducing motor traffic volumes. The biggest 
change tends to be on the roads of most use to cyclists (ie the ones that 
provide a useful, direct, alternative to the surrounding main roads, or a short 
cut).  Before an LTN these are likely to be busy with rat running traffic. An 
LTN removes that. 

However, I’m not sure how these can be best represented in OSM so that routing 
algorithms can take account of them. As I understand it, in the absence of a 
signed cycle route algorithms won’t see any change in the experience of cycling 
on the roads within the zone.

What do people suggest?  Could we mark LTN boundaries (in the way that the 
congestion charging zone is marked)? Should cycle campaigners be pushing for 
routes through LTNs to be designated and signed?


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

Re: [OSM-talk] Cannot find address ringvegen 45 Sørkjosen in nominatim

[Simon Poole]

Nominatim tries to build correct address hierarchies from the data, in
particular it suspects a matching street (name) in the vicinity if an
addr:street tag is specified. While it will match a wide range on name
tags on streets (see
https://github.com/osm-search/Nominatim/blob/master/settings/import-address.style),
if none match it is not going to work.

Given that this is in Norway, I wouldn't be surprised if it is due to a
difference between //Bokmål and Nynorsk.

tl;dr version fix the street tagging and it will work .

Simon

Am 23.08.2020 um 21:41 schrieb Maarten Deen:
> Node 3117603944 was established in 2014 with tags
> addr:city Sørkjosen
> addr:housenumber 45
> addr:postcode 9152
> addr:street Ringvegen
>
> Yet, when I query nominatim for Ringvegen 45 Sørkjosen I get no results.
>
> What is going wrong here? Sørkjosen itself is found [2] so the problem
> does not seem to lie in the special character (I wouldn't have thought
> so). Also found is the street which is named Ringveien [3] in OSM. No
> idea why the street is called different than the address node, but
> does Nominatim not index address nodes?
>
> The reason why I was looking for this node is because it has a Tesla
> supercharger [4] on address 45 Ringvegen 9152 Sørkjosen.
>
> [1] https://www.openstreetmap.org/node/3117603944
> [2] https://nominatim.openstreetmap.org/ui/search.html?q=S%C3%B8rkjosen
> [3]
> https://nominatim.openstreetmap.org/ui/search.html?q=S%C3%B8rkjosen+ringveien
> [4]
> https://www.tesla.com/nl_NL/findus/location/supercharger/sorkjosensupercharger
>
> Regards,
> Maarten
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] New API suggestion: Allowing contributors to easily track their OSM-objects over time

[Simon Poole]

As, independent of any other concerns, a matter of good form, I would
want to point out that there is no such thing as ownership of
OSM-objects, and discussing a concept of "their OSM-objects" is starting
the discussion on the wrong foot.

Am 22.08.2020 um 11:08 schrieb pangoSE:
> Hi
>
> I would like to track all objects that I ever created or edited.
> I suggest we implement a system to make this easy.
>
> I suggest we create a new system that is updated every time a
> changeset is uploaded. The new system tracks userids and osmids and
> date of last change/edit.
>
> When I create or edit an object an entry is made in this system (if a
> way is converted to relation the relation id is added and so forth).
> If another user converts my way to a relation the system edits the
> userobjects table of both users. This works around the problem of
> missing permanent ids. If a node, way or relation is deleted by anyone
> the row in my userobjects is deleted)
>
> The system can then be queried lke this:
>
> IMPLEMENTATION SUGGESTION:
>
> GET Openstreetmap.org/api/userobjects/pangoSE
> Outputs objects for user pangoSE with the oldest first (outputs 10
> entries,  can be used to get more,  can be used to output
> up to 300 entries, _date=desc by default)
>
> The osmids of the objects can then be used to query the suggested
> verification endpoint to easily find old userobjects that are stale
> and need reverification. The user can be used to generate maps and gpx
> exports of all osmids needing verification for the user to use during
> a mapping quest.
>
> This data is privacy sensitive so the endpoint should require
> permissions from the user to make it easy to write a script or service
> that uses the data on behalf of the user.
>
> WDYT?
>
> Cheers
> pangoSE
> -- 
> Skickat från min Android-enhet med k9.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Use of OSM data without attribution

[Simon Poole]

To add to what Andy has already said, complaints about people using
private paths etc are relatively common, not a large number in absolute
terms, but there tend to be a couple each month which either land with
the DWG, or LWG, or naturally with the local community (I've handled a
couple of them with a different hat on locally, but they are rare).

AllTrails is just one of a handful of sources for such issues. I suspect
that it is simply that such ways that are not part of the public road
network tend to be less stable and sometimes not as well surveyed that
makes this more likely to happen. On top of that right of way and access
legislation tends to differ widely among countries, and what is
completely OK in one may find you at the wrong end of a shotgun in
another and that AllTrails et al are not very good in reflecting that.
Example:  highway=track in the UK, which should probably default to
access=private, but here and say in DE, in general would always have
public access except if signposted differently or gated.

Simon

Am 22.08.2020 um 00:33 schrieb Martijn van Exel:
> Curious anecdote: some AllTrails user apparently looked up a phone
> number for OSM US and called up Maggie. Turns out the complaint was
> about a trail that I originally mapped *blush*. In my defense, that
> was 9 years ago, I haven't been to that part of town much since I
> moved, and nobody else updated the trail, which has since disappeared.
>
> Here is the changeset in case you're interested:
> https://www.openstreetmap.org/changeset/89419938
>
> Martijn
>
> On 8/19/2020 3:44 PM, Clifford Snow wrote:
>> Hey Mike,
>> They definitely mention OSM, even call us a partner [1] but like you
>> found their basemap is definitely OSM. Instead of suggesting their
>> users edit OSM, they instead instruct them to email
>> d...@openstreetmap.org <mailto:d...@openstreetmap.org>,
>>
>> All Trails is located in SF but I couldn't find any listing of a
>> leadership team.
>>
>> Do you want to ask on Slack? Someone there might have a connection.
>>
>>
>> [1]
>> https://support.alltrails.com/hc/en-us/articles/360018930672-How-do-I-update-or-change-information-about-a-trail-
>>
>> On Wed, Aug 19, 2020 at 1:03 PM Mike Thompson > <mailto:miketh...@gmail.com>> wrote:
>>
>>     Has anyone tried contacting the AllTrails[0] people about their
>>     use of OSM without attribution?  I am not talking about the "OSM
>>     Map Layer" that they offer, but rather the default "AllTrails Map
>>     Layer."  At the very least it appears that the trails on that
>>     layer come from OSM.  I know that because I have entered some
>>     rather obscure informal trails in OSMe, and they show up in
>>     AllTrails just as I entered them in OSM.
>>     Mike
>>
>>     [0] https://www.alltrails.com/ (in the search box enter the name
>>     of a trail, park, or city to see their map.)
>>     ___
>>     talk mailing list
>>     talk@openstreetmap.org <mailto:talk@openstreetmap.org>
>>     https://lists.openstreetmap.org/listinfo/talk
>>
>>
>>
>> -- 
>> @osm_washington
>> www.snowandsnow.us <https://www.snowandsnow.us>
>> OpenStreetMap: Maps with a human touch
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] New Bing Imagery

[Simon Poole]

There is even a (never merged and now likely really stale) PR:
https://github.com/openstreetmap/iD/pull/4166

SImon

PS: and an issue too

Am 19.08.2020 um 11:20 schrieb Mateusz Konieczny via Talk-GB:
> Have you checked whatever
> there is an open issue proposing to
> support imagery offset database in iD?
>
>
> 19 Aug 2020, 11:11 by scolebou...@joda.org:
>
> So, I followed the links below and added an offset. But this simply
> isn't a viable solution to the problem because it only works for JOSM
> and not iD.
>
> I managed to convince one mapper to type in the offset manually in iD
> every time, but that is a horrible thing to ask new mappers to do,
> very offputting. And now I can see Amazon mappers using an iD variant
> that doesn't have the offset and moving all the roads as a result:
> 
> https://osmcha.org/changesets/89549551?aoi=758c7f2b-faca-44e5-acd2-0cb8c33034bd
> https://www.openstreetmap.org/changeset/89549551
> This is going to keep happening so long as OSM has multiple image
> sources and multiple editors. Frankly I'm amazed that this isn't a
> solved problem.
>
> Having done some mapping across the country recently, it seems like
> Bing is offset to the previous best imagery across the country, but by
> varying amounts. Is there really no solution that can be applied to
> the source Bing layer? Or should we all just accept Bing as golden?
>
> Having added thousands of buildings and fixed roads to align to the
> previous best imagery, I don't have a good solution to the problem,
> and it is demotivating to think that others are going to come along
> and move individual roads/buildings to align without considering the
> bigger picture.
>
> The only solution I can think of is to move all nodes in the area I've
> worked on to match the new Bing (ie a mass edit). Any other
> suggestions?
>
> Stephen
>
>
>
>
>
>
>
>
>
>
> On Sun, 12 Jul 2020 at 23:36, Mateusz Konieczny via Talk-GB
>  wrote:
>
>
> 
> https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Imagery_Offset_Database/Quick_Start
> https://wiki.openstreetmap.org/wiki/Imagery_Offset_Database
> (I think that nowadays it is built in - is plugin installation
> still necessary?)
>
>
> No idea about iD support -
> https://github.com/openstreetmap/iD/search?q=imagery+offset
>
> Jul 13, 2020, 00:21 by scolebou...@joda.org:
>
> Wow, the imagery is really good. But in my area the imagery is
> about
> 3-4m east west and 3-4m north south out of alignment with Esri
> World
> Imagery (Clarity) Beta, which is what I've been using up until now
> (for thousands of buildings).
> https://www.openstreetmap.org/#map=18/51.39886/-0.24940
>
> Is there any way to unify the alignments?
>
> Stephen
>
>
> On Thu, 9 Jul 2020 at 06:41, Gareth L  wrote:
>
>
> I’ve noticed patches of vastly improved bing imagery since
> December, but it is really patchy.
> Gareth
>
> > On 6 Jul 2020, at 23:21, Cj Malone
>  wrote:
> >
> > I was splitting houses in Portsmouth/Southsea this morning.
> The imagery
> > is great, I don't know if it was part of this update, or if
> it's been
> > like this for a while.
> >
> >
> > ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb


signature.asc
Description: OpenPGP digital signature
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] National Cycle Network removal/reclassification

[Simon Still]

> On 14 Aug 2020, at 20:44, David Woolley  wrote:
> 
> On 14/08/2020 19:14, Simon Still wrote:
>> I’m not sure that’s actually a legal status that changes anything - 
>> pedestrians have priority on all shared use paths so not sure that tag would 
>> add anything
> 
> Towpaths are privately paths (currently owned by the Canals and Rivers 
> Trust), so the rules for public paths don't apply.  At one time  you had to 
> apply for a free licence to cycle on them, the quid for quo for which was a 
> promise to do things like give pedestrians priority.

True, but there are also ‘pedestrian priority’ signs in parks and on other bits 
of shared path.  No one has ever been stopped by the police for ‘failing to 
give pedestrian priority’ - it would be reckless cycling or something similar. 

I’m just struggling to think what the tag would add - either for information or 
for a routing algorithm.  Also note the the proposals for the highway code 
would establish and road user hierarchy which would apply everywhere 
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] National Cycle Network removal/reclassification

[Simon Still]

> On 14 Aug 2020, at 16:47, Ken Kilfedder  wrote:
> 
> I believe most of the canal towpaths are 'pedestrian priority' too - at least 
> there are signs to that effect all over the place.  Well worth tagging them 
> to that effect if true.


I’m not sure that’s actually a legal status that changes anything - pedestrians 
have priority on all shared use paths so not sure that tag would add anything 


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

Re: [Talk-GB] National Cycle Network removal/reclassification

[Simon Still]

> On 14 Aug 2020, at 09:31, Robert Skedgell  wrote:
> 
> On 13/08/2020 15:41, Simon Still wrote:
>> 
>> In my view there is definitely scope to look at adding more info to
>> cycle routes/tracks/cycleways to give more information to routing
>> algorithms about the real experience of using them.
>> 
>> Would welcome input on what as we’re doing more on this at the London
>> Cycling Campaign. 
> 
> Is there any more information on what LCC are doing in this area? There
> are probably members, myself included, who would be happy to help.
> 
> I know that borough groups audit changes to local infra, but having
> detailed photographs and notes are less useful to the wider cycling
> community than they could be if the information never finds its way onto
> OSM.

See the blog posts that I linked to.  
Plus 
 https://wiki.openstreetmap.org/wiki/TfL_Cycling_Infrastructure_Database 
<https://wiki.openstreetmap.org/wiki/TfL_Cycling_Infrastructure_Database> 

(Our involvement has now ended but TfL should be continuing to use CID info to 
improve OSM accuracy) 

More discussion planned within LCC and community to press for better navigation 
and wayfinding 

>> 
>> Width of cycleyway is definitely useful if separated from traffic but
>> some way of reflecting the comfort of the riding experience on marked
>> routes would be a big step forward. Traffic Volumes,. Lane widths,
>> traffic speed all contribute (as does surface - gravel bad, cobbles bad,
>> smooth tarmac good)  
> 
> Most sections of cycle routes in London which I use already have
> surface=* set, but there are areas where using smoothness=* consistently
> might help.


Good to know surface is already widely used - I’d managed to miss that in the 
work I’d done. 
Smoothness is a new tag for me 

What has come up in discussions is that it would be good to map ‘restrictions’ 
more comprehensively and have routing algorithms that recognised them.  

There are many sections of cycle route (such as canal towpaths) have many - 
rough surface, steep inclines to rejoin roads, width 
restrictions/gates/barriers to stop motorbikes and tight turning radii.  All of 
those would create issues for someone using a bakfiets, cargo bike or 
disability adapted cycle. 

An objective would be to be able to plan a ‘disabled suitable route’ 

Simon Still;
Campaigns Team, LCC___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-de] Starrflügel-Drohne für Luftbilder

[Simon Poole]

Siehe auch
https://bvcp.de/multicopter-news/recht/geltungsbeginn-eu-verordnung/

Am 14.08.2020 um 14:15 schrieb Simon Poole:
> Ich gehe davon aus, dass nicht die neue, neue Drohenverodnung ist,
> sprich noch keine Anpassung an das neue Europäische Recht beinhaltet.
>
> Ich würde im Augenblick auch eher davon abraten irgendwas zu kaufen
> ausser es ist schon nach den neuen Bestimmungen zugelassen.
>
> Simon
>
> Am 14.08.2020 um 13:48 schrieb Stefan Kaufmann:
>> Am 14.08.20 um 13:18 schrieb Jo:
>>
>>> Es ist aber viel einfacher um dann die Zulassung zu bekommen. Es kann sein
>>> dass das nur wichtig ist in Belgien. Mit meines (900g) darf ich hier nur
>>> 10m hoch fliegen und das reicht ja nicht für Luftbilder.
>> Rechtslage in Deutschland ist anders:
>>
>> https://www.heli-planet.com/downloads/flyer_die_neue_drohnen_verordnung.pdf
>>
>> regards,
>> -stk
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-de
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de


signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Starrflügel-Drohne für Luftbilder

[Simon Poole]

Ich gehe davon aus, dass nicht die neue, neue Drohenverodnung ist,
sprich noch keine Anpassung an das neue Europäische Recht beinhaltet.

Ich würde im Augenblick auch eher davon abraten irgendwas zu kaufen
ausser es ist schon nach den neuen Bestimmungen zugelassen.

Simon

Am 14.08.2020 um 13:48 schrieb Stefan Kaufmann:
> Am 14.08.20 um 13:18 schrieb Jo:
>
>> Es ist aber viel einfacher um dann die Zulassung zu bekommen. Es kann sein
>> dass das nur wichtig ist in Belgien. Mit meines (900g) darf ich hier nur
>> 10m hoch fliegen und das reicht ja nicht für Luftbilder.
> Rechtslage in Deutschland ist anders:
>
> https://www.heli-planet.com/downloads/flyer_die_neue_drohnen_verordnung.pdf
>
> regards,
> -stk
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-GB] National Cycle Network removal/reclassification

[Simon Still]

> On 13 Aug 2020, at 11:41, Robert Whittaker (OSM lists) 
>  wrote:
> 
> On Sat, 18 Jul 2020 at 14:49, Richard Fairhurst  wrote:
>> ... However, note that the "removed"
> sections mostly won't be reflected on the ground yet. Also, the
> dataset isn't perfect, as there's at least one bit near me where the
> route Sustrans have is wrong. I think it's also likely that some of
> the small gaps that have been created are inadvertent and will quickly
> be filled back in as volunteers review the new network.
> 
> We also might need to think about our tagging, as there will now be
> more levels of routes: Full NCN routes, other promoted named routes
> that aren't on the NCN. How can we distinguish these in OSM?
> network=ncn and network=rcn are typically used for national and
> regional level routes rather than specifically the Sustrans NCN.

An interesting conundrum.  I’m thinking about mapping and navigation in London 
at the moment (see blogs at 
https://www.lcc.org.uk/articles/finding-your-way-on-londons-cycle-infrastructure-1
 

https://www.lcc.org.uk/articles/signage-and-wayfinding 



So my understanding is that OSM normally only maps what’s actually on the 
ground rather than what might be shown on a map (and there was some discussion 
recently about this - 
https://www.mail-archive.com/talk-gb@openstreetmap.org/msg19303.html)

So even if Sustrans declassify it, if the signs are still up shouldn’t it 
remain in OSM?  Conversely  - how do you deal with older bits of say London 
Cycle Network where signs have been removed or become unreadable. For example, 
I recently had an extended discussion about the status of the paths in 
Brockwell Park in Brixton (changeset here - 
https://www.openstreetmap.org/changeset/83547875 
 )  Maps showed routes and 
there may once have been signage but there is no longer any signage and 
supporting information says there is not a designated ‘route’ here. 

In my view there is definitely scope to look at adding more info to cycle 
routes/tracks/cycleways to give more information to routing algorithms about 
the real experience of using them.

Would welcome input on what as we’re doing more on this at the London Cycling 
Campaign. 

Width of cycleyway is definitely useful if separated from traffic but some way 
of reflecting the comfort of the riding experience on marked routes would be a 
big step forward. Traffic Volumes,. Lane widths, traffic speed all contribute 
(as does surface - gravel bad, cobbles bad, smooth tarmac good)  ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Roadmap for deprecation of name tags in OSM

[Simon Poole]

The "names" in wikidata are mostly the names of WP pages for the object
in question and have little to do with actually existing names (as per
the OSM definition) of places.

It would be a massive drop in quality if we would do the proposed switch.

Simon

Am 09.08.2020 um 10:25 schrieb pangoSE:
> I suggest we create a roadmap for deprecating of storing and updating
> names in OSM for objects with a Wikidata tag.
>
> The rationale is explained here:
> https://josm.openstreetmap.de/ticket/19655
>
> This of course affects the whole project and data consumers as well.
> Every OSM user will have to become a Wikidata user as well to edit the
> names or add name references (through the editors)
>
> Substantial changes will have to be made:
> * nominatim will need to support fetching names from wikidata somehow.
> It could probably be done on the fly.
> * openstreetmap.org will need to fetch from wikidata when displaying
> any object.
> * rendering the standard map will have to support fetching from wikidata.
> * all editors would have to fetch and enable editing of Wikidata objects.
> * maybe it no longer makes sense to have 2 separate logins? We should
> unify the logging in as much as possible. Ideas are welcome on how to
> do that. Perhaps retire signing up as OSM user on osm.org and ask
> users to create a Wikimedia account instead and log in with that?
>
> I personally don't see any problems connecting Wikimedia and OSM
> closer than the islands they are today.
>
> As mentioned in the ticket above data consumers like Mapbox already
> prefer Wikidata names. I'm guessing thats because they are simply
> better quality, better modeled, better referenced and better protected
> against vandalism.
>
> WDYT?
>
> Cheers
> pangoSE
> Ps I choose this list because this not only relates to tagging, but to
> the wider ecosystem.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

Am 04.08.2020 um 17:05 schrieb Alexandre Oliveira:
>> At this time nobody is proposing anything more than giving P2 a bit more 
>> life for a small sum of money
> And as myself and others have brought up, it's not a good idea to
> spend money to port P2 from a dead technology to another dead
> technology, if people still use it it's much more beneficial in the
> long term to port it to modern web technologies than have to spend a
> few thousand bucks every once in a while to port a software that's
> pretty important for OSM (even though its usage has decreased over the
> years the changeset amount is still high) to another dead technology.
The problem with that is that it implies 2 to 3 more zeros (at least)
before the decimal point in the costs, and -then- the question really
arises why we are doing that. Literally nobody including Richard has
proposed to spend more money down the road, and given that he tends to
be relatively down to earth I assume he is not expecting eternal support.
>
> As someone (I can't recall who it was) said, "$2500 is not much", then
> if the OSMF wants to spend it on useless efforts (i.e. porting P2 from
> Flash to Air) then why not give it to me then, if the OSMF wants to
> spend this money? :P Jokes aside, if the OSMF really wants to spend
> this money I'd suggest it to be spent somewhere else if the board is
> so keen on setting up life support and going through the stress that
> it is to maintain dead libraries.

The reason is that the users want to continue to use P2 for now (see
discussion in the forum for example). To put this in to perspective we
are talking about a one time spend of about 1 € per head, somewhat less
than what iD costs per year (every year), and at least an order of
magnitude less than the same for JOSM etc.

Simon 




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

Could we move all the programming language du jour fanboying, apps that
have nothing to do OSM and other unrelated to the topic discussions
somewhere else please?

And yes it underlines my point that regardless of how exotic the feature
is, you are always going to find somebody that finds it critical to
success (this one of the reasons why JOSM has three variants of
everything), but it isn't a good measure of what the OSMF should spend
its money on, weere applying an 80/20 rule is likely to be far more
appropriate.

At this time nobody is proposing anything more than giving P2 a bit more
life for a small sum of money, if Richard has a plan for longer term
maintenance and development then that should be considered when
proposed. Definitely nobody is going to embark on the multi-million
undertaking that writing and bringing to production a new editor is,
just on the base that it would be cool to write one in .

Simon

Am 04.08.2020 um 16:26 schrieb Matthew Woehlke:
> On 04/08/2020 08.10, Martin Koppenhoefer wrote:
>> On 4. Aug 2020, at 13:58, Matthew Woehlke wrote:
>>> but I would practically *kill* for JOSM to have FreeCAD's suite of
>>> sketch constraints ;-).
>>
>> you’re aware that there are sketch constraints for configurable
>> angles (90, 60, 45 etc) and projection snaps? Hit 2 times „a“ (angle
>> display becomes green)
> Yes. They're better than nothing, but nowhere near what I'm talking
> about. As an example, consider the attached simple FreeCAD sketch
> which is roughly representative of some buildings I've mapped
> recently. The dome in front is centered (segments on either side
> constrained to be equal). The "wings" in back are symmetrical.
>
> It's *possible* to do this sort of thing in JOSM with a lot of care
> and by building part of the geometry, then constructing a bunch of
> "scratch" geometry in order to construct a symmetry line, then doing a
> copy, paste in place, mirror, reverse, stitch the parts together...
> but God help you if you make a mistake and have to start over.
>
> In FreeCAD, you just slap on some equality constraints, angle
> constraints, parallel constraints, etc. and then you can *move* any of
> the nodes and everything else will update to preserve the applied
> constraints. (The one things it's missing that would be helpful is a
> *colinear* constraint; you have to simulate that with parallel and
> coincident constraints using "construction" lines; those are the blue
> ones. A colinear constraint could eliminate the need for those
> construction lines.) This is the major difference, though. In JOSM,
> constraints only apply when you initially draw something, so if you
> get it wrong, you have to start over. In FreeCAD, they're a dynamic
> system; if you get it wrong, just nudge it and the whole thing updates
> *while preserving your constraints*.
>
> Oh, and *arcs*. The ability to define a segment that should be a
> perfect arc, and optionally make it tangent or perpendicular to its
> neighbors, would be a major boon. Again, I can fake it with a bunch of
> scratch construction, but if it's wrong, I have to start over and hope
> my next guess is better. In FreeCAD, just drag the end points until it
> looks right.
>
> Then there are distance constraints, which would be incredibly useful
> if you're mapping something with known dimensions.
>
> Seriously, give FreeCAD a spin. It's pretty awesome for this sort of
> relatively simple 2D stuff. Also look at some of the buildings I've
> done recently; the symmetrical ones don't just *look* symmetrical,
> they *are* symmetrical (within the limits of JOSM's abilities). I've
> also done a lot of stuff like roads that are perfectly centered in
> between parking spaces, groups of aligned buildings that are
> *actually* aligned, and whatnot. It's do-able, but it would be *s*
> much easier with FreeCAD-style constraints.
>
> Obviously, this would all almost surely be a temporary mode (maybe it
> persists as long as JOSM is open, but isn't uploaded), but since you
> usually draw once, that would be fine. (Bonus points if JOSM could
> automatically recreate constraints for ways that don't have any. It
> shouldn't be hard to guess equality, perpendicular and colinear
> constraints, at least.)
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

Am 02.08.2020 um 11:31 schrieb mmd:
> ...
> In a more mid-term, I really like to see a move away from such
> proprietary platforms to an editor that runs in a browser
> out-of-the-box. 

...

Don't we already have that?




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

Am 02.08.2020 um 01:03 schrieb Skyler Hawthorne:
> ...
>
> Sorry if this sounds harsh, but I think using any funds at all to
> continue support for a tool that 1% of editors use would be wasteful.
> Flash is, for all intents and purposes, a dead technology. This money
> is better spent on other uses.
> ...

Extending this a bit further, you could just as well say, given that all
current and actively maintained general purpose editors require 1-2
FTEs, the OSMF should simply block all non-iD editors and tell the
developers to either work on iD or go home.

In reality things are not quite that simple,  it starts with measuring
how much use an app actually gets.

While iD outstrips JOSM substantially wrt users (JOSM has less than 10%
market share), a majority of the iD users have a very small number of
edits and are non recurring contributors. This reflects itself in the
edit counts too where the ratio is ~2/3 JOSM and 1/3 id. Naturally JOSM
-currently- tends to get used for larger edits which is likely a major
factor. Given that P2 users are mostly long time OSM contributors that
edit regularly, a similar pattern can be seen, and I think that a one
time update at the proposed cost can easily be justified.

Now medium term, that is 1-2 years, this is likely going to change
substantially. iD is branching out in to more and more niches, reducing
the breathing space for anything else massively and other editor use has
effectively been stagnating for a long time. While people will
automatically try to start listing special use cases that can "only" be
done with editor XX, the problem is that these are special cases and
unlikely to be worth spending a couple of $100k on per year (virtually
or real) for the small number of users that will remain as iD gains more
and more features.

Simon




signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

[Simon Poole]

That was a good decade ago, nothing that would factor in to a decision
now (because Linux could not be a target platform to start with). 

Am 01.08.2020 um 10:16 schrieb Sören Reinecke via talk:
> So far as I understood Adobe dropped Linux support for its AIR
> plattform. If that is right, then I am in doubt that supporting the
> development of Potlatch 2 is not that in a sustainable manner.
>
> Cheers
>
> Sören Reinecke
>
>
>  Original Message 
> Subject: [OSM-talk] Funding of three infrastructure projects :
> Nominatim, osm2pgsql, Potlatch 2
> From: Guillaume Rischard
> To: OSMF Talk
> CC: OpenStreetMap talk mailing list
>
>
>   Hi all,
>
> The OSMF Board wants to facilitate and support improving
> infrastructure. During the Microgrants process, there were
> proposals that didn’t make it, but would together be a good pilot
> for a “OSM infrastructure” process, to learn how supporting osm
> infrastructure projects works well.
>
> The OSMF Board wants to fund a limited number of projects proposed
> by trusted long-term volunteers whose work we know and enjoy. We
> have selected the osm2pgsql and Potlatch microgrant proposals, and
> have a new proposal from Nominatim.
>
> In the long term, we want to re-activate the Engineering Working
> Group (EWG) by making it a place for decision making, project
> guidance and budget management for such projects.
>
> The Board would like your feedback on these three specific
> infrastructure projects:
>
>
> Nominatim
>
> Nominatim is the geocoding software that powers openstreetmap.org
> and many other apps and websites. Sarah wants to work on:
> 
>
>  *
>
> finishing the localization efforts (improve address
> computation for different countries, localized address output)
>
>  *
>
> making the software more user-friendly (reduce the number of
> programming languages by at least two, move side-projects into
> separate repos, reorganise the code so that Nominatim can
> become an Ubuntu package, docs, docs, docs)
>
> The full proposal is at
> https://wiki.osmfoundation.org/wiki/Nominatim_project_2020-07
>
>
> Potlatch 2
>
> Potlatch 2 used to be the default editor before iD took the relay.
> While usage is declining, it’s still used by 2500 (1.4%) users who
> did 10 million (1.2%) changes in 2020.
> 
>
> Potlatch is built in Flash, which browsers will retire by the end
> of the year. Richard wants to adapt Potlatch 2 to the AIR platform
> so users who still rely on it can continue to use it.
>
> The full proposal is at
> 
> https://wiki.openstreetmap.org/wiki/Microgrants/Microgrants_2020/Proposal/Potlatch_2_for_desktop
>
>
>
> osm2pgsql
>
> osm2pgsql loads OpenStreetMap data into databases suitable for
> applications like rendering into maps, geocoding with Nominatim,
> or general analysis. It is used on openstreetmap.org and in many
> other places. 
>
> While there has been constant paid and volunteer work on
> osm2pgsql, large scale architecture changes to pay off historical
> technical debt are needed to tackle long term challenges, and make
> future changes easier.
>
> Jochen wants to work on:
>
>  *
>
> Hosting documentation on osm2pgsql.org 
>
>  *
>
> Rethinking the output of the program to make it more concise
> and useful
>
>  *
>
> Tackling the refactoring and cleanup of the “middle” code.
>
>  *
>
> Ongoing maintenance as needed
>
>  *
>
> Other work from the road map as time permits
>
> The original budget and scope were limited by the microgrant
> framework. The current project goes beyond that, and addresses
> open issues and potential improvements further and better.
>
> The proposal is at
> https://wiki.osmfoundation.org/wiki/Osm2pgsql_project_2020-07
>
>
>
>
> Thank you and happy mapping
>
> Guillaume, for the OSMF board
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] Electric vehicle charging points

[Simon Still Gmail]

I’ve been adding them in My area. The tagging is established 

Sent from my iPhone

> On 21 Jul 2020, at 12:00, Mark Goodge  wrote:
> 
> Do we map electric vehicle charging points? If not, should we?
> 
> None of the ones in my town are on OSM, at the moment. I could add them, but 
> it seems a bit pointless if they're not generally mapped.
> 
> Mark
> 
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [OSM-talk-fr] Désaccord sur un highway=footway

[Simon Réau]

Je pense aussi que c'est la bonne solution pour cette zone difficile.

Simon REAU
GEOVELO
www.geovelo.fr
simon.r...@geovelo.fr
Tél : 06 77 15 59 86
1 Impasse du Palais, 37000 Tours <https://osm.org/go/0AU_thgO7?m=>




Le mer. 15 juil. 2020 à 21:22, Éric Gillet  a
écrit :

> Le 02/06/2020 à 10:11, Éric Gillet a écrit :
> > Le 01/06/2020 à 22:31, osm.sanspourr...@spamgourmet.com a écrit :
> >>
> >> Donc si on revient sur le coin d'où on est parti :
> >>
> >> - y a-t-il un panneau autorisant les cycles ? Non
> >> - y a-t-il un panneau interdisant les cycles ? Non
> >>
> >> De partout on arrive sur ce qui ressemble soit à un trottoir soit à
> >> une place piétonne.
> >>
> >> Dans le premier cas bicycle=no (implicite, c'est un footway).
> >>
> >> Dans le second cas bicycle=yes (implicite c'est un pedestrian).
> >>
> >> Et comme c'est pas clair on met bicycle=permissive : pas fait pour
> >> mais personne ne dit rien.
> >> J'ai l'impression d'avoir suivi ta logique et j'aboutis à une
> >> solution qui semblait convenir aussi à Eric.
> >>
> > highway=footway/pedestrian + bicycle=permissive me semble en effet le
> > bon compromis entre la légalité/l'intention de l'urbanisme et ce que
> > les gens font en général dans cette zone.
>
> Après avoir laissé décanter j'ai pris la solution qui a fait le moins de
> vagues pour indiquer les zones grises : access=permissive.
>
> Merci pour l'échange !
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[talk-au] unsubscribe [SEC=OFFICIAL]

[Costello Simon]

Please remove Simon Costello from this mailing list.
Nik

Nicole Manning 
Executive Assistant to Simon Costello | National Location Information Branch
Place, Space and Community Division
 
t +61 2 6249 9277    www.ga.gov.au

Part-time hours
Mon, Tue, Thur & Friday 9.30 to 2.00
 

 




-Original Message-
From: talk-au-requ...@openstreetmap.org  
Sent: Sunday, 19 July 2020 4:49 PM
To: talk-au@openstreetmap.org
Subject: Talk-au Digest, Vol 157, Issue 18

Send Talk-au mailing list submissions to
talk-au@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openstreetmap.org/listinfo/talk-au
or, via email, send a message with subject or body 'help' to
talk-au-requ...@openstreetmap.org

You can reach the person managing the list at
talk-au-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of Talk-au digest..."

Geoscience Australia Disclaimer: This e-mail (and files transmitted with it) is 
intended only for the person or entity to which it is addressed. If you are not 
the intended recipient, then you have received this e-mail by mistake and any 
use, dissemination, forwarding, printing or copying of this e-mail and its file 
attachments is prohibited. The security of emails transmitted cannot be 
guaranteed; by forwarding or replying to this email, you acknowledge and accept 
these risks.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-fr] Objet temporairement absent

[Gaël Simon]

Bonjour, tu peux remplacer amenity par disused:amenity avec un commentaire 
indiquant le caractère temporaire
Bonne journée 

Gaël

Le 19 juil. 2020 à 13:17, Arnaud Champollion 
 a écrit :

Bonjour,

À Digne une boîte à livre de type 
https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dpublic_bookcase

a été retirée par son propriétaire en début de confinement.

Elle n'a toujours pas été remise en place, mais on peut supposer qu'elle le 
sera à court ou moyen terme.

Pour ne pas perdre l'historique de l'objet, puis-je le "suspendre" avec un 
attribut spécifique, au lieu de le supprimer ?

Merci

Arnaud


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

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

[OSM-talk-fr] Siège des EPCI

[Gaël Simon]

Bonjour,
De nombreuses relations EPCI n’indiquent pas leur siège avec le rôle 
admin_centre. Par contre beaucoup ont un tag wikidata qui indique l’emplacement 
de ce siège. Ajouter l’admin_center a-t-il alors un intérêt ou ces informations 
sont-elles redontantes ?

Par ailleurs, j’ai fini de cartographier les EPIC de type PETR (pôles 
d’équilibre territorial et rural).

Gaël
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] API indisponible ?

[Gaël Simon]

Bonjour,
Je travaille sous JOSM et depuis quelques minutes j’ai le message Le nom d’hôte 
api.openstreetmap.org n’a pas pu être résolu. 
Je suis le seul ?
Merci

Gaël
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-legal-talk] local copyright law on government data and OSM license

[Simon Poole]

This is not a particular unique situation, a sovereign country can,
naturally, create exclusive rights or specific regulation for more or
less whatever it cares.

Copyright is simply the most popular, with wide spread understanding and
international treaties as support, set of exclusive intellectual
property rights. But there is nothing stopping a government special
casing geodata or other ip that they produce, or introducing special
protection for otherwise not protected works, there can simply be no
expectation that such regulation could be internationally enforced and
reciprocal. Two examples are the national geo information law where I
live and sui generis database rights in the EU.

(Omiting some edge cases here, essentially the ones that you shouldn't
ask about, because you wont like the answer) OSM is interested in its
geodata being useful and usable globally, and because of its nature,
particulary in the country the data is relevant in. As a result, unlike
other projects, we can't ignore national quirks and restrictions and
need to accomodate them as far as it is compatible with our mission.

So in this case I would take the conservative stance (as our licence is
open and does not discriminate against commercial use) and suggest that
any use of government data would need permisson. I would not try to
outlawyer the government as your argumentation would seem to imply you
would like to do.

Naturally it is completly possible to produce a fully functional map
without resorting to government data, so not getting such permission is
not a show stopper.

tl;dr version: if you have quirky national regulations then please abide
by them so that your work contributing to OSM is not in vain. If you are
a resident in one of the edge case territories, you should read the OSMF
ToU and carefully consider your situation.

Simon

On 16.07.2020 22:59, Eugene Alvin Villar wrote:
> Hi Kathleen, all,
>
> Just as a bit of reference, the original intellectual property law
> from 1924, back when the Philippines was a territory of the United
> States, didn't have this commercial-with-prior-approval second
> sentence and was basically modeled after the U.S. law (government
> works are fully in the public domain). This additional sentence was
> added in 1972 and was retained in the present law of 1997. Previous
> analysis of the current law by Wikimedia volunteers with respect to
> copyright can be seen here and which concludes that this second
> sentence is some sort of additional non-copyright-based government
> right:
> https://commons.wikimedia.org/wiki/Commons:Deletion_requests/Template:PD-PhilippineGov
>
> This situation actually raises a lot of questions especially in the
> context of OSM. For instance, if a government agency published a
> dataset of polygons of places, it would probably be best to get the
> agency's prior approval to import such dataset in order to waive the
> requirement of "prior approval [...] for exploitation of such work for
> profit" because end users of OSM should not have to ask the agency for
> approval if they want to use the data that was included in OSM for profit.
>
> On the other hand, if an OSM mapper /derives/ new data from such a
> dataset (for example, generating a representative point for each
> polygon, maybe at the centroid, or maybe at at the "admin centre" if
> the polygon represents settlements and the mapper used their best
> judgement and research to place such points), then this new dataset is
> no longer the same as the government dataset. If the OSM mapper added
> the new derived data to OSM, then one could perhaps argue that prior
> approval from the government agency is no longer needed because the
> very act of mapping in OSM is not "for exploitation of such work for
> profit". And furthermore, end users of OSM would also perhaps not need
> to seek "prior approval" as well since they are not exploiting the
> original government dataset but rather a derived dataset (ex.,
> points), and which cannot be used to reverse engineer the original
> government dataset (ex., polygons).
>
> Regards,
> Eugene
>
>
>
> On Thu, Jul 16, 2020 at 10:57 AM Kathleen Lu via legal-talk
> mailto:legal-talk@openstreetmap.org>>
> wrote:
>
> A few thoughts:
>
> I'd want to talk to a Philippine lawyer, because frankly, these
> two sentences seem to contradict each other: /_No copyright shall
> subsist in any work of the Government of the Philippines. However,
> prior approval of the government agency or office wherein the work
> is created shall be necessary for exploitation of such work for
> profit_
> /
>
> What would be the consequences of not getting permission? A
> violation of the government's non-copyright rights? Rights of
>

Re: [Talk-GB] Call to action: Translators needed

[Simon Poole]

On 14.07.2020 17:21, o...@poppe.dev wrote:
> ... again, your wording sounds like you don't trust the organizations further 
> that you could throw a rock and basically discard their efforts as those of 
> money-hungry, evil corporations that aren't interested in the humanitarian 
> aspect at all (Ablasshandel was a big thing in medieval times, I guess we 
> shouldn't go down that road).

I've never found the concept of trust when dealing with legal entities
of any kind useful. In any case the correct throwing distance would be
dropping the stone.

There is nothing wrong with being money hungry btw, leads to predictable
behaviour, and is less fickle than many other things.

>
> I know that I might be exaggerating, but in essence you're just lumping all 
> 20+ organizations together and ignore their individuality.

I'm just commenting on the involvement "in" OSM which is fairly uniform.
OK HOT seems to be pivoting now around globalizing its paid mapping
business, but that is maybe because they are wising up on the fact that
the ambulance chasing may have run its course as a funding mechanism.

In any case you should do your own research on the organizations, some
have very good reputation, say MSF, others less so.

>> A "Call to action" for MapSwipe translations just reiterates the same
>> concepts in the particular absurd situation were the issue  at hand
>> could have been resolved with a couple of minutes work at any time over
>> the last 5 years if the developers were even remotely interested in
>> cooperating with wider OSM instead of just sapping out some manpower.
> "Call to action" was _my wording_ and _my idea_ alone, nobody forced me to 
> word it that way, nor have I given it a second thought, so every criticism to 
> that reflects back to my action.
>
> If you think that the developing team could have just done/given thought "5 
> more minutes" (As a developer for 30+ years, I'm very sceptical of such 
> claims) to incorporate their project into the established areas, there's no 
> hinderance for you to get into contact (because you now know of the problem, 
> that's why nobody has done so earlier) with them, and provide an easy 
> solution to the absurdity of the situation that you see.

It essentially boils down to checking a couple of boxes in transifex and
sending an announcement out to the existing translators that there is a
new project available, and changing the base URL for the project in
whatever they use to automate translations now.

Numerous projects have done it in the past, really no big deal.

And I've suggested it to "Humanitarian" projects before (would have to
dig if it was specifically MapSwipe), but as with essentially all
"Humanitarian" software development there is essentially no cooperation
with any mainstream OSM work, which may have to do with funding, maybe not.

>
> You might have just had a bad day just like I had a couple of unpleasant 
> weeks, but I do not understand your reasoning for your reactions. That might 
> just be me and I might be completely in the wrong here, but I suggest we 
> leave it at that. 
>
> Kai

It is just experience vs. trust.

Simon


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

Re: [Talk-GB] Call to action: Translators needed

[Simon Poole]

I've been asked to clarify this as it might come across as a personal
attack which was not intended, sorry.

The, very well funded, organizations in OSM space that claim
"Humanitarian" for themselves, market themselves mainly by having a
never ending stream of emergencies (some real, some not, some where OSM
mapping could be useful, some not) that urgently need attention.

In exchange for allowing HOT, MM etc to monetize your participation in
"resolving" these emergencies, you get alleviated to a superior human
being, well at least for a while. Think of it as a digital Ablasshandel,
just that in the middle ages the benefits were probably more tangible.

A "Call to action" for MapSwipe translations just reiterates the same
concepts in the particular absurd situation were the issue  at hand
could have been resolved with a couple of minutes work at any time over
the last 5 years if the developers were even remotely interested in
cooperating with wider OSM instead of just sapping out some manpower.

Simon

On 13.07.2020 00:59, Simon Poole wrote:
> It's the other way around, I believe you are the victim and have been had.
>
> Am 12. Juli 2020 21:12:15 MESZ schrieb Kai Michael Poppe - OSM
> :
>
> On 12.07.2020 20:58, Simon Poole wrote:
>
> The project in question could have naturally joined the
> OpenStreetMap transifex organisation and profited from a
> couple of 100 very experienced translators, but that would be
> too simple. 
>
>
> Well, don't kill the messenger. I myself only today discovered that 
> there's a JOSM team and an OSM organization.
> It might be worth checking whether the projects could be moved to the OSM 
> org.
>
> Kai
> 
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
> -- 
> Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail
> gesendet.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Call to action: Translators needed

[Simon Poole]

It's the other way around, I believe you are the victim and have been had.

Am 12. Juli 2020 21:12:15 MESZ schrieb Kai Michael Poppe - OSM :
>
>On 12.07.2020 20:58, Simon Poole wrote:
>
>> The project in question could have naturally joined the OpenStreetMap
>transifex organisation and profited from a couple of 100 very
>experienced translators, but that would be too simple.
>
>Well, don't kill the messenger. I myself only today discovered that
>there's a JOSM team and an OSM organization.
>It might be worth checking whether the projects could be moved to the
>OSM org.
>
>Kai
>
>___
>Talk-GB mailing list
>Talk-GB@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-gb

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Call to action: Translators needed

[Simon Poole]

The project in question could have naturally joined the OpenStreetMap transifex 
organisation and profited from a couple of 100 very experienced translators, 
but that would be too simple.

Am 12. Juli 2020 19:50:43 MESZ schrieb Kai Michael Poppe - OSM :
>Good evening list!
>
>During last week's Missing Maps London event I got to know the mobile
>App "MapSwipe". This app is used to identify Imagery Tiles with
>specific features like buildings, roads, etc. in countries with low map
>coverage (i.e. developing/least developed countries). It is a
>second-level crowdsourcing platform and it's data is used by the
>Humanitarian OpenStreetMap Team (HotOSM.org) to feed it's taskmanager.
>From there volounteers use computer-based editors to map the tiles that
>were marked as having a mappable feature.
>
>Enough marketing talk, this is what this mail is about: The developing
>team uses Transifex
>(https://www.transifex.com/mapswipe/mapswipe-app/dashboard/) to
>translate the strings in the OpenSource-App
>(https://github.com/mapswipe/mapswipe) and is looking for people who'd
>love to contribute with more translations or finishing/reviewing the
>existing languages. Czech only needs review, but Dutch, French,
>Japanese, Nepali, Persian, Swahili, Hungarian, Indonesia, Russian and
>Spanish are still missing loads of translated strings.
>
>So, if any of you would be able to help with any of the languages
>mentioned above (you may also add any other language that you think
>should be on the app), this would be greatly appreciated!
>
>Please do not hesitate to share this mail with anyone you think could
>help or cross-post this outside this list, I haven't done so anywhere
>except the German Telegram Group t.me/OSM_de.
>
>Thank you for reading this far :)
>
>Kai
>
>___
>Talk-GB mailing list
>Talk-GB@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-gb

-- 
Diese Nachricht wurde von meinem Android-Mobiltelefon mit Kaiten Mail gesendet.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk-fr] JOSM assistant relation sans admin_centre

[Gaël Simon]

Merci Yves c’est parfait

Gaël

Le 5 juil. 2020 à 18:41, Yves P.  a écrit :


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

[OSM-talk-fr] JOSM assistant relation sans admin_centre

[Gaël Simon]

Bonjour,
Dans l’assistant de requête JOSM, comment puis-je récupérer les relations 
boundary qui n’ont pas de membre avec rôle admin_centre ?
Merci pour votre aide

Gaël
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Cycle Track - part/soft protection tags - proposal

[Simon Still]

Try this - description and photo of each type I’ve identified.  Most of these 
photos are London infra, many COVID emergency meausres

https://docs.google.com/document/d/1VL0MmHJoapd4JRgDhow0el2H06IJNsK-8KycxtWSaEw/edit?usp=sharing
 

 

You should be able to leave comments on that doc as well 



> On 16 Jun 2020, at 23:21, Mateusz Konieczny via Talk-GB 
>  wrote:
> 
> Do you have a photo of such feature?
> 
> https://i1.wp.com/bicilonatours.com/wp-content/uploads/2017/02/barcelona-cr-urgell.png
>  
> 
> link is dead
> 
> 

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

Re: [OSM-talk] Facebook acquires crowdsourced mapping company Mapillary

[Simon Poole]

Am 19.06.2020 um 13:47 schrieb Nick Whitelegg:
>
> (Disclaimer: I am the developer of said project)

One of the key functionalities required for such a project to be useable
in countries with developed privacy regulation is the ability to
automatically pixelate relevant parts of the images with a high degree
of reliability. It took Mapillary literally years to get that nailed
down and bring it to the level of functionality it is at now.


Which is one of the reasons why, way back when Mapillary started, I was
sceptical about the sustainability because the part of the product the
detection is required don't have a real associated revenue stream
(except if you a google, or ... and can use it in one way or the other
to sell ads).


In any case doing that from scratch would be a real pain. I believe the
OSC stack is now actually all OSS which would be a far better starting
point -if- sustainable funding could be built around the whole thing.


Simon


PS: naturally the whole reason for OSC was a business dispute that is
now moot because Mapillary is opening up its images for commercial use too.


>
> Those of you looking for 100% FOSS software and who are focused on 360
> degree photography of off-road routes (walking trails and so on) might
> want to consider OpenTrailView (https://opentrailview.org). Do bear in
> mind that it is in the early stages of development, so don't expect
> Mapillary-style UX just yet, and there is only a small amount of
> imagery (largely southern England at the moment plus a few around
> Heidelberg for probably obvious reasons) but it is in active
> development and I do have a possible collaboration with another
> project (more on that later).
>
> OpenTrailVIew also uses underlying OpenStreetMap data to auto-connect
> panoramas, using GeoJSON Path Finder
> (github.com/perliedman/geojson-path-finder), though, due to server
> capacity constraints, this only works at present in Europe and Turkey
> (though requests for other countries welcome, though note that if they
> are for large and/or highly-populated countries countries such as the
> USA, China or Brazil I would have to restrict it to a region).
>
> You can login using your OSM account.
>
> Nick
> 
> *From:* Florian Lohoff 
> *Sent:* 19 June 2020 07:58
> *To:* Niels Elgaard Larsen 
> *Cc:* talk@openstreetmap.org 
> *Subject:* Re: [OSM-talk] Facebook acquires crowdsourced mapping
> company Mapillary
>  
> On Fri, Jun 19, 2020 at 01:21:59AM +0200, Niels Elgaard Larsen wrote:
> > Paul Johnson:
> > > Great.  How's this affect those of us who trust Facebook about as
> far as we can throw it?
> >
> >
> > Use openstreetcam
>
> Openstreetcam is pretty much "disfunct" from my perspective. There are
> tons of bugs people opened because of their tracks not beeing
> processing. Same for me. Twitter feed dead for a year. It looks pretty
> much abandoned since end of 2019 - Since early June serious problems
> processing tracks and uploads.
>
> And for the me focus on Car driveable streets makes it useless.
>
> Flo
> -- 
> Florian Lohoff f...@zz.de
>     UTF-8 Test: The  ran after a , but the  ran away
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] COVID road changes

[Simon Still]

>Temporary and experimental traffic orders may include a date on which
>the expire or have to be reviewed, so that could perhaps be tagged?

>None of the orders which I have seen have explicitly mentioned Covid-19,
>but any suggestions about how to tag these would be useful.
A COVID-19 tag  - or  #StreetspaceLDN  StreetspaceLondon or some variation 
could also enable mapping that highlights the temporary infrastructure (I know 
there is interest in this within the cycling community) 

Best
Simon
(Didn’t receive original mail so apologies if this doesn’t thread)___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-GB] Cycle Track - part/soft protection tags - proposal

[Simon Still]

Full disclosure - I’m currently working for London Cycling Campaign on a 
project to bring data from the Transport For London Cycling Infrastructure 
Database to OSM.

As part of this the question arose as to how to tag cycle facilities that are 
give more protection and comfort than a painted lane on the road but not as 
much as a fully protected lane with, say, a 50cm concrete kerb separating 
cyclists from motor traffic. 

This was raised here - 

https://github.com/cyclestreets/tflcid-conversion/issues/23 


There are may types of ‘hybrid’, ‘partial, or ‘soft’ separation.  The London 
COVID-19 ‘StreetScape’ programme is bring a lot of this type of infrastructure 
to London’s streets very quickly.  Looking at OSM Wiki and previous discussions 
it doesn’t appear that there is a definitive way to record these. And indeed, 
looking at the recent infrastructure and how it has been entered to OSM by 
users it is not happening consistently as a result. 

My view on this is that the greatest distinction is between a painted lane and 
a track (that has some form of protection).  The difference between the 
different types of track is less than between no protection at all and 
’something’.  

Given the multitude of different ways of giving some protection to cyclists I 
wonder whether it is better to treat them all as variants of track (since they 
all offer much greater protection than a lane but vary in comfort level - in my 
view in this order of comfort).

cycleway:track=kerb
cycleway:track=rubber_kerb_wand
cycleway:track=rubber_kerb

cycleway:track=concrete_barrier
cycleway:track=plastic_barrier

cycleway:track=stepped
cycleway:track=wandorca
cycleway:track=wand
cycleway:track=orca



There may be more I've forgotten.

This would mean that routing engines would see either lane or track at the 
basic level, but the routing engine designer could then add further refinement 
using info about the type of track (in combination  perhaps with the size/speed 
of the road it was alongside) if that info was available.   The detail of the 
precise type of infra is relevant (rather than just simply tagging these with a 
generic tag such as ‘part protected’ or ‘hybrid’ since it may be that some 
types of infra prove more successful or have safety issues and there is a 
desire to identify locations where they are present (eg the concrete or water 
filed barriers prevent informal crossing of the road by pedestrians) 

Since this infra is being rolled out quickly and in volume (both in London and 
internationally - though London, due to the fragmented local authorities seems 
to be doing it in far more varied ways than other places) there is a benefit to 
establishing this now 

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

Re: [OSM-legal-talk] OSM Data in wikidata

[Simon Poole]

Am 16.06.2020 um 13:51 schrieb Martin Koppenhoefer:
> Am Di., 16. Juni 2020 um 13:32 Uhr schrieb Simon Poole  <mailto:si...@poole.ch>>:
>
> (not discussing if the material added is even protected
> to start with).
>
>
>
> As you are mentioning it, are you in doubt? By the substantial
> guideline it seems it would be covered by the ODbL:
> https://wiki.osmfoundation.org/wiki/Licence/Community_Guidelines/Substantial_-_Guideline

I'm simply making no assumptions about how the data got into wikidata,
for example the users may be contributing to both (OSM and WD).

Simon

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


signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk

Re: [OSM-legal-talk] OSM Data in wikidata

[Simon Poole]

Am 16.06.2020 um 13:13 schrieb Martin Koppenhoefer:
> 
>
> Provided that ODbL and OpenStreetMap would be sufficiently linked, is
> it then possible to copy OSM data into wikidata, which is distributed
> as CC0?
>
> 

As been pointed out many, many, many times (and it is not going to
change), CC0 explicitly does not cover third party rights in the
licensed material, just those of the entity distributing the work.

So adding information from OSM to Wikidata does not create a licence
conflict as such (not discussing if the material added is even protected
to start with).

Simon




signature.asc
Description: OpenPGP digital signature
___
legal-talk mailing list
legal-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/legal-talk