Re: [OSM-talk-be] Import of GPX files for marked trails in OSM / Import de traces GPX pour promenades balisées dans OSM

2020-08-19 Diskussionsfäden Matthieu Gaillet

Génial ! Count me in. J’ai l’expérience de ce genre de relation et suis donc 
opérationnel. 

Matthieu G.  (en mode mobile)

> Le 20 août 2020 à 07:46, Julien Minet  a écrit :
> 
> 
> Hello / Bonjour, 
> 
> Thanks to an active lobbying of Jacques Fondaire, contributor in Aubange, we 
> had the explicit right (well, an email) to use some GPX files from the local 
> tourism offices from the province of Luxembourg for completing the marked 
> trails in South-Luxembourg in OSM. We did not receive all the tracks yet but 
> in total there are about 120 walking marked trails in the Parc Naturel 
> Haute-Sure Forêt d'Anlier. 
> 
> This is not an automatic import since, to the best of my knowledge, there is 
> no automatic tool to convert some GPX into OSM relations. So we have to 
> manually add these relations based on the GPX information. From my 
> experience, it takes about 15 min. per relation to do so (in JOSM). I plan to 
> write a few lines about this import somewhere on the OSM wiki such as here. 
> 
> If anyone wants to help to enter this information in OSM, just let me know! 
> If you want to know how to add some marked trails in OSM, have a look at this 
> page and that one for Belgian specificities. A nice app rendering all these 
> routes is https://hiking.waymarkedtrails.org/. 
> 
> // en français //
> 
> Grâce à un lobbying actif de Jacques Fondaire, collaborateur à Aubange, nous 
> avons eu le droit explicite (enfin, un email) d'utiliser certains fichiers 
> GPX des offices de tourisme locaux de la province de Luxembourg pour 
> compléter les sentiers balisés du Sud-Luxembourg dans OSM. Nous n'avons pas 
> encore reçu tous les fichiers, mais il s'agit d'environ 120 pistes balisées 
> dans le Parc Naturel Haute-Sure Forêt d'Anlier. 
> 
> Il ne s'agit pas d'une importation automatique car, à ma connaissance, il 
> n'existe pas d'outil automatique permettant de convertir des GPX en relations 
> OSM. Nous devons donc ajouter manuellement ces relations sur la base des GPX. 
> D'après mon expérience, il faut environ 15 minutes par relation pour le faire 
> (dans JOSM). J'ai l'intention d'écrire quelques lignes sur cette importation 
> quelque part, par exemple ici. 
> 
> Si quelqu'un veut aider à saisir ces informations dans OSM, faites-le moi 
> savoir ! Si vous voulez savoir comment ajouter quelques pistes balisées dans 
> OSM, jetez un coup d'oeil à cette page et à celle-ci (spécificités belges). 
> Une belle application rendant tous ces parcours est 
> https://hiking.waymarkedtrails.org/. 
> 
> Happy mapping, 
> 
> juminet
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be


[OSM-talk-be] Import of GPX files for marked trails in OSM / Import de traces GPX pour promenades balisées dans OSM

2020-08-19 Diskussionsfäden Julien Minet
Hello / Bonjour,

Thanks to an active lobbying of Jacques Fondaire, contributor in Aubange,
we had the explicit right (well, an email) to use some GPX files from the
local tourism offices from the province of Luxembourg for completing the
marked trails in South-Luxembourg in OSM. We did not receive all the tracks
yet but in total there are about 120 walking marked trails in the Parc
Naturel Haute-Sure Forêt d'Anlier.

This is not an automatic import since, to the best of my knowledge, there
is no automatic tool to convert some GPX into OSM relations. So we have to
manually add these relations based on the GPX information. From my
experience, it takes about 15 min. per relation to do so (in JOSM). I plan
to write a few lines about this import somewhere on the OSM wiki such as
here
.


If anyone wants to help to enter this information in OSM, just let me know!
If you want to know how to add some marked trails in OSM, have a look at this
page  and that one

for Belgian specificities. A nice app rendering all these routes is
https://hiking.waymarkedtrails.org/.

// en français //

Grâce à un lobbying actif de Jacques Fondaire, collaborateur à Aubange,
nous avons eu le droit explicite (enfin, un email) d'utiliser certains
fichiers GPX des offices de tourisme locaux de la province de Luxembourg
pour compléter les sentiers balisés du Sud-Luxembourg dans OSM. Nous
n'avons pas encore reçu tous les fichiers, mais il s'agit d'environ 120
pistes balisées dans le Parc Naturel Haute-Sure Forêt d'Anlier.

Il ne s'agit pas d'une importation automatique car, à ma connaissance, il
n'existe pas d'outil automatique permettant de convertir des GPX en
relations OSM. Nous devons donc ajouter manuellement ces relations sur la
base des GPX. D'après mon expérience, il faut environ 15 minutes par
relation pour le faire (dans JOSM). J'ai l'intention d'écrire quelques
lignes sur cette importation quelque part, par exemple ici
.


Si quelqu'un veut aider à saisir ces informations dans OSM, faites-le moi
savoir ! Si vous voulez savoir comment ajouter quelques pistes balisées
dans OSM, jetez un coup d'oeil à cette page
 et à celle-ci

(spécificités belges). Une belle application rendant tous ces parcours est
https://hiking.waymarkedtrails.org/.

Happy mapping,

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


Re: [Talk-cr] Añadir alertas según CNE al mapa de OSM

2020-08-19 Diskussionsfäden Rodrigo
Etiqueté algunos cantones, pero el mapa no se puede visualizar.

En la wiki de Costa Rica no están todos los cantones del país.
Convendría agregar los enlaces a sus respectivas relaciones, pues ya
aparecen en la base de datos: https://overpass-turbo.eu/s/XdL

On 8/19/20 9:52 PM, Jaime Gutiérrez Alfaro wrote:
> Hola, espero que estén muy bien.
>
> Les quiero proponer que añadamos a los cantones (relaciones con
> `admin_level=6`) una etiqueta para indicar el estado de alerta de
> emergencia en la que están los cantones del país. Hoy en día este dato
> es muy útil pues según el nivel de alerta se establecen las medidas de
> restricción a la movilidad en vehículos automotores y la apertura de
> negocios.
>
> Sugiero usar la llave `alert:cne`, donde "cne" es acrónimo de Comisión
> Nacional de Emergencias, que es quien establece estas alertas. Los
> posibles valores que podría tener esta llave son: roja, naranja,
> amarilla y verde.
>
> Con esta propuesta podríamos hacer un mapa libre como
> [este](https://umap.openstreetmap.fr/en/map/mapa-de-alertas-cne-costa-rica_490621)
> que representa lo mismo que este [otro
> mapa](https://cnecr.maps.arcgis.com/apps/webappviewer/index.html?id=bc6c709b4fbd4929a725cb93e0a79436)
> privativo.
>
> A manera de ejemplo añadí la etiqueta y valores propuesta en dos
> cantones. el de Alajuela (alerta naranja) y Poás (alerta amarilla).
> Por eso en el mapa libre se pueden visualizar estos dos.
>
> Pura vida,
> Jaime.
>
> ___
> Talk-cr mailing list
> Talk-cr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cr
___
Talk-cr mailing list
Talk-cr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cr


[Talk-cr] Añadir alertas según CNE al mapa de OSM

2020-08-19 Diskussionsfäden Jaime Gutiérrez Alfaro
Hola, espero que estén muy bien.

Les quiero proponer que añadamos a los cantones (relaciones con
`admin_level=6`) una etiqueta para indicar el estado de alerta de
emergencia en la que están los cantones del país. Hoy en día este dato es
muy útil pues según el nivel de alerta se establecen las medidas de
restricción a la movilidad en vehículos automotores y la apertura de
negocios.

Sugiero usar la llave `alert:cne`, donde "cne" es acrónimo de Comisión
Nacional de Emergencias, que es quien establece estas alertas. Los posibles
valores que podría tener esta llave son: roja, naranja, amarilla y verde.

Con esta propuesta podríamos hacer un mapa libre como [este](
https://umap.openstreetmap.fr/en/map/mapa-de-alertas-cne-costa-rica_490621)
que representa lo mismo que este [otro mapa](
https://cnecr.maps.arcgis.com/apps/webappviewer/index.html?id=bc6c709b4fbd4929a725cb93e0a79436)
privativo.

A manera de ejemplo añadí la etiqueta y valores propuesta en dos cantones.
el de Alajuela (alerta naranja) y Poás (alerta amarilla). Por eso en el
mapa libre se pueden visualizar estos dos.

Pura vida,
Jaime.
___
Talk-cr mailing list
Talk-cr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cr


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

2020-08-19 Diskussionsfäden Andy Townsend


On 19/08/2020 22:44, Clifford Snow wrote:
...  Instead of suggesting their users edit OSM, they instead instruct 
them to email d...@openstreetmap.org ,



Indeed, and by the time they get to us they are usually "rabbits of 
negative euphoria"* because of the less than stellar support experience 
they've had at AllTrails.


Looking at e.g. 
https://www.alltrails.com/explore/list/yorkshire-wolds-way?b_tl_lat=54.06089919948305_tl_lng=-0.7765960693359375_br_lat=53.9918264806059_br_lng=-0.6293106079101562 
I'm not surprised - to my eyes that really is a crime against 
cartography.  Zoom in, and you'll see that that useful-looking 
north-south path just southeast of Thixendale is actually marked 
"(PRIVATE)", but at any scale you might want to plan a route on it isn't.


The explanation we have to give every time goes something along the 
lines of:


 * No, we're not Alltrails support, and can't directly affect the way
   that their map represents things.
 * Yes, it's perfectly normal for the OpenStreetMap database to include
   ways along which there is limited access (such as only the
   householder, or perhaps other people in an emergency).
 * Individual maps can choose what data to show and what not, and if a
   map does a poor job of it that's really not an OpenStreetMap problem.
 * While we'd love you to update OpenStreetMap yourself** (since you
   know your local area better than we do) we're more than happy to try
   and fix the OSM data if it's wrong - but we can't guarantee when (or
   even if) any particular OSM-based map will show the changes.

Best Regards,

Andy (from the Data Working Group)

* not a happy bunny

** I'd also, if it seems that it might help, try and introduce them to 
the local OSM community.



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


Re: [Talk-at] OSM AT Erreichbarkeit

2020-08-19 Diskussionsfäden Friedrich Volkmann

On 20.08.20 00:10, scubbx wrote:
Das Thema Local Chapter wird vom Verein seit ca. 2-3 Jahren immer wieder mal 
diskutiert. Auch dies hättest du bei jeder der öffentlichen Versammlungen 
mitbekommen können.


Ich fordere dich auf, die Verbreitung von Unwahrheiten zu unterlassen, 
genauso wie wilde Vermutungen von dir nicht als Tatsachen hinzustellen.


Wow. Dass dich mal jemand aus der Ruhe bringen kann!

Ich verstehe nicht, worum es in diesem Streit überhaupt geht. Soweit ich 
mich erinnern kann, und jetzt lese ich es auch im Wiki, wurde der Verein 
gegründet mit dem Zweck: "OpenStreetMap in Österreich fördern, die Community 
in Österreich unterstützen, Ansprechpartner für Behörden oder Sponsoren sein 
und insgesamt den Mappern in Österreich helfen".
Ich sehe nicht, was daran falsch sein kann – außer dass einige Leute im 
Verein ihre Freizeit dafür opfern.


Gestattet mir trotzdem eine Frage: Warum redet ihr immer von einem "local 
Chapter"? Wovon handelt dieses Kapitel, und in welcher Publikation soll es 
erscheinen? Schreibt ihr an einem Buch über OSM? Können wir dazu was beitragen?


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

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


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

2020-08-19 Diskussionsfäden Mike Thompson
I have already heard back from the CEO of AllTrails.  See his response
below.  They are going to fix the issue. I am impressed!

=
Thanks for the note, Mike. I know that this is going to sound lame but I
swear it's the truth, and that's that you found a bug on our website. There
should totally be an attribution block at the bottom and we'll get that
fixed up ASAP.

All the best,
Ron
=



On Wed, Aug 19, 2020 at 4:37 PM Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> On 20. Aug 2020, at 00:18, Mike Thompson  wrote:
>
> Thanks for the link where they mention OSM.  I did find their CEO on
> Linkedin, and just sent him this message:
>
>
>
> thank you! You may also consider adding them here:
> https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution
> to keep track of the case.
>
> Cheers Martin
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


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

2020-08-19 Diskussionsfäden Martin Koppenhoefer


sent from a phone

> On 20. Aug 2020, at 00:18, Mike Thompson  wrote:
> 
> Thanks for the link where they mention OSM.  I did find their CEO on 
> Linkedin, and just sent him this message:


thank you! You may also consider adding them here:
https://wiki.openstreetmap.org/wiki/Lacking_proper_attribution
to keep track of the case.

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


Re: [Talk-it] Nuovo stile di Google Maps

2020-08-19 Diskussionsfäden Martin Koppenhoefer


sent from a phone

> On 20. Aug 2020, at 00:20, totera  wrote:
> 
> Questo avrebbe potuto essere un punto di forza di OSM, e invece non abbiamo
> neanche una modalità univoca per mappare le strisce...


non fa niente, ne abbiamo 2-3, ma se vuoi fare una mappa non ti impedisce 
l’esistenza di più alternative di farla. Se pensi, google probabilmente deve 
gestire 100 modi diversi di taggare le strisce (perché usano tanti fonti 
diversi). 
Poi, sono al meno 10 anni che con ogni release dicono di aver migliorata la 
mappa per i pedoni, e che avranno più percorsi pedonali non accessibili in 
macchina (ma nella realtà sono sempre solo piccoli esercizi rispetto 
all’insieme dei percorsi).
Il loro vero punto di forza sono gli esercizi commerciali e altri POI, che in 
grandissimi numeri si autoinseriscono a gratis nella loro mappa, perché è il 
default (nonché i dati che gli utenti lasciano, utilizzando i loro sistemi).

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


Re: [Talk-it] Nuovo stile di Google Maps

2020-08-19 Diskussionsfäden totera
Federico Leva (Nemo) wrote
> https://www.ilpost.it/2020/08/19/google-maps-cambiera-un-po/

"Per quanto riguarda le città, Google ha spiegato di aver lavorato per
rendere più facile riconoscere aree e attraversamenti pedonali, così da
rendere più utile l’utilizzo delle mappe anche a chi si vuole spostare a
piedi."

Questo avrebbe potuto essere un punto di forza di OSM, e invece non abbiamo
neanche una modalità univoca per mappare le strisce...

Ciao,
Gianluca



--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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


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

2020-08-19 Diskussionsfäden Mike Thompson
Steve,

Thanks for the confirmation that the attribution is missing.  I will let
you, and the rest of the list, know if and when I hear from them.

Mike

On Wed, Aug 19, 2020 at 3:51 PM stevea  wrote:

> Thanks very much you two:  I've often meant to do something about
> alltrails' seeming / actual lack of attribution to OSM (if it exists, I
> haven't found it either) and something always seems to creep up and prevent
> me from taking action.  These are most assuredly "our" (OSM's / mine,
> others in OSM) data.  Yea:  let's get this ball rolling and a proper OSM
> attribution!
>
> SteveA
> California
>
> > On Aug 19, 2020, at 2: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,
> >
> > 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 
> 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
https://lists.openstreetmap.org/listinfo/talk


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

2020-08-19 Diskussionsfäden Mike Thompson
Clifford,

Thanks for the link where they mention OSM.  I did find their CEO on
Linkedin, and just sent him this message:

==

Hi Ron, I noticed that AllTrails uses OSM data for its trails on the
default "AllTrails Map Layer", while you mention this fact on your site[0],
I didn't see any attribution on the map itself crediting OSM.  The map
should have some text on it such as "Trail data © OpenStreetMap
contributors"[1]

Thanks

Mike

OSM Contributor Specializing in Trails

==


There are several other members of the AllTrails leadership team on
LinkedIn, you might want to reach out to them too.


Mike





[0]
https://support.alltrails.com/hc/en-us/articles/360018930672-How-do-I-update-or-change-information-about-a-trail-

[1] https://www.openstreetmap.org/copyright

On Wed, Aug 19, 2020 at 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,
>
> 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  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
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
>
> --
> @osm_washington
> www.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-at] OSM AT Erreichbarkeit

2020-08-19 Diskussionsfäden scubbx
Die Mitgliederversammlungen des OSM-AT Vereins waren immer öffentlich
und die darin diskutierte Finanzlage des Vereins genau so transparent
wie unbeeindruckend.
Das Thema Local Chapter wird vom Verein seit ca. 2-3 Jahren immer wieder
mal diskutiert. Auch dies hättest du bei jeder der öffentlichen
Versammlungen mitbekommen können.

Ich fordere dich auf, die Verbreitung von Unwahrheiten zu unterlassen,
genauso wie wilde Vermutungen von dir nicht als Tatsachen hinzustellen.

Mfg. Markus Mayr (ScubbX)


Am 19.08.20 um 23:44 schrieb Johann Haag:
> openstreetmap.at  tritt also ohne den Status
> eines local chapter innezuhaben, unter dem Namen von OpenStreetMap
> auf, und generiert definitiv daraus auch Einnahmen unbekannter Höhe.
> Der Betrieb der Website erfolgt offenkundig unzuverlässig. Ich finde
> man sollte das Recht unter dem Namen von OSM aufzutreten, besser an
> den Status eines local chapter knüpfen, solches schafft Vertrauen,
> Transparenz und auch Verbindlichkeit.
>
> Es wurde bisher sicher, z.B von Andreas bei diversen Veranstaltungen
> auch viel geleistete, openstreetmap benötigt aber mehr Professionalität.
>
> Mst. Johann Haag
>
>
>
>
> Am Mi., 19. Aug. 2020 um 18:14 Uhr schrieb Frederik Ramm
> mailto:frede...@remote.org>>:
>
> Hallo,
>
> On 19.08.20 17:58, Rudolf Mayer wrote:
> > Ich kann bei FOSSGIS auch nirgends sehen, dass sie auch Österreich
> > repräsentieren..
>
> Der FOSSGIS ist die Regional-Organisation ("Local Chapter") der OSGeo
> Foundation für die Region D-A-CH, aber bei OpenStreetMap ist der
> FOSSGIS
> ausschliesslich für Deutschland zuständig. Die Schweizer hatten schon
> lange vor dem FOSSGIS ihr eigenes anerkanntes OSMF-Local-Chapter, und
> der Verein openstreetmap.at  hat sich
> bislang meines Wissens nicht um
> diesen Status bemüht.
>
> Bye
> Frederik
>
> -- 
> Frederik Ramm  ##  eMail frede...@remote.org
>   ##  N49°00'09" E008°23'33"
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-at
>
>
>
> -- 
> Elektronikermeister Johann Haag
> Innsbruckerstraße 42
> 6380 St. Johann in Tirol
> ÖSTERREICH
> Tel: +43 664/174 7414
> Mailto:johannh...@hxg.at 
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


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

2020-08-19 Diskussionsfäden stevea
Thanks very much you two:  I've often meant to do something about alltrails' 
seeming / actual lack of attribution to OSM (if it exists, I haven't found it 
either) and something always seems to creep up and prevent me from taking 
action.  These are most assuredly "our" (OSM's / mine, others in OSM) data.  
Yea:  let's get this ball rolling and a proper OSM attribution!

SteveA
California

> On Aug 19, 2020, at 2: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, 
> 
> 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  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
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-it] Nuovo stile di Google Maps

2020-08-19 Diskussionsfäden Martin Koppenhoefer


sent from a phone

> On 19. Aug 2020, at 22:20, Federico Leva (Nemo)  wrote:
> 
> Piú contrasto, piú colori, piú dettagli... si può dire che Google Maps
> si avvicina al layer di base di osm.org?


vediamo come se lo cavano, avevo l’impressione che la loro mappa era diventata 
praticamente inutilizzabile (nei livelli di zoom di città o quartiere), per 
ottenere un senso dello spazio intendo, funzionava soltanto con un overlay di 
una rotta o dei POI, mentre cartograficamente la trovavo pessima (si capisce 
niente di una città). Potrei però avere un’immagine storta, perché non lo uso 
praticamente mai.
In generale abbiamo un vantaggio: non dobbiamo sacrificare la obiettività a 
favore di qualcuno che ci paga per essere visto di più rispetto a quel che si 
merita ;-)
(quello che loro chiamano “mappe individuali”)

Ciao Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it


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

2020-08-19 Diskussionsfäden Clifford Snow
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,

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


-- 
@osm_washington
www.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


Re: [Talk-at] OSM AT Erreichbarkeit

2020-08-19 Diskussionsfäden Johann Haag
openstreetmap.at tritt also ohne den Status eines local chapter
innezuhaben, unter dem Namen von OpenStreetMap auf, und generiert definitiv
daraus auch Einnahmen unbekannter Höhe. Der Betrieb der Website erfolgt
offenkundig unzuverlässig. Ich finde man sollte das Recht unter dem Namen
von OSM aufzutreten, besser an den Status eines local chapter knüpfen,
solches schafft Vertrauen, Transparenz und auch Verbindlichkeit.

Es wurde bisher sicher, z.B von Andreas bei diversen Veranstaltungen auch
viel geleistete, openstreetmap benötigt aber mehr Professionalität.

Mst. Johann Haag




Am Mi., 19. Aug. 2020 um 18:14 Uhr schrieb Frederik Ramm <
frede...@remote.org>:

> Hallo,
>
> On 19.08.20 17:58, Rudolf Mayer wrote:
> > Ich kann bei FOSSGIS auch nirgends sehen, dass sie auch Österreich
> > repräsentieren..
>
> Der FOSSGIS ist die Regional-Organisation ("Local Chapter") der OSGeo
> Foundation für die Region D-A-CH, aber bei OpenStreetMap ist der FOSSGIS
> ausschliesslich für Deutschland zuständig. Die Schweizer hatten schon
> lange vor dem FOSSGIS ihr eigenes anerkanntes OSMF-Local-Chapter, und
> der Verein openstreetmap.at hat sich bislang meines Wissens nicht um
> diesen Status bemüht.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


Re: [Talk-GB] Eat out to help out data

2020-08-19 Diskussionsfäden Kai Michael Poppe - OSM
Hey Rob,

if they made up their mind about the license 
(https://github.com/hmrc/eat-out-to-help-out-establishments/issues/3 - Apache 
2.0 is software, not data) the ~100 entries with wrong postcode data 
(https://github.com/hmrc/eat-out-to-help-out-establishments/issues/18) out of 
62k entries would be ok.

But yeah, it would be great to have some very recent establishment data.

Grouping the Postcodes, there are
  38,563 unique postcodes (62.1 % of entries)
   6,326 pcs occur twice  (20.1 %)
   1,800 pcs occur thrice  (8.7 %)
 611 four times(3.9 %)
 214 five times(1.7 %)
...
checking those data against the FHRS-OpenData would be relatively easy and very 
quick to implement and would allow for 96.5% of the entries to be checked. Once 
one has the FHRS data finding an appropriate OSM object becomes easier.

Someone™ would have to do the coding and once licensing and usage are clear, 
the data could be used :-)

Kai

On 19.08.2020 22:10, Rob Nickerson wrote:
> Hi all,
> 
> Anyone considered using the Eat out to Help out data that HMRC have published 
> to aid with mapping efforts?
> 
> https://github.com/hmrc/eat-out-to-help-out-establishments
> 
> Prior to this, there was a scraper that collated the data:
> https://github.com/svenlatham/eatout-scraper
> 
> Thank you,
> *Rob*
> 
> ___
> 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-it] Nuovo stile di Google Maps

2020-08-19 Diskussionsfäden Federico Leva (Nemo)
https://www.ilpost.it/2020/08/19/google-maps-cambiera-un-po/

Piú contrasto, piú colori, piú dettagli... si può dire che Google Maps
si avvicina al layer di base di osm.org? Rivalutare il minimalismo a
tutti i costi sicuramente non guasta.

Federico

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


[Talk-GB] Eat out to help out data

2020-08-19 Diskussionsfäden Rob Nickerson
Hi all,

Anyone considered using the Eat out to Help out data that HMRC have
published to aid with mapping efforts?

https://github.com/hmrc/eat-out-to-help-out-establishments

Prior to this, there was a scraper that collated the data:
https://github.com/svenlatham/eatout-scraper

Thank you,
*Rob*
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


[OSM-talk] Use of OSM data without attribution

2020-08-19 Diskussionsfäden Mike Thompson
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
https://lists.openstreetmap.org/listinfo/talk


Re: [OSM-talk-fr] Diagramme de transport publique

2020-08-19 Diskussionsfäden Gad.Jo

Je pense avoir trouvé... il y a un brin par horaire

J'ai fait un essais sur la ligne 22 avec deux relations supplémentaire 
avec des horaires et ça commence à rendre quelques choses de similaire : 
https://overpass-api.de/api/sketch-line?ref=22=Citibus


Le 19/08/2020 à 21:21, Gad.Jo a écrit :

J'ai oublié de partager le lien vers le diagramme qui me poste question

Celui qui fonctionne bien : 
https://overpass-api.de/api/sketch-line?ref=10=Libero
Celui dont je ne comprend pas le rendu : 
https://overpass-api.de/api/sketch-line?ref=15=Citibus


Pouvez-vous m'indiquer ce qui ne va pas sur la relation 
https://www.openstreetmap.org/relation/6743131



Le 18/08/2020 à 17:09, Percherie OnDaNet a écrit :

Bonjour,


Je suis en train de finaliser le réseau de transport en commun sur 
Narbonne (hors transport scolaire) et je cherche à faire afficher les 
diagrammes de chaque ligne de la même façon que sur 
https://overpass-api.de/api/sketch-line?ref=10=Libero


Sur la relation route_master n° 4113572 à Bern (Suisse) : 
https://www.openstreetmap.org/relation/4113572
le diagramme fonctionne tel quel avec un brin pour chaque sens car 
les arrêts ne sont pas identique à l'aller et au retour.


Sur la relation route_master n° 6743131 à Narbonne (France) : 
https://www.openstreetmap.org/relation/6743131
le diagramme ne s'affiche pas de la même manière, je m'attendait à 
voir un brin pour chaque sens départ/terminus


J'ai quelques essais infructueux via le formulaire disponible sur 
https://overpass-api.de/public_transport.html mais sans succès.


Comment faire en sorte pour que la relation présente de la ligne 15 
sur Narbonne affiche un diagramme similaire à celui de la ligne 10 
sur Bern (Suisse) ?



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


Re: [OSM-talk-fr] Diagramme de transport publique

2020-08-19 Diskussionsfäden Gad.Jo

J'ai oublié de partager le lien vers le diagramme qui me poste question

Celui qui fonctionne bien : 
https://overpass-api.de/api/sketch-line?ref=10=Libero
Celui dont je ne comprend pas le rendu : 
https://overpass-api.de/api/sketch-line?ref=15=Citibus


Pouvez-vous m'indiquer ce qui ne va pas sur la relation 
https://www.openstreetmap.org/relation/6743131



Le 18/08/2020 à 17:09, Percherie OnDaNet a écrit :

Bonjour,


Je suis en train de finaliser le réseau de transport en commun sur 
Narbonne (hors transport scolaire) et je cherche à faire afficher les 
diagrammes de chaque ligne de la même façon que sur 
https://overpass-api.de/api/sketch-line?ref=10=Libero


Sur la relation route_master n° 4113572 à Bern (Suisse) : 
https://www.openstreetmap.org/relation/4113572
le diagramme fonctionne tel quel avec un brin pour chaque sens car les 
arrêts ne sont pas identique à l'aller et au retour.


Sur la relation route_master n° 6743131 à Narbonne (France) : 
https://www.openstreetmap.org/relation/6743131
le diagramme ne s'affiche pas de la même manière, je m'attendait à 
voir un brin pour chaque sens départ/terminus


J'ai quelques essais infructueux via le formulaire disponible sur 
https://overpass-api.de/public_transport.html mais sans succès.


Comment faire en sorte pour que la relation présente de la ligne 15 
sur Narbonne affiche un diagramme similaire à celui de la ligne 10 sur 
Bern (Suisse) ?



___
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-at] OSM AT Erreichbarkeit

2020-08-19 Diskussionsfäden nine-osm . org-lists

Hallo liebe Leute,

die Mailing-Liste  sehe ich wie alle weiteren 
offiziellen Openstreetmap.org Mailinglisten mit voller Berechtigung.


Übersicht über Openstreetmap.org Mailinglisten:
https://wiki.openstreetmap.org/wiki/Mailing_lists

Beste Grüße aus der Steiermark,
Erwin


On 8/17/20 8:13 PM, Johann Haag wrote:

Hallo Andreas,
Du verstehst mich völlig falsch, jede Mitarbeit von Freiwilligen ist zu 
unterstützen,
Löst dazu bitte einfach das talk mail Konstrukt auf, und arbeitet 
transparent unter einer OSM Identität im Webforum mit.
Spenden sind dem local chapter FOSSGIS zuzuweisen, dieser schüttet 
sicher projektbezogene Gelder wieder aus.


Wer unter dem Namen von OpenStreetMap agiert, muss hierbei auf 
weitestgehende Transparenz achten, und darf auch bei leiser Kritik nicht 
derart zimperlich reagieren, sondern hat seine Gebarung umfassend 
offenzulegen.


Mst. Johann Haag

Am 17.08.2020 um 19:35 schrieb Andreas via Talk-at 
mailto:talk-at@openstreetmap.org>>:


Am 16.08.20 um 23:15 schrieb Johann Haag:



Am 16.08.2020 um 22:39 schrieb scubbx 

>:

Der Österreichische Verrein hat die Kappen 2014 produziert, um die es
in der Anfrage von Simon Poole geht.
An wen hätte er sich sonst wenden sollen?




Man gründe also also einen Hobby Verein, genannt OpenStreetMap-Tirol,
gemeinnützigen Statuten Ehrensache. Dazu Tiroler OSM Kapperl. Einnahmen
nur im Umfang was wir auch tatsächlich ausgeben, keine Kunst. Fechten
nicht beim BEV und Gemeindebund, sondern aussschließlich bei Tiroler
Touristikern, wir sind ja gemeinnützig.
Künftig sämtliche OSM Belange mit Tirol Bezug an uns senden, garantierte
Reaktionszeit mal schauen (wir haben ja auch noch ganz viel anderes zu
tun), spätestens jedoch zur gesetzlich verpflichtend vorgeschriebenen
Jahreshauptversammlung.



Unglaublich wie du die Arbeit für OSM von Freiwilligen in den Schmutz
ziehst.OSM.at macht mehr als nur OSM-Kapperl. Wärst du 
in den letzten

Jahren auf einer Geo-Veranstaltung in Österreich gewesen, hättest du
dich persönlich an unserem Stand informieren können.

Mitglieder des Vereins nehmen teil an:
- AGIT
- Makerfaire Vienna
- Linuxtage / -wochen
- OSM Stammtische
- Mapathons

um nur ein paar der Veranstaltungen zu nennen. Im Gegensatz zu dir
versuchen wir mit anderen OSM Mappern oder Begeisterten in Kontakt zu
treten. Wir spielen uns nicht auf, dass wir die einzigen sind, die sich
um OSM kümmern.

Ich bitte daher in Zukunft auf Mails in dieser Form zu verzichten und
informiere dich bevor du unqualifiziert und unbelegte Behauptungen von
dir gibst.

Danke
Andreas


Grüsse, Mst. Johann Haag



Am 16.08.20 um 19:56 schrieb Johann Haag:



Am 16.08.2020 um 15:38 schrieb scubbx >:




Der Österreichische Verrein hat die Kappen 2014 produziert, um die
es in der Anfrage von Simon Poole geht.
An wen hätte er sich sonst wenden sollen?


Wie hat der Wiener Verein das finanziert, laut Statuten gibt es ja
keine Einnahmen. Ich möchte diesem Verein nun nichts unterstellen.
Hier gehört aber wesentlich mehr Transparenz hinein. OSM ist
inzwischen ein Ferrari.

Grüsse Mst. Johann Haag



Am 16.08.20 um 13:57 schrieb Johann Haag:

Österreich kann sich ja um eine eigene offizielle OpenStreetMap
Vertretung bemühen,
mir wurde vom Wiener Verein mitgeteilt, dass dieser nur eine lose
Vereinigung sei.
Sofern der Wiener Verein für offizielle Belange auf die Fossgis,
unseren local chapter verweist, sehe ich auch kein Problem. Eine
solche Erklärung fehlt aber auf dessen Webseite openstreetmap.at 



Wenn sich nun Simon Poole für offizielles,
https://lists.openstreetmap.org/pipermail/talk-at/2020-August/010645.html
an den Wiener Verein wendet, dann finde ich das ganz einfach falsch.
Der Wiener Verein hat aktuell nicht mehr Mandat als jeder andere
OSM- Stammtisch in Österreich.

Grüsse Mst. Johann Haag




Am 16.08.2020 um 10:40 schrieb Kevin Kofler
>:


Johann Haag wrote:

Es ist längst an der Zeit, dass man den Wiener Verein aus der Liste
https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters

entfernt,
und den Domainopenstreetmap.at 
>

 mit
openstreetmap.de 
>

 zusammenführt.


Wieso soll Österreich von Deutschland aus verwaltet werden?
Österreich ist
ein unabhängiges Land und kein Teil von Deutschland! (Und die
kurze Zeit, in
der das anders war, wünscht sich hoffentlich keiner hier zurück!)

   Kevin Kofler


___
Talk-at mailing list
Talk-at@openstreetmap.org 



Re: [Talk-at] OSM AT Erreichbarkeit

2020-08-19 Diskussionsfäden Frederik Ramm
Hallo,

On 19.08.20 17:58, Rudolf Mayer wrote:
> Ich kann bei FOSSGIS auch nirgends sehen, dass sie auch Österreich
> repräsentieren..

Der FOSSGIS ist die Regional-Organisation ("Local Chapter") der OSGeo
Foundation für die Region D-A-CH, aber bei OpenStreetMap ist der FOSSGIS
ausschliesslich für Deutschland zuständig. Die Schweizer hatten schon
lange vor dem FOSSGIS ihr eigenes anerkanntes OSMF-Local-Chapter, und
der Verein openstreetmap.at hat sich bislang meines Wissens nicht um
diesen Status bemüht.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Robert Whittaker (OSM lists)
On Wed, 19 Aug 2020 at 15:36, SK53  wrote:
> This isn't necessarily true. If you open any OS Open Data product in QGIS one 
> is now confronted by a bewildering array of ways of converting from the OSGB 
> national grid co-ordinates to WGS84.
>
> The optimum one currently uses the 2015 file of detailed offset corrections 
> to the basic projection transformation. There was an earlier set of similar 
> data released in 2002. If one doesn't download this correction data then it 
> falls back on the basic transform using OSGB36 which can be anywhere between 
> 1 and 5 m off-true. In addition there has always been the slightly obscure 
> behaviour of OSGB projections specified in proj4 or WKT formats with respect 
> to the Helmert Transformation parameters (in early days of Open Data Chris 
> Hill & I found these were essential). At least part of the problem is that 
> EPSG:27700 appears to relate to several very slightly diverging projections, 
> whereas, for instance, Irish Grid changes are handled by EPSG:29001 through 
> EPSG:29003, and Swiss Grid CH1903 is EPSG:4149, CH1903+ is EPSG:4150 and the 
> newest CH1903+/LV95 is EPSG:2096.
>
> I don't know what transformation JOSM uses when reading EPSG:27700 so unless 
> one is very cautious it is not possible to be certain that one is anywhere 
> near the RMS 25 cm accuracy of OS data (especially as products, including 
> Boundary Line, may be partially generalised.

Perhaps this is what's causing the following problem for me then. I
GPS-surveyed a lot of the roads on my estate a few years ago when
aerial imagery wasn't so good. I've got GPS traces in OSM that
consistently follow the pavements on each side of the road and will
line up nicely with the aerial imagery if you put in the right
off-set. However, the required off-set for these traces is around 3m
out from the offset you need to make the OS OpenMap Local Functional
sites (as suggested above) line up, when I load the shapefile directly
in JOSM. This ~3m is very noticable when you have mapped buildings and
pavements sticking out into roads.

Perhaps it would be useful if someone could to do a correct
transformation of (e.g.) the OS OpenMap Local Functional Sites data to
a format and CRS that can be unambiguously read by JOSM, in order to
help our imagery alignment.

Robert.

-- 
Robert Whittaker

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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden 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-at] OSM AT Erreichbarkeit

2020-08-19 Diskussionsfäden Rudolf Mayer

Hallo,

On 19/08/2020 17:29, Johann Haag wrote:



Am Mi., 19. Aug. 2020 um 14:18 Uhr schrieb Kevin Kofler 
mailto:kevin.kof...@chello.at>>:


Johann Haag wrote:
 > Wiener Verein
[…]
 > Wiener Verein
[…]
 > Wiener Verein
[…]
 > Wiener Verein


Ist das Thema local chapter, wirklich derart schwer zu verstehen?
https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters
Österreichs Local Chapter ist aktuell https://www.fossgis.de/



Ich habe nicht wirklich eine Ahnung von den Local Chapters, aber woher 
nimmst du die info, dass FOSSGIS für Österreich repräsentativ zuständig ist?



Wenn sich da ein selbsternannter Verein



Jeder Verein ist selbsternannt.

wichtig macht, in Realität dann 
nach belieben mal da, und dann wieder mal weg ist, dann darf man 
berechtigte Zweifel an dessen Befugnissen anmelden.

Für Wünsche und Beschwerden, auch für Spenden und Spendenquittungen



Ich habe echt keine Ahnung woher dein Faible für Spenden kommt..
Hast Du diese so nötig für Deine Mapping Aktivitäten? Oder was ist hier 
der springende Punkt? Millionen von Novomatic bekommen? :-)


, ist 
alleinig der Fossgis Verein zuständig.
  Wenn unser local chapter Fossgis meint, man können openstreetmap.at 
 vertrauen, dann soll bitte Fossgis für AT 
spezifische Spenden die Kontonummer des Österreichischen Vereins 
angeben. Ich kann diese aber bei Fossgis nicht finden.



Ich kann bei FOSSGIS auch nirgends sehen, dass sie auch Österreich 
repräsentieren..


Lg
Rudi

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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Silent Spike
I contribute a bit to the development of iD and have interacted with the
current lead developer (who's currently not funded to work on it full time
anymore) as well as the previous (who's moved on to RapiD) numerous times.
As it's open source software my suggestion would be to interface using the
development channels of Github (open an issue ticket concerning supporting
the offset DB, or comment on the existing one if there is one) rather than
approaching anyone in particular. This way there is a documented place for
continued/historic open discussion.

It is unlikely you will see quick movement on this though unless someone
takes on the challenge themselves (the benefit of open source - and how
I've made additions to the software in the past). The community itself has
a responsibility to contribute to and develop open source tools if they
don't meet our needs/wants.

On Wed, Aug 19, 2020 at 4:23 PM Stephen Colebourne 
wrote:

> I'm glad I started a discussion, even if there aren't any real answers. It
> is going to be an increasing problem I fear and one I think OSM needs
> a solid answer to.
>
> In SW London, I've just checked against "OS OpenData StreetView" and all
> my edits (and thus Esri World Clarity Beta) all match pretty much exactly.
> The imported boundary data is less clear, but again it favours the current
> data where I can actually determine a difference. So. I do think Bing is
> out.
>
> Does anyone have any contacts with iD developers? From reading their
> threads it seems like they want to design a brand new perfect system from
> scratch, rather than adopt the offset DB. Since JOSM is generally more
> savvy users, it is iD I care more about.
>
> I'll contact the Amazon mapper and see if I get anywhere...
>
> Stephen
>
>
>
> On Wed, 19 Aug 2020 at 16:00, Colin Smale  wrote:
> >
> > At least it sounds soluble. Given the right transform and corrections a
> "definitive" OS point in Easting/Northing format can be translated
> accurately to WGS84 lat/long. However you look at it, I would expect a
> purely mathematical transformation should have less error than a
> transformation involving "tracing" from imagery whose rectification has
> probably also involved some of these transformations each with their own
> error terms. But I suppose that it at least partly depends on your
> definition of "perfection."
> >
> >
> >
> >
> > On 2020-08-19 16:34, SK53 wrote:
> >
> > This isn't necessarily true. If you open any OS Open Data product in
> QGIS one is now confronted by a bewildering array of ways of converting
> from the OSGB national grid co-ordinates to WGS84.
> >
> > The optimum one currently uses the 2015 file of detailed offset
> corrections to the basic projection transformation. There was an earlier
> set of similar data released in 2002. If one doesn't download this
> correction data then it falls back on the basic transform using OSGB36
> which can be anywhere between 1 and 5 m off-true. In addition there has
> always been the slightly obscure behaviour of OSGB projections specified in
> proj4 or WKT formats with respect to the Helmert Transformation parameters
> (in early days of Open Data Chris Hill & I found these were essential). At
> least part of the problem is that EPSG:27700 appears to relate to several
> very slightly diverging projections, whereas, for instance, Irish Grid
> changes are handled by EPSG:29001 through EPSG:29003, and Swiss Grid CH1903
> is EPSG:4149, CH1903+ is EPSG:4150 and the newest CH1903+/LV95 is EPSG:2096.
> >
> > I don't know what transformation JOSM uses when reading EPSG:27700 so
> unless one is very cautious it is not possible to be certain that one is
> anywhere near the RMS 25 cm accuracy of OS data (especially as products,
> including Boundary Line, may be partially generalised.
> >
> > Like Jass I've been looking at various data sets which can be pulled
> into editors to help with alignment. I initially used OS Open Roads, but
> this is just too generalised to be usable in many areas. Larger buildings
> from OS Open Local, although generalised, will often have corners in the
> right place. Perhaps what we need is an equivalent of TIGER Line as a GB
> specific overlay layer showing selected alignment friendly features from
> either OS Local or Vector Map. If we could borrow styling from either TIGER
> Line or the US Forest roads it might be feasible to make such a layer.
> >
> > Jerry
> >
> > On Wed, 19 Aug 2020 at 13:58, Colin Smale  wrote:
> >>
> >> On 2020-08-19 12:17, Andy Townsend wrote:
> >>
> >> On 19/08/2020 10:11, Stephen Colebourne wrote: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
> >> If that's happening at all, please comment on the changeset explaining
> the problem.  In English urban areas OS OpenData StreetView is 

Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Colin Smale
On 2020-08-19 17:21, Russ Garrett wrote:

> On Wed, 19 Aug 2020 at 16:00, Colin Smale  wrote: 
> 
>> At least it sounds soluble. Given the right transform and corrections a 
>> "definitive" OS point in Easting/Northing format can be translated 
>> accurately to WGS84 lat/long. However you look at it, I would expect a 
>> purely mathematical transformation should have less error than a 
>> transformation involving "tracing" from imagery whose rectification has 
>> probably also involved some of these transformations each with their own 
>> error terms. But I suppose that it at least partly depends on your 
>> definition of "perfection."
> 
> Well, that assumes that OS's locations are perfect, and that their
> data isn't subject to orthorectification errors and the like. It's
> still likely to be better than any other source, but I'd be surprised
> if there weren't similar errors in some of the OS data, especially in
> more rural & hilly areas.

Agree with this. 

Here's a thought: I doubt the OS use equipment that reads out directly
in OSGB36. I would think it it more likely that their equipment provides
(e.g.) WGS84 data which is then converted to OSGB36 before storing it in
the MasterMap database? I wonder what transformation errors are
introduced at that stage. If we reverse that transformation exactly, we
should arrive at the data as originally captured. 

> In my experience, once you start trying to go below 5m accuracy you
> swiftly learn not to trust anyone.

I can understand that, but it is not helping us forward... We need to
trust someone/something unless we think we can do better ourselves. I
tend to regard the OS as "sufficiently trustworthy" from my perspective
as a reasonably technically, mathematically competent person without any
specific inside knowledge of the OS. So if the OS say it's at {x,y} and
some other source says {x',y'} then I would presume that the OS is more
likely to be correct, and the other source would have to show me a damn
good provenance if it wants me to consider it better than the OS (and
thereby prompt me to move some feature in OSM).___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden David Woolley

On 19/08/2020 16:21, Russ Garrett wrote:

5m accuracy


You'll accumulate that error in a couple of centuries, just from 
continental drift: 
, 
given that OSM is referenced to WGS-84, not the British mainland.


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


Re: [Talk-at] OSM AT Erreichbarkeit

2020-08-19 Diskussionsfäden Johann Haag
Am Mi., 19. Aug. 2020 um 14:18 Uhr schrieb Kevin Kofler <
kevin.kof...@chello.at>:

> Johann Haag wrote:
> > Wiener Verein
> […]
> > Wiener Verein
> […]
> > Wiener Verein
> […]
> > Wiener Verein
>

Ist das Thema local chapter, wirklich derart schwer zu verstehen?
https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters
Österreichs Local Chapter ist aktuell https://www.fossgis.de/

Wenn sich da ein selbsternannter Verein wichtig macht, in Realität dann
nach belieben mal da, und dann wieder mal weg ist, dann darf man
berechtigte Zweifel an dessen Befugnissen anmelden.
Für Wünsche und Beschwerden, auch für Spenden und Spendenquittungen, ist
alleinig der Fossgis Verein zuständig.
 Wenn unser local chapter Fossgis meint, man können openstreetmap.at
vertrauen, dann soll bitte Fossgis für AT spezifische Spenden die
Kontonummer des Österreichischen Vereins angeben. Ich kann diese aber bei
Fossgis nicht finden.

Grüsse Mst. Johann Haag

>
> Ah, daher weht also der Wind, das "gute alte" Wien-Bashing…
>
> Kevin Kofler
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
>


-- 
Elektronikermeister Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannh...@hxg.at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Stephen Colebourne
I'm glad I started a discussion, even if there aren't any real answers. It
is going to be an increasing problem I fear and one I think OSM needs
a solid answer to.

In SW London, I've just checked against "OS OpenData StreetView" and all my
edits (and thus Esri World Clarity Beta) all match pretty much exactly. The
imported boundary data is less clear, but again it favours the current data
where I can actually determine a difference. So. I do think Bing is out.

Does anyone have any contacts with iD developers? From reading their
threads it seems like they want to design a brand new perfect system from
scratch, rather than adopt the offset DB. Since JOSM is generally more
savvy users, it is iD I care more about.

I'll contact the Amazon mapper and see if I get anywhere...

Stephen



On Wed, 19 Aug 2020 at 16:00, Colin Smale  wrote:
>
> At least it sounds soluble. Given the right transform and corrections a
"definitive" OS point in Easting/Northing format can be translated
accurately to WGS84 lat/long. However you look at it, I would expect a
purely mathematical transformation should have less error than a
transformation involving "tracing" from imagery whose rectification has
probably also involved some of these transformations each with their own
error terms. But I suppose that it at least partly depends on your
definition of "perfection."
>
>
>
>
> On 2020-08-19 16:34, SK53 wrote:
>
> This isn't necessarily true. If you open any OS Open Data product in QGIS
one is now confronted by a bewildering array of ways of converting from the
OSGB national grid co-ordinates to WGS84.
>
> The optimum one currently uses the 2015 file of detailed offset
corrections to the basic projection transformation. There was an earlier
set of similar data released in 2002. If one doesn't download this
correction data then it falls back on the basic transform using OSGB36
which can be anywhere between 1 and 5 m off-true. In addition there has
always been the slightly obscure behaviour of OSGB projections specified in
proj4 or WKT formats with respect to the Helmert Transformation parameters
(in early days of Open Data Chris Hill & I found these were essential). At
least part of the problem is that EPSG:27700 appears to relate to several
very slightly diverging projections, whereas, for instance, Irish Grid
changes are handled by EPSG:29001 through EPSG:29003, and Swiss Grid CH1903
is EPSG:4149, CH1903+ is EPSG:4150 and the newest CH1903+/LV95 is EPSG:2096.
>
> I don't know what transformation JOSM uses when reading EPSG:27700 so
unless one is very cautious it is not possible to be certain that one is
anywhere near the RMS 25 cm accuracy of OS data (especially as products,
including Boundary Line, may be partially generalised.
>
> Like Jass I've been looking at various data sets which can be pulled into
editors to help with alignment. I initially used OS Open Roads, but this is
just too generalised to be usable in many areas. Larger buildings from OS
Open Local, although generalised, will often have corners in the right
place. Perhaps what we need is an equivalent of TIGER Line as a GB specific
overlay layer showing selected alignment friendly features from either OS
Local or Vector Map. If we could borrow styling from either TIGER Line or
the US Forest roads it might be feasible to make such a layer.
>
> Jerry
>
> On Wed, 19 Aug 2020 at 13:58, Colin Smale  wrote:
>>
>> On 2020-08-19 12:17, Andy Townsend wrote:
>>
>> On 19/08/2020 10:11, Stephen Colebourne wrote: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
>> If that's happening at all, please comment on the changeset explaining
the problem.  In English urban areas OS OpenData StreetView is a pretty
good guide for alignment and if people (especially people doing a lot of
editing) are not taking into account different imagery offsets then that's
just wrong.
>>
>> Possibly even better that StreetView imagery is data that has been
imported directly from OS, such as OS Boundary-Line for the admin
boundaries. This is probably the closest we can get to cm-level accuracy -
even though they don't give us the full resolution, the base points such as
tripoints where boundaries meet are likely to be pretty damn accurate. I
would recommend using these as a kind of calibration point to sanity-check
imagery alignment and other data based on less accurate GPS positioning
(e.g. from any consumer-grade GPS kit).
>>
>> ___
>> 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 

Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Russ Garrett
On Wed, 19 Aug 2020 at 16:00, Colin Smale  wrote:
> At least it sounds soluble. Given the right transform and corrections a 
> "definitive" OS point in Easting/Northing format can be translated accurately 
> to WGS84 lat/long. However you look at it, I would expect a purely 
> mathematical transformation should have less error than a transformation 
> involving "tracing" from imagery whose rectification has probably also 
> involved some of these transformations each with their own error terms. But I 
> suppose that it at least partly depends on your definition of "perfection."

Well, that assumes that OS's locations are perfect, and that their
data isn't subject to orthorectification errors and the like. It's
still likely to be better than any other source, but I'd be surprised
if there weren't similar errors in some of the OS data, especially in
more rural & hilly areas.

In my experience, once you start trying to go below 5m accuracy you
swiftly learn not to trust anyone.

Cheers,

-- 
Russ Garrett
r...@garrett.co.uk

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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Colin Smale
At least it sounds soluble. Given the right transform and corrections a
"definitive" OS point in Easting/Northing format can be translated
accurately to WGS84 lat/long. However you look at it, I would expect a
purely mathematical transformation should have less error than a
transformation involving "tracing" from imagery whose rectification has
probably also involved some of these transformations each with their own
error terms. But I suppose that it at least partly depends on your
definition of "perfection."

On 2020-08-19 16:34, SK53 wrote:

> This isn't necessarily true. If you open any OS Open Data product in QGIS one 
> is now confronted by a bewildering array of ways of converting from the OSGB 
> national grid co-ordinates to WGS84. 
> 
> The optimum one currently uses the 2015 file of detailed offset corrections 
> to the basic projection transformation. There was an earlier set of similar 
> data released in 2002. If one doesn't download this correction data then it 
> falls back on the basic transform using OSGB36 which can be anywhere between 
> 1 and 5 m off-true. In addition there has always been the slightly obscure 
> behaviour of OSGB projections specified in proj4 or WKT formats with respect 
> to the Helmert Transformation parameters (in early days of Open Data Chris 
> Hill & I found these were essential). At least part of the problem is that 
> EPSG:27700 appears to relate to several very slightly diverging projections, 
> whereas, for instance, Irish Grid changes are handled by EPSG:29001 through 
> EPSG:29003, and Swiss Grid CH1903 is EPSG:4149, CH1903+ is EPSG:4150 and the 
> newest CH1903+/LV95 is EPSG:2096.
> 
> I don't know what transformation JOSM uses when reading EPSG:27700 so unless 
> one is very cautious it is not possible to be certain that one is anywhere 
> near the RMS 25 cm accuracy of OS data (especially as products, including 
> Boundary Line, may be partially generalised. 
> 
> Like Jass I've been looking at various data sets which can be pulled into 
> editors to help with alignment. I initially used OS Open Roads, but this is 
> just too generalised to be usable in many areas. Larger buildings from OS 
> Open Local, although generalised, will often have corners in the right place. 
> Perhaps what we need is an equivalent of TIGER Line as a GB specific overlay 
> layer showing selected alignment friendly features from either OS Local or 
> Vector Map. If we could borrow styling from either TIGER Line or the US 
> Forest roads it might be feasible to make such a layer. 
> 
> Jerry 
> 
> On Wed, 19 Aug 2020 at 13:58, Colin Smale  wrote: 
> 
> On 2020-08-19 12:17, Andy Townsend wrote: 
> On 19/08/2020 10:11, Stephen Colebourne wrote: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
> If that's happening at all, please comment on the changeset explaining the 
> problem.  In English urban areas OS OpenData StreetView is a pretty good 
> guide for alignment and if people (especially people doing a lot of editing) 
> are not taking into account different imagery offsets then that's just wrong. 
> Possibly even better that StreetView imagery is data that has been imported 
> directly from OS, such as OS Boundary-Line for the admin boundaries. This is 
> probably the closest we can get to cm-level accuracy - even though they don't 
> give us the full resolution, the base points such as tripoints where 
> boundaries meet are likely to be pretty damn accurate. I would recommend 
> using these as a kind of calibration point to sanity-check imagery alignment 
> and other data based on less accurate GPS positioning (e.g. from any 
> consumer-grade GPS kit). 
> ___
> 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] New Bing Imagery

2020-08-19 Diskussionsfäden Alan Mackie
On Wed, 19 Aug 2020 at 14:52, Jass Kurn  wrote:

>
> On Wed, 19 Aug 2020 at 13:58, Colin Smale  wrote:
>
>> Possibly even better that StreetView imagery is data that has been
>> imported directly from OS, such as OS Boundary-Line for the admin
>> boundaries. This is probably the closest we can get to cm-level accuracy -
>> even though they don't give us the full resolution, the base points such as
>> tripoints where boundaries meet are likely to be pretty damn accurate. I
>> would recommend using these as a kind of calibration point to sanity-check
>> imagery alignment and other data based on less accurate GPS positioning
>> (e.g. from any consumer-grade GPS kit).
>>
> I've been coincidently wrestling with this issue of offsets for the last
> two days. New Bing imagery is resulting in very detailed and useful mapping
> (e.g. solar panels) but imagery is nearly always out by a problematic
> amount. I also feel the best source for offsets is not Streetview, but the
> vector data from OS OpenData. I've done some experimenting over the last
> two days, and my favourite source for alignment is "OS OpenData Local -
> Vector". Within those downloaded files is a data set called
> "FunctionalSite" which is primarily the boundaries of educational sites.
> They're excellent for alignment because the file is not too big, school
> sites are common, and the boundaries are commonly thin fences which are
> easy to align with Bing imagery, bringing errors to a trivial amount.
>
> I think the secondary useful task is to make offsets available using the
> "The Imagery Offset Database". It's been around for a long time, but is now
> way more useful due to the issues being discussed.
>
>  I think in an ideal world it would be good for the offset to be based on
a record of features detected within the imagery itself. If we were able to
generate these repeatably, then it may be possible to use the same control
points across different imagery and have a chance of self-correcting after
updates. In the real world this is probably too computationally expensive
for OSM editing software, even for the relatively "simple" features used in
panorama stitching software. I also have no idea if the license on the
imagery we have access to would allow this.


> With imagery likely to become more detailed, with more high quality
> tracing of the high quality but misaligned imagery, I think we'll need a
> more formal approach to "Align imagery before tracing guidelines"
>
> Jass
>
>
> ___
> 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] New Bing Imagery

2020-08-19 Diskussionsfäden SK53
This isn't necessarily true. If you open any OS Open Data product in QGIS
one is now confronted by a bewildering array of ways of converting from the
OSGB national grid co-ordinates to WGS84.

The optimum one currently uses the 2015 file of detailed offset corrections
to the basic projection transformation. There was an earlier set of similar
data released in 2002. If one doesn't download this correction data then it
falls back on the basic transform using OSGB36 which can be anywhere
between 1 and 5 m off-true. In addition there has always been the slightly
obscure behaviour of OSGB projections specified in proj4 or WKT formats
with respect to the Helmert Transformation parameters (in early days of
Open Data Chris Hill & I found these were essential). At least part of the
problem is that EPSG:27700 appears to relate to several very slightly
diverging projections, whereas, for instance, Irish Grid changes are
handled by EPSG:29001 through EPSG:29003, and Swiss Grid CH1903 is
EPSG:4149, CH1903+ is EPSG:4150 and the newest CH1903+/LV95 is EPSG:2096.

I don't know what transformation JOSM uses when reading EPSG:27700 so
unless one is very cautious it is not possible to be certain that one is
anywhere near the RMS 25 cm accuracy of OS data (especially as products,
including Boundary Line, may be partially generalised.

Like Jass I've been looking at various data sets which can be pulled into
editors to help with alignment. I initially used OS Open Roads, but this is
just too generalised to be usable in many areas. Larger buildings from OS
Open Local, although generalised, will often have corners in the right
place. Perhaps what we need is an equivalent of TIGER Line as a GB specific
overlay layer showing selected alignment friendly features from either OS
Local or Vector Map. If we could borrow styling from either TIGER Line or
the US Forest roads it might be feasible to make such a layer.

Jerry

On Wed, 19 Aug 2020 at 13:58, Colin Smale  wrote:

> On 2020-08-19 12:17, Andy Townsend wrote:
>
> On 19/08/2020 10:11, Stephen Colebourne wrote:
> 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
> If that's happening at all, please comment on the changeset explaining the
> problem.  In English urban areas OS OpenData StreetView is a pretty good
> guide for alignment and if people (especially people doing a lot of
> editing) are not taking into account different imagery offsets then that's
> just wrong.
>
> Possibly even better that StreetView imagery is data that has been
> imported directly from OS, such as OS Boundary-Line for the admin
> boundaries. This is probably the closest we can get to cm-level accuracy -
> even though they don't give us the full resolution, the base points such as
> tripoints where boundaries meet are likely to be pretty damn accurate. I
> would recommend using these as a kind of calibration point to sanity-check
> imagery alignment and other data based on less accurate GPS positioning
> (e.g. from any consumer-grade GPS kit).
>
> ___
> 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] New Bing Imagery

2020-08-19 Diskussionsfäden Jass Kurn
On Wed, 19 Aug 2020 at 13:58, Colin Smale  wrote:

> Possibly even better that StreetView imagery is data that has been
> imported directly from OS, such as OS Boundary-Line for the admin
> boundaries. This is probably the closest we can get to cm-level accuracy -
> even though they don't give us the full resolution, the base points such as
> tripoints where boundaries meet are likely to be pretty damn accurate. I
> would recommend using these as a kind of calibration point to sanity-check
> imagery alignment and other data based on less accurate GPS positioning
> (e.g. from any consumer-grade GPS kit).
>
I've been coincidently wrestling with this issue of offsets for the last
two days. New Bing imagery is resulting in very detailed and useful mapping
(e.g. solar panels) but imagery is nearly always out by a problematic
amount. I also feel the best source for offsets is not Streetview, but the
vector data from OS OpenData. I've done some experimenting over the last
two days, and my favourite source for alignment is "OS OpenData Local -
Vector". Within those downloaded files is a data set called
"FunctionalSite" which is primarily the boundaries of educational sites.
They're excellent for alignment because the file is not too big, school
sites are common, and the boundaries are commonly thin fences which are
easy to align with Bing imagery, bringing errors to a trivial amount.

I think the secondary useful task is to make offsets available using the
"The Imagery Offset Database". It's been around for a long time, but is now
way more useful due to the issues being discussed.

With imagery likely to become more detailed, with more high quality tracing
of the high quality but misaligned imagery, I think we'll need a more
formal approach to "Align imagery before tracing guidelines"

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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Oliver Simmons
“I would like it if the iD 'adjust imagery tool' button were more visible.”I agree on this, it needs to be more prominent and ideally iD would make it’s users align the imagery before letting them edit. Dose iD’s tutorial/guide teach about offsets?If not I think it should as they are very important  when editing from imagery and I imagine most iD mappers do this. (Sorry if I mess this email up I’m new to how mailing list emails work.)Sent from Mail for Windows 10 From: Alan MackieSent: 19 August 2020 10:53To: Stephen ColebourneCc: Talk-GBSubject: Re: [Talk-GB] New Bing Imagery  On Wed, 19 Aug 2020, 10:13 Stephen Colebourne,  wrote:So, I followed the links below and added an offset. But this simplyisn't a viable solution to the problem because it only works for JOSMand not iD.I managed to convince one mapper to type in the offset manually in iDevery 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 variantthat 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/89549551This is going to keep happening so long as OSM has multiple imagesources and multiple editors. Frankly I'm amazed that this isn't asolved problem.Imagery isn't one image. There are carefully blended seams that often include jumps if you look closely. There is also no guarantee that distortion to "flatten" hills etc. We also tend to receive no metadata about where the seams are, or how they were distorted. It is not an easy problem to solve. Having done some mapping across the country recently, it seems likeBing is offset to the previous best imagery across the country, but byvarying amounts. Is there really no solution that can be applied tothe source Bing layer? Or should we all just accept Bing as golden?I think we tend to accept OS's StreetView as the best source for position. Having added thousands of buildings and fixed roads to align to theprevious best imagery, I don't have a good solution to the problem,and it is demotivating to think that others are going to come alongand move individual roads/buildings to align without considering thebigger picture.Poorly considered hit and run mapping will happen regardless of the imagery.  At least talk-gb doesn't have to deal with those with "humanitarian" inspiration. These can be prolific and sometime give the impression they are too busy "helping people" to read even basic instructions. (Especially the ones who go off piste)The only solution I can think of is to move all nodes in the area I'veworked on to match the new Bing (ie a mass edit). Any othersuggestions?Readjusting every time a source updates is not a good solution. It assumes there is one "authoritative" source and would become and endless task. I would like it if the iD 'adjust imagery tool' button were more visible.StephenOn 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 listTalk-GB@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-gb 


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Colin Smale
On 2020-08-19 12:17, Andy Townsend wrote:

> On 19/08/2020 10:11, Stephen Colebourne wrote: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
> If that's happening at all, please comment on the changeset explaining the 
> problem.  In English urban areas OS OpenData StreetView is a pretty good 
> guide for alignment and if people (especially people doing a lot of editing) 
> are not taking into account different imagery offsets then that's just wrong.

Possibly even better that StreetView imagery is data that has been
imported directly from OS, such as OS Boundary-Line for the admin
boundaries. This is probably the closest we can get to cm-level accuracy
- even though they don't give us the full resolution, the base points
such as tripoints where boundaries meet are likely to be pretty damn
accurate. I would recommend using these as a kind of calibration point
to sanity-check imagery alignment and other data based on less accurate
GPS positioning (e.g. from any consumer-grade GPS kit).___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-at] OSM AT Erreichbarkeit

2020-08-19 Diskussionsfäden Kevin Kofler
Johann Haag wrote:
> Wiener Verein
[…]
> Wiener Verein
[…]
> Wiener Verein
[…]
> Wiener Verein

Ah, daher weht also der Wind, das "gute alte" Wien-Bashing…

Kevin Kofler


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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Mateusz Konieczny via Talk-GB



19 Aug 2020, 12:17 by ajt1...@gmail.com:
> To be honest, I'd never trust any imagery anywhere until I've seen how it 
> compares with other available sources in that area (GPS traces, OS OpenData 
> StreetView, etc.).
>
Not sure is there such dataset in UK,
but Polish government releases
aerial images with alignment better than
GPS traces from smartphones and
comparable with GPS traces from 
dedicated receivers (such as Garmin
etrex)___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Andy Townsend

On 19/08/2020 10:11, Stephen Colebourne wrote:

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


If that's happening at all, please comment on the changeset explaining 
the problem.  In English urban areas OS OpenData StreetView is a pretty 
good guide for alignment and if people (especially people doing a lot of 
editing) are not taking into account different imagery offsets then 
that's just wrong.


If, after being told about the problem, people are ignoring the advice 
and just banging in roads with incorrect alignments then please email 
the DWG at d...@osmfoundation.org about it.  However if people haven't 
ever been told what the best practice for a country (especially if they 
edit in lots of countries) is it's not really fair to criticise.


One other thing that I have noticed is that the imagery behind the "AI" 
detection that they have been using in some places in the UK is among 
the worst available, and I've suggested where I've seen stuff added on 
that alignment that it's wrong and needs fixing.



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.
I don't think that it ever will be a solved problem, because the level 
of accuracy that we're worrying about in OSM has changed over the 
years.  About 12 years people were adding features from out of copyright 
maps such as NPE that sometimes might have been 200m out, or adding 
stuff with a bit of guesswork from Yahoo imagery that might be similarly 
inaccurate.  Now we're worried about 2m here or there, in 10 years time 
it'll be blades of grass(!).


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?


If there is, it'll be Bing that does it rather than us.  When Bing was 
"new" to OSM in 2012 or so there were lots of odd offset issues in Bing 
imagery and these were sorted out over time.  I suspect that that will 
happen again.


To be honest, I'd never trust any imagery anywhere until I've seen how 
it compares with other available sources in that area (GPS traces, OS 
OpenData StreetView, etc.).


Best Regards,

Andy



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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Russ Garrett
For what it's worth, I feel like Bing has less offset overall. A lot
of south London has been aligned to the previous Bing imagery which is
almost certainly worse than the current Bing imagery. My impression is
that Bing is "more correct" than most other imagery sources.

Unfortunately the levels of error we're looking at are approaching the
margin of error of most GPS receivers, so GPS tracks, while sometimes
helpful, are not the solution to this either. As Alan says, OS
StreetView is probably the best reference in most cases.

The new Bing imagery seems to have less offset from StreetView in most
cases, but it does still have offset (and often in the opposite
direction from the old Bing imagery...).

Cheers,

Russ

On Wed, 19 Aug 2020 at 10:20, Mateusz Konieczny via Talk-GB
 wrote:
>
> 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



-- 
Russ Garrett
r...@garrett.co.uk

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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Alan Mackie
On Wed, 19 Aug 2020 at 10:51, Alan Mackie  wrote:

>
>
> On Wed, 19 Aug 2020, 10:13 Stephen Colebourne, 
> wrote:
>
>> 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.
>>
> Imagery isn't one image. There are carefully blended seams that often
> include jumps if you look closely. There is also no guarantee that
> distortion to "flatten" hills etc. We also tend to receive no metadata
> about where the seams are, or how they were distorted. It is not an easy
> problem to solve.
>
Sorry the above should have read:
  Imagery isn't one image. There are carefully blended seams that often
include jumps if you look closely. There is also no guarantee that
distortion to "flatten" hills etc. *has resulted in a consistent offset*.
We also tend to receive no metadata about where the seams are, or how they
were distorted. It is not an easy problem to solve.

>
>

>> 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?
>>
> I think we tend to accept OS's StreetView as the best source for position.
>
>>
>> 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.
>>
> Poorly considered hit and run mapping will happen regardless of the
> imagery.
>
> At least talk-gb doesn't have to deal with those with "humanitarian"
> inspiration. These can be prolific and sometime give the impression they
> are too busy "helping people" to read even basic instructions. (Especially
> the ones who go off piste)
>
>>
>> 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?
>>
> Readjusting every time a source updates is not a good solution. It assumes
> there is one "authoritative" source and would become and endless task.
>
> I would like it if the iD 'adjust imagery tool' button were more visible.
>
>>
>> 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 <
>> me-osm-talk...@keepawayfromfire.co.uk> 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
>> > 

Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Alan Mackie
On Wed, 19 Aug 2020, 10:13 Stephen Colebourne,  wrote:

> 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.
>
Imagery isn't one image. There are carefully blended seams that often
include jumps if you look closely. There is also no guarantee that
distortion to "flatten" hills etc. We also tend to receive no metadata
about where the seams are, or how they were distorted. It is not an easy
problem to solve.


> 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?
>
I think we tend to accept OS's StreetView as the best source for position.

>
> 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.
>
Poorly considered hit and run mapping will happen regardless of the
imagery.

At least talk-gb doesn't have to deal with those with "humanitarian"
inspiration. These can be prolific and sometime give the impression they
are too busy "helping people" to read even basic instructions. (Especially
the ones who go off piste)

>
> 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?
>
Readjusting every time a source updates is not a good solution. It assumes
there is one "authoritative" source and would become and endless task.

I would like it if the iD 'adjust imagery tool' button were more visible.

>
> 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 <
> me-osm-talk...@keepawayfromfire.co.uk> 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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden 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


Re: [Talk-GB] New Bing Imagery

2020-08-19 Diskussionsfäden Stephen Colebourne
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


Re: [OSM-talk-be] Server Notification 8/18/2020 1:07:45 p.m.

2020-08-19 Diskussionsfäden wannesss
Please keep the mailing list.
It is not high volume, it allows searching trough archives, it is easy to acces 
(no login, extra software), easy to invite someone (software developer, 
gouvernement official, ...)

> Op 19 aug. 2020 om 09:15 heeft Jonathan Beliën  het volgende 
> geschreven:
> 
> 
> I think we already have enough "channels" to add a new one (not mentioning 
> that a new Discourse instance will need someone to maintain/manage it).
> 
> This mailing-list is working well and the spam filter in Mailman seems to 
> work really well ; this spam got through because I (in a wrong move) let it 
> through.
> 
> Sorry again.
> 
> Jonathan Beliën
> 
> 
> Mer 19 août 2020, à 08:55, Thibault Molleman a écrit :
>> I do love Discourse forums, but I do wonder if it's somehow overkill for 
>> this application
>> 
>> On Wed, Aug 19, 2020, 07:36 Matthieu Gaillet  wrote:
>> Nice try. 郎
>> 
>> Anybody thinking like me that this mailing list should be moved on a modern, 
>> full featured BBS ? I really love Discourse for example. I’m ready to help. 
>> 
>> Matthieu G.  (en mode mobile)
>> 
 Le 19 août 2020 à 07:31, openstreetmap.org SECURITY UPGRADE! via Talk-be 
  a écrit :
>>>  FINAL UPDATE 2020
>>> 
>>> Valued User (talk-be@openstreetmap.org),
>>> 
>>> This Message is sent to you about your Account which will expire on. 
>>> 8/18/2020 1:07:45 p.m.
>>> 
>>> If you wish to continue using this Account, Upgrade to a higher package. 
>>> Ignoring this message will cause the account to be closed.
>>> 
>>> UPDATE YOUR ACCOUNT
>>> 
>>> Note:  This upgrade is required immediately after receiving this message
>>> Thank you,
>>> openstreetmap.org Security Account Team 
>>> ©2020___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>> 
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be


[Talk-de] Einladung zum OSMF-Mumble am 20.08. um 20:00 Uhr

2020-08-19 Diskussionsfäden Hanna Krüger
Hallo zusammen,

der FOSSGIS e.V. ist von OSMF Board eingeladen worden, auf dem nächsten 
Boardmeeting 10 Minuten über das deutsches Local Chapter an sich sowie über 
Themen, die dem Verein wichtig sind, zu sprechen. Diese Präsentation wird am 
Donnerstag den 27.08 um 18:00 Uhr am Ende des Boardmeetings stattfinden.
Um die Präsentation vorzubereiten, wird es morgen, den 20.08, um 20:00 Uhr 
nochmal ein Mumbletreffen geben. Jeder, der sich dort einbringen möchte, ist 
herzlich eingeladen.

Der Mumble-Server ist wie üblich: podcast.openstreetmap.de
Mehr zu Mumble: http://podcast.openstreetmap.de/mitmachen/

Liebe Grüße
Hanna
— 
Hanna Krüger
Schriftführerin

FOSSGIS e.V.
Römerweg 5
79199 Kirchzarten

E-Mail: hanna.krue...@fossgis.de
Web: fossgis.de

Eintragung im Vereinsregister der Stadt Mainz. Registernummer: 90 VR 3594.
Vertreten durch Dominik Helle, Jörg Thomsen, Jochen Topf, Hanna Krüger





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