Re: [Talk-it] Violazione OSM

[demon.box]

Maurizio Napolitano-3 wrote
> In teoria i toponimi dovrebbero essere nomi riconosciuti da tutti,
> quindi è giusto che siano uguali.
> (...)

ciao, certo è non un problema di "gelosia" del dato ma semmai è un problema
di modalità di divulgazione del dato (senza citare la fonte).

sono comunque stra-sicuro che hanno copiato da OSM perchè sono toponimi che
prima di questa nuova mappa esistevano soltanto in OSM, non li avevo mai
visti su nessun'altra mappa, nemmeno sulla precedente 4Land della stessa
zona di una decina di anni fa, ne sulla CTR.

sono infatti tutti toponimi che io ho ricavato studiando pubblicazioni e
cercandone poi conferma da persone del luogo, oppure chiedendo direttamente
a loro, si tratta di toponimi molto particolareggiati conosciuti soltanto
localmente o che si erano persi nel tempo.

tra l'altro tra questi toponimi ce ne sono una ventina che sono stati
caricati da un altro mapper che conosco personalmente, frutto di una sua
ricerca fatta una trentina di anni fa ed ovviamente la 4Land ha copiato pure
quelli!!

appena avrò la mappa cartacea posterò degli esempi, ma credetemi: HANNO
COPIATO.

--enrico




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

[talk-au] Fixing NSW Locality boundaries

[Joel H.]

Someone has imported all the boundaries for localities into OSM, However 
most of these have fixme's. (example: 
https://www.openstreetmap.org/relation/6070204)


These ask for a center point/node, and to reconsider the place= tag. 
Would it be a good idea for me to first, make a relation with the label 
nodes. And then to change the place= tags on the boundaries to match the 
label nodes?


Keep in mind that the boundaries were imports, and could benefit from 
closer inspection.



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

Re: [Talk-cz] Taskman pro poštovní schránky

[Marián Kyral]

-- Původní e-mail --
Od: Marián Kyral 
Komu: OpenStreetMap Czech Republic 
Datum: 29. 1. 2018 12:22:58
Předmět: Re: [Talk-cz] Taskman pro poštovní schránky
"
-- Původní e-mail --
Od: majka 
Komu: OpenStreetMap Czech Republic 
Datum: 29. 1. 2018 12:04:48
Předmět: Re: [Talk-cz] Taskman pro poštovní schránky
"






2018-01-29 10:37 GMT+01:00 r00t :
"Ahoj,



Ty o kterych vim a mam tu v okoli snad domapuju rucne, ale ten reverse
geocoding
by to chtelo pro celou CR.

Je nekde ten seznam k nahlednuti, abych aspon vedel kolik mi jich tu v okoli
chybi nebo udelal ten geo-decoding rucne a podival se po nich ve streetview?



"





Můžu zkusit příští týden připravit pár dalších dep, případně pokud je zájem,
ještě někdy tenhle týden třeba tu Prahu. Bude ale třeba to potom ručně
projít a vložit do OSM.




Zatím jsem osobně takhle dělala depa České Budějovice, Český Krumlov a
Jindřichův Hradec + něco málo v Plzni.




Popis toho, jak jsem to dělala tu padl někdy v únoru loňského roku, můžu
sepsat nový / vylepšený návod.





Chyby souřadnic v poi-importeru (tedy souboru ČP) - hlásila jsem Mariánovi a
ten ručně opravoval souřadnice pro POI-importer. Mám za to, že někde
existuje csv, osobně jsem zatím posílala mailem.



"



Ten seznam (a konverzní skript) je tady: https://github.com/mkyral/osm/blob/
master/import/ceska_posta/corrections.csv




Ale je to ještě ve starém formátu, kdy ještě nebyly ref. Nově to bude:

ref;lat lon




Plánuji ten bastl přepsat do pythonu, mohlo by to být efektivnější.

"



Tak jsem se včera konečně dokopal k tomu, oprášit si python (hrůza jak
člověk zapomíná, když něco déle nepoužívá) a vypadá to slibně. To co mi v
shellu běželo minuty, po přepisu běží pár sekund.



Marián
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-ca] using image recognition to create building foot prints.

[Matthew Darwin]

Ok, just I had to re-write more than just that one section to make it 
coherent.   Hopefully the page has a bit more logical structure now.


https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020

Comments and edits welcome!


On 2018-01-29 09:26 PM, Matthew Darwin wrote:


I will re-write the "project management" section of the wiki page to 
align with this discussion.


On 2018-01-29 09:17 PM, john whelan wrote:
and I think I agree with Pierre the best approach would be to do it 
a step at a time using experienced local resources.


We do need to engage with high schools and the Universities but it 
is difficult with the resources available.  There is some material 
available https://wiki.openstreetmap.org/wiki/Education but it 
would need reviewing to see if it is relevant to what is required.


We were exceptionally fortunate in Ottawa with the pilot and the 
resources we had available but even there I wasn't certain we would 
be able to pull it off.


Cheerio John


2018-01-29 21:11 GMT-05:00 Matthew Darwin >:


+1

Unless someone has lots of $$$ to throw at OSM work (which
could then fund full time coordinators, trainers, lawyers,
etc), the only way I see to coordinate is to approach it like
how OSM in Canada was build up to now... distributed model with
local groups doing what makes sense for their area.   There is,
of course, no way to map all buildings in Canada by 2020 this
way.  Still it is good to set aspirational goals...

On 2018-01-29 08:57 PM, Pierre Béland wrote:


Il faut une part de réalisme. Pour bien coordonner, il ne
suffit pas de créer une tâche et d'inviter à participer. Nous
ne sommes pas une communauté structurée au niveau national. 
Je comprends que diverses universités s'intéressent au projet
OSM et aimeraient initier leurs étudiants à ce projet. La
meilleure solution je pense c'est de se mettre en contact avec
la communauté OSM locale et s'assurer de bien encadrer la
formation et les premiers jours de participation à OSM.

Les contributeurs sont davantage actifs dans leurs communautés
locales ou selon leur divers intérêts liés à leur travail ou
loisir. Personne n'est prêt à s'engager à coordonner un tel
projet au niveau national.



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







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

Re: [Talk-ca] using image recognition to create building foot prints.

[Matthew Darwin]

I will re-write the "project management" section of the wiki page to 
align with this discussion.


On 2018-01-29 09:17 PM, john whelan wrote:
and I think I agree with Pierre the best approach would be to do it 
a step at a time using experienced local resources.


We do need to engage with high schools and the Universities but it 
is difficult with the resources available.  There is some material 
available https://wiki.openstreetmap.org/wiki/Education but it would 
need reviewing to see if it is relevant to what is required.


We were exceptionally fortunate in Ottawa with the pilot and the 
resources we had available but even there I wasn't certain we would 
be able to pull it off.


Cheerio John


2018-01-29 21:11 GMT-05:00 Matthew Darwin >:


+1

Unless someone has lots of $$$ to throw at OSM work (which could
then fund full time coordinators, trainers, lawyers, etc), the
only way I see to coordinate is to approach it like how OSM in
Canada was build up to now... distributed model with local
groups doing what makes sense for their area.   There is, of
course, no way to map all buildings in Canada by 2020 this way.
Still it is good to set aspirational goals...

On 2018-01-29 08:57 PM, Pierre Béland wrote:


Il faut une part de réalisme. Pour bien coordonner, il ne
suffit pas de créer une tâche et d'inviter à participer. Nous
ne sommes pas une communauté structurée au niveau national.  Je
comprends que diverses universités s'intéressent au projet OSM
et aimeraient initier leurs étudiants à ce projet. La meilleure
solution je pense c'est de se mettre en contact avec la
communauté OSM locale et s'assurer de bien encadrer la
formation et les premiers jours de participation à OSM.

Les contributeurs sont davantage actifs dans leurs communautés
locales ou selon leur divers intérêts liés à leur travail ou
loisir. Personne n'est prêt à s'engager à coordonner un tel
projet au niveau national.



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





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

Re: [Talk-ca] using image recognition to create building foot prints.

[john whelan]

 and I think I agree with Pierre the best approach would be to do it a step
at a time using experienced local resources.

We do need to engage with high schools and the Universities but it is
difficult with the resources available.  There is some material available
https://wiki.openstreetmap.org/wiki/Education but it would need reviewing
to see if it is relevant to what is required.

We were exceptionally fortunate in Ottawa with the pilot and the resources
we had available but even there I wasn't certain we would be able to pull
it off.

Cheerio John


2018-01-29 21:11 GMT-05:00 Matthew Darwin :

> +1
>
> Unless someone has lots of $$$ to throw at OSM work (which could then fund
> full time coordinators, trainers, lawyers, etc), the only way I see to
> coordinate is to approach it like how OSM in Canada was build up to now...
> distributed model with local groups doing what makes sense for their
> area.   There is, of course, no way to map all buildings in Canada by 2020
> this way.  Still it is good to set aspirational goals...
> On 2018-01-29 08:57 PM, Pierre Béland wrote:
>
>
> Il faut une part de réalisme. Pour bien coordonner, il ne suffit pas de
> créer une tâche et d'inviter à participer. Nous ne sommes pas une
> communauté structurée au niveau national.  Je comprends que diverses
> universités s'intéressent au projet OSM et aimeraient initier leurs
> étudiants à ce projet. La meilleure solution je pense c'est de se mettre en
> contact avec la communauté OSM locale et s'assurer de bien encadrer la
> formation et les premiers jours de participation à OSM.
>
> Les contributeurs sont davantage actifs dans leurs communautés locales ou
> selon leur divers intérêts liés à leur travail ou loisir. Personne n'est
> prêt à s'engager à coordonner un tel projet au niveau national.
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] using image recognition to create building foot prints.

[Matthew Darwin]

+1

Unless someone has lots of $$$ to throw at OSM work (which could then 
fund full time coordinators, trainers, lawyers, etc), the only way I 
see to coordinate is to approach it like how OSM in Canada was build 
up to now... distributed model with local groups doing what makes 
sense for their area.   There is, of course, no way to map all 
buildings in Canada by 2020 this way.  Still it is good to set 
aspirational goals...


On 2018-01-29 08:57 PM, Pierre Béland wrote:


Il faut une part de réalisme. Pour bien coordonner, il ne suffit pas 
de créer une tâche et d'inviter à participer. Nous ne sommes pas une 
communauté structurée au niveau national.  Je comprends que diverses 
universités s'intéressent au projet OSM et aimeraient initier leurs 
étudiants à ce projet. La meilleure solution je pense c'est de se 
mettre en contact avec la communauté OSM locale et s'assurer de bien 
encadrer la formation et les premiers jours de participation à OSM.


Les contributeurs sont davantage actifs dans leurs communautés 
locales ou selon leur divers intérêts liés à leur travail ou loisir. 
Personne n'est prêt à s'engager à coordonner un tel projet au niveau 
national.


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

Re: [Talk-ca] using image recognition to create building foot prints.

[Pierre Béland]

Effectivement, on en revient aux discussions d'il y a quelques mois. Nous avons 
indiqué dès le départ que ce projet était très ambitieux et qu'il y avait des 
risques importants sur la qualité de la données si on s'appuyait principalement 
sur des groupes inexpérimentés via les universités, etc. 
John mentionnait la réponse pour le Népal. Nous venions de terminer la réponse 
pour l'Ébola après près d'un an de cartographie intensive.  Nous avions 
plusieurs défis à surmonter avec l'absence d'imagerie récente, des communautés 
isolées en montagne, des communications interrompues.  A cela s'est ajoutée la 
vague déferlante des carto-parties. Les médias avaient beaucoup parlé de la 
réponse humanitaire OSM aux diverses crises humanitaires. Beaucoup de groupes 
étaient intéressés à collaborer. Encore plus que pour Tacloban aux Philippines 
et pour l'Ebola.  Les statistiques montraient des records de participation de 
nouveaux contributeurs. En contrepartie, John et d'autres qui validaient les 
données, rapportaient continuellement des problèmes de qualité de la donnée. 
Nous avons vécu le même problème avec Haiti en octobre 2016. 

Il faut une part de réalisme. Pour bien coordonner, il ne suffit pas de créer 
une tâche et d'inviter à participer. Nous ne sommes pas une communauté 
structurée au niveau national.  Je comprends que diverses universités 
s'intéressent au projet OSM et aimeraient initier leurs étudiants à ce projet. 
La meilleure solution je pense c'est de se mettre en contact avec la communauté 
OSM locale et s'assurer de bien encadrer la formation et les premiers jours de 
participation à OSM.

Les contributeurs sont davantage actifs dans leurs communautés locales ou selon 
leur divers intérêts liés à leur travail ou loisir. Personne n'est prêt à 
s'engager à coordonner un tel projet au niveau national.  
Des personnes comme John et moi avons consacré beaucoup de temps à coordonner, 
supporter les réponses humanitaires OSM au niveau international. Nos propos 
prudents visent à en venir à une approche réaliste.  Il vaut mieux partir sur 
des bases solides, initier quelques projets au départ si des communautés sont 
prêtes à les supporter.    
Pierre 
 

Le lundi 29 janvier 2018 18:57:14 HNE, john whelan  
a écrit :  
 
 ​The idea behind the building project is good.  Basically you need a mixture 
of accurate building outlines and tags.  From there the statisticians can work 
their magic.  This is true in Canada as well as other parts of the world.  With 
OSM buildings and tags combined with open source stats software R (R.org) you 
get ground floor GIS planning tools and they are badly needed in Africa etc.  
If we can pull it off this is good.

First Pierre's point that machine learning and imagery is a little different to 
using radar type technology. If we would have had it available in Nepal it 
would have saved a lot of problems.  Even today in Africa the standard of 
building mapping would be much improved by the use of such technology.

It isn't yet accepted by OSM as mainstream.  That is an issue we need to get 
round before we can use the stuff.

However Canada has always been in the forefront of imports.  We have a history 
of using NCR Canada’s data ie CANVEC and we are comfortable using it.  Some 
parts we recognise are better quality than others.  We also have within the 
mailing list some deep technical expertise which can be used to evaluate the 
radar type technology for detecting building outlines.  I think it will take 
time to get this technology accepted by OSM and that is the point of this 
thread.

I think we have to accept that the BC2020i project is one that was not dreamt 
up by the OSM community.  I think the idea came out of Alessandro of Stats 
Canada and my understanding is the web page was put together by a single person 
with little experience of OSM, the processes and politics involved. There is 
demand for the data but OSM is more geared towards mappers than customer 
demands.

What we have ended up with is a project with lots of words and aspirations but 
little apparent understanding of what is involved.  The idea has been picked up 
by High Schools and Universities and we are now getting inexperienced mappers 
in with little training adding buildings to the map in iD and the data quality 
is poor for some and that is an issue since it reflects on the project itself.

There seems to be no project manager and that is an issue.  We’ve cleaned up 
the wiki page to some extent.  There is a demand from schools and Universities 
to get involved.  We need someone to put together guidance for these people.

I take Pierre’s point that in an ideal world experienced local mappers would 
map locally and take responsibility for their area importing when appropriate.  
Unfortunately we do not live in an ideal world.

Cheerio John​

On 29 January 2018 at 17:59, OSM Volunteer stevea  
wrote:

On Jan 29, 2018, at 2:35 PM, 

Re: [Talk-cl] Senderos y datos de Strava

[Marco González Luengo]

Hola Danilo,

Es bueno saber que hay datos, entonces, porque a través de Maps.me (que es
lo que uso para cuando viajo) no aparece la información de los senderos. De
todos modos revisaré a ver si es algo por mi lado o por los parámetros que
usa Maps.me para sus mapas.

Y es bueno saber que hay integración con Strava. Me será útil para mantener
senderos en Pichilemu.

Saludos.


El El lun, 29 de ene. de 2018 a las 21:07, Danilo Lacoste <
dan...@lacosox.org> escribió:

> Hola Marco, los datos de strava que entiendo se pueden usar, son los del
> heatmap, incluso ellos tienen una app que permite mejorar los caminos
> usando ese heatmap integrado con el editor ID.
> https://labs.strava.com/slide/ ;
> https://wiki.openstreetmap.org/wiki/Strava
>
> Respecto a los datos del Cerro Ñielol en Temuco, yo soy parte de esos
> personajes que se la pasan allá haciendo como que somos sanos :), y hace
> algunos años agregué varias de las rutas con sus nombres (no todos si),
> incluso agregué también senderos no oficiales que normalmente usamos para
> hacer MTB.
>
> Como mencionas, usar esa capa de strava es super útil para encontrar esos
> caminos desconocidos.
>
> saludos.
>
>
> 2018-01-29 20:57 GMT-03:00 Marco González Luengo :
>
>> Buenas,
>>
>> Hace un par de días que veo en mi Twitter que se ha hecho alguna polémica
>> respecto a una liberación de datos de la aplicación Strava (un tracker para
>> deportistas) y que ha permitido tener trazas de sitios militares
>> confidenciales. Sin embargo mi tema aquí es otro.
>>
>> Hace poco visité el Cerro Ñielol en Temuco y me di cuenta que
>> aparentemente no hay trazas de los senderos del cerro, sino sólo los
>> caminos principales. Estos senderos están señalizados y tienen nombres, e
>> incluso algunos con miradores. Como solo estaba de paso, no pude dedicarme
>> a trazar, pero si note que habían muchos deportistas recorriendo los
>> senderos, ya sea en bicicleta o trotando.
>>
>> Como hay una gran cantidad de deportistas que usan aplicaciones como
>> Strava, pensé que sería conveniente usar trazas GPS de aquellos usuarios
>> para lograr mejorar la red de senderos de varios lugares, como en este caso
>> el Cerro Ñielol. Sin embargo, desconozco la licencia de aquellos datos.
>>
>> Se que Strava tiene un sitio web, https://labs.strava.com, donde se
>> puede juguetear con los datos que tienen disponible.
>>
>> Saludos.
>>
>> ___
>> Talk-cl mailing list
>> Talk-cl@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cl
>>
>>
>
>
> --
> Danilo Lacoste Z.   dan...@lacosox.org
> Ing. Civil en informática
> www.lacosox.org
>
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

[Talk-cl] Senderos y datos de Strava

[Marco González Luengo]

Buenas,

Hace un par de días que veo en mi Twitter que se ha hecho alguna polémica
respecto a una liberación de datos de la aplicación Strava (un tracker para
deportistas) y que ha permitido tener trazas de sitios militares
confidenciales. Sin embargo mi tema aquí es otro.

Hace poco visité el Cerro Ñielol en Temuco y me di cuenta que aparentemente
no hay trazas de los senderos del cerro, sino sólo los caminos principales.
Estos senderos están señalizados y tienen nombres, e incluso algunos con
miradores. Como solo estaba de paso, no pude dedicarme a trazar, pero si
note que habían muchos deportistas recorriendo los senderos, ya sea en
bicicleta o trotando.

Como hay una gran cantidad de deportistas que usan aplicaciones como
Strava, pensé que sería conveniente usar trazas GPS de aquellos usuarios
para lograr mejorar la red de senderos de varios lugares, como en este caso
el Cerro Ñielol. Sin embargo, desconozco la licencia de aquellos datos.

Se que Strava tiene un sitio web, https://labs.strava.com, donde se puede
juguetear con los datos que tienen disponible.

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

Re: [Talk-ca] using image recognition to create building foot prints.

[john whelan]

​The idea behind the building project is good.  Basically you need a
mixture of accurate building outlines and tags.  From there the
statisticians can work their magic.  This is true in Canada as well as
other parts of the world.  With OSM buildings and tags combined with open
source stats software R (R.org) you get ground floor GIS planning tools and
they are badly needed in Africa etc.  If we can pull it off this is good.

First Pierre's point that machine learning and imagery is a little
different to using radar type technology. If we would have had it available
in Nepal it would have saved a lot of problems.  Even today in Africa the
standard of building mapping would be much improved by the use of such
technology.

It isn't yet accepted by OSM as mainstream.  That is an issue we need to
get round before we can use the stuff.

However Canada has always been in the forefront of imports.  We have a
history of using NCR Canada’s data ie CANVEC and we are comfortable using
it.  Some parts we recognise are better quality than others.  We also have
within the mailing list some deep technical expertise which can be used to
evaluate the radar type technology for detecting building outlines.  I
think it will take time to get this technology accepted by OSM and that is
the point of this thread.

I think we have to accept that the BC2020i project is one that was not
dreamt up by the OSM community.  I think the idea came out of Alessandro of
Stats Canada and my understanding is the web page was put together by a
single person with little experience of OSM, the processes and politics
involved. There is demand for the data but OSM is more geared towards
mappers than customer demands.

What we have ended up with is a project with lots of words and aspirations
but little apparent understanding of what is involved.  The idea has been
picked up by High Schools and Universities and we are now getting
inexperienced mappers in with little training adding buildings to the map
in iD and the data quality is poor for some and that is an issue since it
reflects on the project itself.

There seems to be no project manager and that is an issue.  We’ve cleaned
up the wiki page to some extent.  There is a demand from schools and
Universities to get involved.  We need someone to put together guidance for
these people.

I take Pierre’s point that in an ideal world experienced local mappers
would map locally and take responsibility for their area importing when
appropriate.  Unfortunately we do not live in an ideal world.

Cheerio John​


On 29 January 2018 at 17:59, OSM Volunteer stevea  wrote:

> On Jan 29, 2018, at 2:35 PM, Stewart C. Russell  wrote:
> > On 2018-01-29 04:37 PM, OSM Volunteer stevea wrote:
> >>
> >> OSM is delighted to receive building data in Canada, truly we are.
> >> (Provided they are high-quality data).  I have heard the process of
> >> entering data into OSM, especially "bulk import" OD (which must match
> >> license compatibility against OSM's license, our ODbL) described as
> >> "inside baseball."  It is not.
> >
> > If you're gonna quote me, at least try to understand me, please.
>
> Stewart, I apologize if I misquoted you or took it out of context, that
> was not my intention.
>
> > The open data / OSM dialogue in Canada has been going something like
> > this, ever since I started working with municipal groups in 2011 or so:
> >
> > Municipal data advocate: Please use our data! It's under an open
> >   licence!
> >
> > OSM volunteer: But our licences aren't compatible!
> >
> > Municipal data advocate: But it's an open licence! Our lawyers say
> >   you'll be fine!
> >
> > OSM volunteer: But we need … (starts to reel off list of additional
> >   supporting docs)
> >
> > Municipal data advocate: Companies like Google and Nokia use our data
> >   with no problem. Use our data! We are giving it to you!
> >   Don't complain!
> >
> > OSM volunteer: but but the licence …
> >
> > (Municipal data advocate storms off in search of a someone more likely
> > to give them corporate recognition.)
> >
> > Some very tenacious OSM people and some very adaptable government people
> > have made things work in a few places in Canada.
>
> I both salute these efforts and bow deeply in obeisance at the good work
> done here by them.  These are the important seeds of the future, the acorns
> from which mighty oaks shall grow.  Yes, it will take time, effort,
> coordination, management and documentation.
>
> Simply put, (and I don't wish to be rude), "municipal data advocates"
> cannot assume that OSM is a "free ride," without some front-loaded effort
> at planning and further project guidance along the way.  We have our
> culture and methods in OSM, and that's the way it is.  I am hopeful, as
> inter-community cooperation is something Canada has been and is quite good
> at doing for its entire history.
>
> > Only when we have a way
> > forward on data licensing, 

Re: [Talk-ca] using image recognition to create building foot prints.

[OSM Volunteer stevea]

On Jan 29, 2018, at 2:35 PM, Stewart C. Russell  wrote:
> On 2018-01-29 04:37 PM, OSM Volunteer stevea wrote:
>> 
>> OSM is delighted to receive building data in Canada, truly we are.
>> (Provided they are high-quality data).  I have heard the process of
>> entering data into OSM, especially "bulk import" OD (which must match
>> license compatibility against OSM's license, our ODbL) described as
>> "inside baseball."  It is not.
> 
> If you're gonna quote me, at least try to understand me, please.

Stewart, I apologize if I misquoted you or took it out of context, that was not 
my intention.

> The open data / OSM dialogue in Canada has been going something like
> this, ever since I started working with municipal groups in 2011 or so:
> 
> Municipal data advocate: Please use our data! It's under an open
>   licence!
> 
> OSM volunteer: But our licences aren't compatible!
> 
> Municipal data advocate: But it's an open licence! Our lawyers say
>   you'll be fine!
> 
> OSM volunteer: But we need … (starts to reel off list of additional
>   supporting docs)
> 
> Municipal data advocate: Companies like Google and Nokia use our data
>   with no problem. Use our data! We are giving it to you!
>   Don't complain!
> 
> OSM volunteer: but but the licence …
> 
> (Municipal data advocate storms off in search of a someone more likely
> to give them corporate recognition.)
> 
> Some very tenacious OSM people and some very adaptable government people
> have made things work in a few places in Canada.

I both salute these efforts and bow deeply in obeisance at the good work done 
here by them.  These are the important seeds of the future, the acorns from 
which mighty oaks shall grow.  Yes, it will take time, effort, coordination, 
management and documentation.

Simply put, (and I don't wish to be rude), "municipal data advocates" cannot 
assume that OSM is a "free ride," without some front-loaded effort at planning 
and further project guidance along the way.  We have our culture and methods in 
OSM, and that's the way it is.  I am hopeful, as inter-community cooperation is 
something Canada has been and is quite good at doing for its entire history.

> Only when we have a way
> forward on data licensing, then BC2020 would be an OSM project.

I respectfully disagree.  Yes, "ways forward on data licensing" is vitally 
important, as it is a major obstacle.  However, BC2020, and the way that it has 
morphed into becoming by its very nature using OSM as a repository of data, IS 
an OSM project.  Therefore, it must hew to OSM tenets, like transparency, good 
communication, wiki updates, and in a project of scope this wide, sane and 
steady planning and project management.

You can say that license compatibility is "slow going" (and you'd be right) but 
OSM is "up to" three cities (from one, Ottawa).  Rome wasn't built in a day and 
Canada's building data won't be entered into OSM in a day, either.  HOWEVER, as 
they are being entered now, some "manually," some (few) via OD licence, and 
some as simple improvements ("Hey, I'm going to tag this a café because I'm a 
local OSM user and I know it is one!"), these efforts MUST BE coordinated (or 
managed, I keep saying, though I'm not particularly enamored of the word as it 
seems non-OSM, yet on national-scope projects, something like "management" 
really is required, even if it is "loose but effective coordination").

Building data being entered into OSM do not have to be part of BC2020i, what is 
now WikiProject BC2020:  if I simply tag a building polygon amenity=cafe, I 
don't become part of a coordinated effort.  However, to the extent they strive 
to be part of the coordinated effort to enter nationwide building data, 
following the guidelines in our wiki of what we mean by acceptable-quality 
data, with acceptable tags, they really, really should.  Such coordination 
benefits everybody, and at minor "cost" (follow some nationwide guidelines, 
stay communicative with your status...).  Is that so difficult a point upon 
which to agree?

Thank you for continuing good dialog,
SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-GB] Help remembering how to ...

[Lester Caine]

On 29/01/18 21:22, Lester Caine wrote:

It has been a while and my notes and crib sheets seem to be messed up.

Have JOSM running with ImportImagePlugin and I have a tif file with a 28 
pixel per meter scale, and the lat and long for the top left corner, but 
I'm obviously not putting the right numbers in the world file which I 
have done in the past and fine tuned position once loaded so has 
something changed, or have I just got the wrong data. I'm fairly sure I 
also had a Linux program that helped me play with the values but having 
brain freeze at the moment ...


First problem solved ... it's PicLayer plugin ... and then I can tweak 
the config files ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-ca] using image recognition to create building foot prints.

[Stewart C. Russell]

On 2018-01-29 04:37 PM, OSM Volunteer stevea wrote:
> 
> OSM is delighted to receive building data in Canada, truly we are.
> (Provided they are high-quality data).  I have heard the process of
> entering data into OSM, especially "bulk import" OD (which must match
> license compatibility against OSM's license, our ODbL) described as
> "inside baseball."  It is not.

If you're gonna quote me, at least try to understand me, please.

The open data / OSM dialogue in Canada has been going something like
this, ever since I started working with municipal groups in 2011 or so:

Municipal data advocate: Please use our data! It's under an open
licence!

OSM volunteer: But our licences aren't compatible!

Municipal data advocate: But it's an open licence! Our lawyers say
you'll be fine!

OSM volunteer: But we need … (starts to reel off list of additional
supporting docs)

Municipal data advocate: Companies like Google and Nokia use our data
with no problem. Use our data! We are giving it to you!
Don't complain!

OSM volunteer: but but the licence …

(Municipal data advocate storms off in search of a someone more likely
to give them corporate recognition.)

Some very tenacious OSM people and some very adaptable government people
have made things work in a few places in Canada. Only when we have a way
forward on data licensing, then BC2020 would be an OSM project.

 Stewart

 Stewart

Stewart

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

Re: [Talk-de] Königreich Württemberg

[Michael Reichert]

Hallo Martin,

Am 23.01.2018 um 01:52 schrieb Martin Koppenhoefer:
> Nachdem sich hier alle einig waren, habe ich mich mal an Württemberg
> gemacht. Die Relation ist ja schnell gelöscht, aber die ways, die mit
> boundary=historic neu angelegt worden waren, sind z.T. noch übrig (beim
> ersten Versuch ist mir der JOSM abgestürzt und darum habe ich es nun in
> mehreren Changesets gemacht), man muss da ja aufpassen, dass man erst die
> Gegend lädt, bevor man löscht, weil man sonst versehentlich nodes löschen
> könnte, die auch von anderen ways benutzt werden, oder kümmert sich da die
> API drum?

Wenn du ein Objekt löschen willst und den entsprechenden
HTTP-DELETE-Call machst, prüft die API, ob das Objekt noch anderswo
referenziert wird. Wenn du den Diff-Upload verwendest, wird der gesamte
Diff zurückgewiesen, weil laut Doku garantiert ist, dass der gesamte
Diff als eine SQL-Transaktion durchgeführt wird.

Ich habe vor einigen Wochen ein C++-Tool geschrieben, das mir in genau
den Anwendungsfall (Relationen löschen, die man für überflüssig hält)
alle Ways ausgibt, die nach der Löschaktion Waisen wären.

https://github.com/Nakaner/prepdelrels

Viele Grüße

Michael

-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



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

Re: [Talk-at] *** GMX Spamverdacht *** Re: Neighbourhoods in Wien

[Stefan Tauner]

On Mon, 29 Jan 2018 13:49:43 +0100
Kevin Kofler  wrote:

> Bzgl. Bergen fällt mir da der Gipfel bei der Schwabenwiese ein, wo im 
> franziszeischen Kataster der Name "Handleinsberg" aufscheint, auf einer 
> anderen historischen Karte auf wien.at habe ich "Handelsberg" gelesen, 
> offiziell hat der Gipfel keinen Namen. Da gab es schon Revert-Wars zwischen 
> dem oder den Befürworter(n) eines Phantasienamen (offenbar eine Benennung 
> durch einen Beitragenden nach sich selbst), den Befürwortern von 
> "Handleinsberg" und denen, die den Gipfel ganz namenlos sehen wollen. 
> Derzeit ist kein Name eingetragen.

Also eigentlich gibts da nur 2 Parteien. Den PP, der offenbar der
Meinung ist, der Berg soll nach ihm benannt sein oder gar nicht... und
alle anderen, denen es relativ egal ist, ob ein nicht gebräuchlicher
Name getaggt ist und welcher davon oder eben gar keiner - aber
jedenfalls kein Bullshit. :)

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

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

Re: [Talk-ca] using image recognition to create building foot prints.

[Pierre Béland]

Précision,   Les missions aériennes permettent de produire des images de grande 
qualité.  On y associe des équipements LIDAR qui émettent un signal vers le sol 
pour mesurer la distance. Aussi bien la technique LIDAR que de petits drones 
sont aujourd'hui capables de produire des modèles d'élévation avec quelques 
centimètres de précision.  Cela permet aussi de produire des modèles 3D des 
immeubles et de distinguer avec la végétation.
Suite aux inondations du Richelieu et du Lac Champlain en 2011, des modèles 
d'élévation très des zones urbaines en bordure de la rivière Richelieu ont été 
produites. Si on se rappelle les discussions il y a quelques mois, un tel 
travail d'import va nécessiter des ressources importantes. Les diverses 
communautés OSM locales devront évaluer leur capacité à réaliser des projets 
d'import d'immeubles. Et il faut éviter de se baser sur le modèle 
«Cartoparties» pour réaliser de tels projets. Des milliers de personnes qui 
sont sensibiliées quelques heures à la cartographie ne reviennent pas ensuite 
et laisse souvent une donnée de piètre qualité.
Il faut être réaliste et construire peu à peu, motiver des communautés locales 
à expérimenter un modèle d'import de la donnée. Cela fera ensuite boule de 
neige ( c'est de saison :)  )

Pierre 
 

Le lundi 29 janvier 2018 16:07:31 HNE, Pierre Béland  a 
écrit :  
 
 Bonjour John
Les spécialistes d'imagerie produisent des couches de données assez précises à 
partir d'imagerie LIDAR ou de drones, incluant, immeubles, cours d'eau et 
occupation du sol. Ces images offrent qualité et précision. Des techniques de 
classification, interprétation, correction permettent aux spécialistes de 
converger vers un produit de qualité.  Et bien sûr toutes ces avancées 
technologiques et l'accès éventuel à des profanes bousculent les habitudes tout 
comme les véhicules sans conducteur :)
Même si Statistique Canada fournit à OSM un fichier produit par des 
spécialistes, il sera nécessaire ensuite d'établir une procédure d'import, de 
fusionner / aligner avec les données existantes et de corriger. 
Et ouvront la porte au Futur! Une autre avenue, c'est l'accès aux profanes que 
nous sommes à des outils semi-automatiques pour faciliter la digitalisation de 
différents éléments tels immeubles, routes et rivières. Je ne connais pas 
l'historique des expériences d'utilisation de tels outils. Mais on peut 
remonter en 2011, où on parlait d'un outil de détection de route. Divers 
articles traitent aussi de ce sujet.
https://alastaira.wordpress.com/2011/02/04/automatic-road-detection-using-bing-maps-imagery/https://gis.stackexchange.com/questions/77876/is-there-a-tool-that-performs-automatic-recognition-of-buildings


Facebook a aussi expérimenté des outils de reconnaissance d'image en Thaîlande 
récemment. Selon les plaintes de certains contributeurs, les données ont été 
ajoutées à OSM sans valider suffisamment avec la réalité sur le terrain.
Je pense qu'il serait intéressant pour les contributeurs expérimentés d'avoir 
accès à des outils semi-automatisés facilitant dans JOSM par exemple le tracé 
d'immeubles, routes, cours d'eau, etc. Pour un cours d'eau par exemple, je 
déplace le curseur de la souris, et les contours et le centre de la rivière 
sont tracés automatiquement. Ou encore le contour d'un lac est tracé.
 
Pierre 
 

Le lundi 29 janvier 2018 15:15:59 HNE, john whelan  
a écrit :  
 
 ·    NRCan is working on a methodology to extract building  footprints, 
including topographic elevation and height attributes, from LiDAR


Traditionally OSM has not been happy with this sort of thing.  The accuracy can 
be poor.

We probably need to think about this since the BC2020i project had this 
mentioned and Stats Can has given it a mention also.  I'm not promoting it nor 
saying its bad but it will almost certainly be raised shortly.

First if an import was done using this data who would be the local group to 
approve it?  I suspect because it covers the entire country it would be the 
talk-ca group.  The date would come through the TB portal so licensing is not 
an issue.  Or it could be split into regions with regional local groups making 
decisions.

The other very big question is to do with data quality.  So far nothing that is 
machine learnt from imagery has consistently met the expectations of 
OpenStreetMap.

Note to Pierre I'm not sure if you are on the talk-ca mailing list but any 
feedback you might have on the data quality side would be welcome and will be 
shared amongst the group.

Thoughts?

Thanks John
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] using image recognition to create building foot prints.

[OSM Volunteer stevea]

Um, "dyed-in-the-wool."
Steve

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

Re: [Talk-ca] using image recognition to create building foot prints.

[OSM Volunteer stevea]

On Jan 29, 2018, at 12:15 PM, john whelan  wrote:
> ·NRCan is working on a methodology to extract building footprints, 
> including topographic elevation and height attributes, from LiDAR
> Traditionally OSM has not been happy with this sort of thing.  The accuracy 
> can be poor.

I find it troublesome that John should even have to explain this to a single 
person on this list.  However, maybe some here don't know this, so "OK."

Warning:  lukewarm screed ahead.

I say this with all politeness intended:  OpenStreetMap is not a dumping 
grounds for data which are open (OD) nor experimental from AI/machine learning 
results, then there is some vague and hand-waving future process which may or 
may not come along in the future and "fix them to meet OSM's quality standards."

OSM is delighted to receive building data in Canada, truly we are.  (Provided 
they are high-quality data).  I have heard the process of entering data into 
OSM, especially "bulk import" OD (which must match license compatibility 
against OSM's license, our ODbL) described as "inside baseball."  It is not.  
Every single person reading this list is either an OSM volunteer like me, or 
has an interest in OSM.  (Signing up for this mailing list is my evidence for 
saying that).  That means fully treating OSM as the "host project" for these 
data, simply put, because it is.  Acting as if OSM is simply an airplane 
expected to fly, without following a flight plan nor contacting a control tower 
will get this project grounded, as OSM volunteers like me declare an emergency, 
seeing nobody in the pilot's seat, while all the passengers expect a free ride 
to their own distinct destinations.  That simply "doesn't fly."

Recently, many of us have become more aware of the history of StatsCan wanting 
to introduce building data to crowdsourcing and coming up with BC2020i (the i 
for "initiative").  Left quite unspoken was that "crowdsourcing building data 
from StatsCan" silently became "put building data into OSM."  While there was 
traction to do this in 2016, many meetings, a fair amount of data entry and the 
beginnings of more established OSM-style process (writing a wiki or two, 
efforts to harmonize local OD licenses with ODbL...) in 2017, this "initiative" 
has now fully morphed into an OSM WikiProject, BC2020.  This has its own wiki 
(https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Building_Canada_2020 
being re-written now) and is getting on a better footing by discussing the huge 
number of moving parts both there and here in talk-ca.  But, in my opinion, the 
project remains badly unfocused (slowly, it gets better).

Building data in Canada entering OSM, whether by "manual" methods (e.g. tracing 
a Bing layer) or by "bulk import" from licenced OD is ongoing.  However, it 
absolutely must hew to the tenets of OSM:  good, wide-area coordination and 
communication, consensus, following the guidelines written into an Import Plan 
(if bulk importation of OD data happens) and keeping others informed of status 
(licence approvals, how far along manual methods are via the Task Manager...).  
This is NOT "inside baseball."  It is OSM, plain and simple, through and 
through — this is because BC2020 is an OSM project.  In my opinion (and if it 
isn't clear by now), this project suffers from a serious lack of Project 
Management.  I do not wish to chide, rather to encourage.

As OSM is "hosting" BC2020, I'd like to see more "cultural sensitivity" towards 
what OSM absolutely MUST DO on national-level projects:

• we document our intentions with a well-written wiki (due to history, 
what we have was poorly done, though it is improving),
• we publish Import Plans PER IMPORT (whether municipality, province or 
whatever),  Ottawa's was good, others must grow from this,
• we inform wider community (Canadian and worldwide OSM) with status, 
including licence and data entry progress, whether via Task Manager or 
otherwise,
• especially in early stages (and we are here now), we guide and steer 
the project towards achievable goals and realistic timeframes, doing so 
applying knowledge gained from previous (especially national-level or very wide 
scope) OSM projects.

This is not an exhaustive list.

Please, for months I've been cajoling, back-channel-communicating, 
wiki-improving and friend-making my way (OUR way) towards a simple 
understanding (and declaration?) by all involved in BC2020 that it is an OSM 
project, that it must hew closely to OSM tenets and that that is not "inside 
baseball."  OSM is simply the methods by which these Canadian building data 
find a home.  I'd like to see "local stovepipes" of sub-project data entry 
efforts and no- or little-communication turn into talk-ca threads and new wiki 
sections in our wiki, so this project becomes much more transparent and 
wide-area.  I'd especially like to see someone or some group (call it a 
"steering committee") step 

Re: [Talk-ca] using image recognition to create building foot prints.

[john whelan]

I think my concern at the moment is how to handle these in an acceptable
manner to OSM.

It would seem Stewart has some confidence in the data and I suspect you
have yourself.

So given a benediction by the mailing list to go ahead we would need to go
through the import process.

My gut feel would be some sort of manual import using JOSM one building at
a time over a trial area might be acceptable and I'm not sure if we have a
volunteer nor when the data will be available.

Cheerio John

2018-01-29 16:07 GMT-05:00 Pierre Béland :

> Bonjour John
>
> Les spécialistes d'imagerie produisent des couches de données assez
> précises à partir d'imagerie LIDAR ou de drones, incluant, immeubles, cours
> d'eau et occupation du sol. Ces images offrent qualité et précision. Des
> techniques de classification, interprétation, correction permettent aux
> spécialistes de converger vers un produit de qualité.  Et bien sûr toutes
> ces avancées technologiques et l'accès éventuel à des profanes bousculent
> les habitudes tout comme les véhicules sans conducteur :)
>
> Même si Statistique Canada fournit à OSM un fichier produit par des
> spécialistes, il sera nécessaire ensuite d'établir une procédure d'import,
> de fusionner / aligner avec les données existantes et de corriger.
>
> Et ouvront la porte au Futur! Une autre avenue, c'est l'accès aux profanes
> que nous sommes à des outils semi-automatiques pour faciliter la
> digitalisation de différents éléments tels immeubles, routes et rivières.
> Je ne connais pas l'historique des expériences d'utilisation de tels
> outils. Mais on peut remonter en 2011, où on parlait d'un outil de
> détection de route. Divers articles traitent aussi de ce sujet.
> https://alastaira.wordpress.com/2011/02/04/automatic-road-
> detection-using-bing-maps-imagery/
> https://gis.stackexchange.com/questions/77876/is-there-a-
> tool-that-performs-automatic-recognition-of-buildings
>
>
> Facebook a aussi expérimenté des outils de reconnaissance d'image en
> Thaîlande récemment. Selon les plaintes de certains contributeurs, les
> données ont été ajoutées à OSM sans valider suffisamment avec la réalité
> sur le terrain.
>
> Je pense qu'il serait intéressant pour les contributeurs expérimentés
> d'avoir accès à des outils semi-automatisés facilitant dans JOSM par
> exemple le tracé d'immeubles, routes, cours d'eau, etc. Pour un cours d'eau
> par exemple, je déplace le curseur de la souris, et les contours et le
> centre de la rivière sont tracés automatiquement. Ou encore le contour d'un
> lac est tracé.
>
>
> Pierre
>
>
> Le lundi 29 janvier 2018 15:15:59 HNE, john whelan 
> a écrit :
>
>
> ·
>
>
> *NRCan is working on a methodology to extract building footprints,
> including topographic elevation and height attributes, from LiDAR*
>
>
> *Traditionally OSM has not been happy with this sort of thing.  The
> accuracy can be poor.*
>
>
> *We probably need to think about this since the BC2020i project had this
> mentioned and Stats Can has given it a mention also.  I'm not promoting it
> nor saying its bad but it will almost certainly be raised shortly.*
>
>
> *First if an import was done using this data who would be the local group
> to approve it?  I suspect because it covers the entire country it would be
> the talk-ca group.  The date would come through the TB portal so licensing
> is not an issue.  Or it could be split into regions with regional local
> groups making decisions.*
>
>
> *The other very big question is to do with data quality.  So far nothing
> that is machine learnt from imagery has consistently met the expectations
> of OpenStreetMap.*
>
>
> *Note to Pierre I'm not sure if you are on the talk-ca mailing list but
> any feedback you might have on the data quality side would be welcome and
> will be shared amongst the group.*
>
>
> *Thoughts?*
>
> *Thanks John*
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-GB] Dev support

[Rob Nickerson]

Hi all,

We had a request on twitter for some support in building a web based editor
to add tree data to OSM. Stuart has the experience to do the front end but
needs a leg up on the back-end.

Is there a suitable person/group/place that I could point him too? I could
point him in the direction of the OSM London meetings but being based in
Yorkshire (part time at ODI Leeds) this may not be an option.

https://twitter.com/astronomyblog/status/957256567044427776

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

[Talk-GB] Help remembering how to ...

[Lester Caine]

It has been a while and my notes and crib sheets seem to be messed up.

Have JOSM running with ImportImagePlugin and I have a tif file with a 28 
pixel per meter scale, and the lat and long for the top left corner, but 
I'm obviously not putting the right numbers in the world file which I 
have done in the past and fine tuned position once loaded so has 
something changed, or have I just got the wrong data. I'm fairly sure I 
also had a Linux program that helped me play with the values but having 
brain freeze at the moment ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-ca] using image recognition to create building foot prints.

[Pierre Béland]

Bonjour John
Les spécialistes d'imagerie produisent des couches de données assez précises à 
partir d'imagerie LIDAR ou de drones, incluant, immeubles, cours d'eau et 
occupation du sol. Ces images offrent qualité et précision. Des techniques de 
classification, interprétation, correction permettent aux spécialistes de 
converger vers un produit de qualité.  Et bien sûr toutes ces avancées 
technologiques et l'accès éventuel à des profanes bousculent les habitudes tout 
comme les véhicules sans conducteur :)
Même si Statistique Canada fournit à OSM un fichier produit par des 
spécialistes, il sera nécessaire ensuite d'établir une procédure d'import, de 
fusionner / aligner avec les données existantes et de corriger. 
Et ouvront la porte au Futur! Une autre avenue, c'est l'accès aux profanes que 
nous sommes à des outils semi-automatiques pour faciliter la digitalisation de 
différents éléments tels immeubles, routes et rivières. Je ne connais pas 
l'historique des expériences d'utilisation de tels outils. Mais on peut 
remonter en 2011, où on parlait d'un outil de détection de route. Divers 
articles traitent aussi de ce sujet.
https://alastaira.wordpress.com/2011/02/04/automatic-road-detection-using-bing-maps-imagery/https://gis.stackexchange.com/questions/77876/is-there-a-tool-that-performs-automatic-recognition-of-buildings


Facebook a aussi expérimenté des outils de reconnaissance d'image en Thaîlande 
récemment. Selon les plaintes de certains contributeurs, les données ont été 
ajoutées à OSM sans valider suffisamment avec la réalité sur le terrain.
Je pense qu'il serait intéressant pour les contributeurs expérimentés d'avoir 
accès à des outils semi-automatisés facilitant dans JOSM par exemple le tracé 
d'immeubles, routes, cours d'eau, etc. Pour un cours d'eau par exemple, je 
déplace le curseur de la souris, et les contours et le centre de la rivière 
sont tracés automatiquement. Ou encore le contour d'un lac est tracé.
 
Pierre 
 

Le lundi 29 janvier 2018 15:15:59 HNE, john whelan  
a écrit :  
 
 ·    NRCan is working on a methodology to extract building  footprints, 
including topographic elevation and height attributes, from LiDAR


Traditionally OSM has not been happy with this sort of thing.  The accuracy can 
be poor.

We probably need to think about this since the BC2020i project had this 
mentioned and Stats Can has given it a mention also.  I'm not promoting it nor 
saying its bad but it will almost certainly be raised shortly.

First if an import was done using this data who would be the local group to 
approve it?  I suspect because it covers the entire country it would be the 
talk-ca group.  The date would come through the TB portal so licensing is not 
an issue.  Or it could be split into regions with regional local groups making 
decisions.

The other very big question is to do with data quality.  So far nothing that is 
machine learnt from imagery has consistently met the expectations of 
OpenStreetMap.

Note to Pierre I'm not sure if you are on the talk-ca mailing list but any 
feedback you might have on the data quality side would be welcome and will be 
shared amongst the group.

Thoughts?

Thanks John
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-it] Violazione OSM

[Maurizio Napolitano]

> comunque è impossibile, proprio non ci credo, che per fatti loro hanno
> trovato TUTTI gli stessi "miei" toponomi scritti allo stesso identico modo e
> posizionati nello stesso punto preciso ;-)

In teoria i toponimi dovrebbero essere nomi riconosciuti da tutti,
quindi è giusto che siano uguali.
Quello che invece è impossibile è che abbiano le stesse coordinate.
Più che altro perchè il punto che identifica un toponimo è sempre
circoscritto ad un intorno che può essere più o meno grande in
relazione a ciò che il toponimo rappresenta.
Pertanto se le coordinate concidono, allora non c'è ombra di dubbio
che la banca dati è la stessa.

Sarebbe importante dimostrare questo pescando le coordinate.
 

  https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank">https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif;
alt="" width="46" height="29" style="width: 46px; height: 29px;"
/>
Mail priva di virus. https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail;
target="_blank" style="color: #4453ea;">www.avast.com   




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

Re: [Talk-it] Violazione OSM

[Alessandro Palmas]

  
  
Il 29/01/2018 21:25, demon.box ha
  scritto:


  Alessandro Palmas wrote

  
Ciao,
non hanno ancora stampato il materiale, giusto?

Le mappe sarebbero queste (ne linko una a caso)?
http://www.comune.brescia.it/servizi/ambienteeverde/VerdeRetIdricoMinore/parcodellecolline/Documents/A3_15000_Brescia_Maddalena_nord_07.pdf

  
  
ciao, no questa non è la mappa nuova. quella che hai linkato è una delle
vecchie mappe su base CTR mentre quella nuova è della 4Land.

comunque è già stata stampata soltanto che non sono ancora pronti a
distribuirla...

--enrico


Bè, con 20€ di timbro e un minimo di buona volontà possono ancora
recuperare.
  


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

Re: [Talk-ca] using image recognition to create building foot prints.

[Stewart C. Russell]

On 2018-01-29 03:15 PM, john whelan wrote:
> ·*NRCan is working on a methodology to extract building 
> footprints, including topographic elevation and height attributes,
> from LiDAR
> 
> * Traditionally OSM has not been happy with this sort of thing.
> The accuracy can be poor.

If you want to take a look at this kind of data, Toronto's 3D massing
data set is derived from LIDAR. It's what we have for building outlines,
and it's not bad at all:
https://www.toronto.ca/city-government/data-research-maps/open-data/open-data-catalogue/locations-and-mapping/#db07630f-252d-f7ae-2dff-8d0b38ec6576

cheers,
 Stewart

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

Re: [Talk-ca] using image recognition to create building foot prints.

[Adam Martin]

Can't speak for the rest of the country as such, but I do know that the
imagery quality in Newfoundland is rather poor. Recognizing building shapes
would technically work, but the result would be poorly aligned boxes, not
accurate house shapes. We also do not have a local working group as far as
I am aware so any importation would need to be brought to the whole list or
such a group created.

On Jan 29, 2018 4:47 PM, "john whelan"  wrote:

> ·
>
>
> *NRCan is working on a methodology to extract building footprints,
> including topographic elevation and height attributes, from LiDAR*
>
>
> *Traditionally OSM has not been happy with this sort of thing.  The
> accuracy can be poor.*
>
>
> *We probably need to think about this since the BC2020i project had this
> mentioned and Stats Can has given it a mention also.  I'm not promoting it
> nor saying its bad but it will almost certainly be raised shortly.*
>
>
> *First if an import was done using this data who would be the local group
> to approve it?  I suspect because it covers the entire country it would be
> the talk-ca group.  The date would come through the TB portal so licensing
> is not an issue.  Or it could be split into regions with regional local
> groups making decisions.*
>
>
> *The other very big question is to do with data quality.  So far nothing
> that is machine learnt from imagery has consistently met the expectations
> of OpenStreetMap.*
>
>
> *Note to Pierre I'm not sure if you are on the talk-ca mailing list but
> any feedback you might have on the data quality side would be welcome and
> will be shared amongst the group.*
>
>
> *Thoughts?*
>
> *Thanks John*
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-it] Violazione OSM

[demon.box]

Alessandro Palmas wrote
> Ciao,
> non hanno ancora stampato il materiale, giusto?
> 
> Le mappe sarebbero queste (ne linko una a caso)?
> http://www.comune.brescia.it/servizi/ambienteeverde/VerdeRetIdricoMinore/parcodellecolline/Documents/A3_15000_Brescia_Maddalena_nord_07.pdf

ciao, no questa non è la mappa nuova. quella che hai linkato è una delle
vecchie mappe su base CTR mentre quella nuova è della 4Land.

comunque è già stata stampata soltanto che non sono ancora pronti a
distribuirla...

--enrico





--
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: [Talk-it] Complesso residenziale

[Luigi Toscano]

Martin Koppenhoefer ha scritto:
> 2018-01-29 0:18 GMT+01:00 Luca Delucchi  >:
> 
> 2018-01-28 19:16 GMT+01:00 Luigi Toscano  >:
> > Per coerenza con quanto detto prima, -1; sarebbe una ripetizione 
> inutile.
> 
> anch'io concordo, sarebbe solo un dato duplicato
> 
> 
> 
> 
> stiamo parlando di un POI "poligonale" (=mappato come way). Posso capire, che
> per tanti casi semplici (un POI a civico, POI non troppo grande oppure
> geometria non interessa al mappatore e mappa come nodo) esiste un workaround
> di unire l'ingresso con il POI e di aggiungere i tags addr, e "funziona" (in
> realtà funziona solo quasi, c'è un problema topologico, nel senso che un POI è
> dentro un edificio, mentre un ingresso è tra edificio e esterno, ma per la
> maggiorparte degli casi di utilizzo non crea problemi pratici). Ma nel caso
> del POI poligonale esteso, come fai a dire che l'indirizzo su quel poligono
> non aggiunge informazioni? Come faccio a capire l'indirizzo di un POI se non è
> esplicitato e ci sono civici ad ogni ingresso e ogni vitrina?

La risposta ovvia e funzionale sarebbero le relazioni, e ancora devo capire
perché incontrano una ingiustificata resistenza.

-- 
Luigi

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

Re: [Talk-it] Violazione OSM

[Alessandro Palmas]

Il 29/01/2018 20:53, demon.box ha scritto:

..

il problema è che in questa nuova mappa ho trovato tutti ma dico tutti i
toponimi che in 8 anni ho faticosamente e minuziosamente caricato in OSM

...


conosco personalmente il Direttore del Parco e sicuramente glie lo farò
notare nei prossimi giorni visto che lo incrocio ogni mattina ;-)

c'è qualcos'altro da fare secondo voi?



Ciao,
non hanno ancora stampato il materiale, giusto?

Le mappe sarebbero queste (ne linko una a caso)?
http://www.comune.brescia.it/servizi/ambienteeverde/VerdeRetIdricoMinore/parcodellecolline/Documents/A3_15000_Brescia_Maddalena_nord_07.pdf

Sul pdf si legge che la base è la CTR Regione Lombardia.

Se conosci il Direttore del Parco avvisalo subito che gli conviene come 
minimo citare OSM. Se poi hanno fatto mischiato i toponimi OSM con 
quelli della CTR la cosa è un pò più grave.


Oltre alle eventuali conseguenze lato OSM anche Regione Lombardia non 
sarebbe molto contenta di vedersi attribuiti dei dati che essa non ha 
mai validato.
Appena puoi dacci un feedback; in caso di problemi vedo se riesco ad 
attivare RL o ERSAF per fare un pò di moral suasion.


Alessandro Ale_Zena_IT

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

[Talk-ca] using image recognition to create building foot prints.

[john whelan]

 ·


*NRCan is working on a methodology to extract building footprints,
including topographic elevation and height attributes, from LiDAR*


*Traditionally OSM has not been happy with this sort of thing.  The
accuracy can be poor.*


*We probably need to think about this since the BC2020i project had this
mentioned and Stats Can has given it a mention also.  I'm not promoting it
nor saying its bad but it will almost certainly be raised shortly.*


*First if an import was done using this data who would be the local group
to approve it?  I suspect because it covers the entire country it would be
the talk-ca group.  The date would come through the TB portal so licensing
is not an issue.  Or it could be split into regions with regional local
groups making decisions.*


*The other very big question is to do with data quality.  So far nothing
that is machine learnt from imagery has consistently met the expectations
of OpenStreetMap.*


*Note to Pierre I'm not sure if you are on the talk-ca mailing list but any
feedback you might have on the data quality side would be welcome and will
be shared amongst the group.*


*Thoughts?*

*Thanks John*
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-it] Violazione OSM

[demon.box]

Andreas Lattmann wrote
> Il problema è che non me lo trova il parco.
> Adesso riprovo. 
> Andreas Lattmann

anch'io ho avuto la stessa difficoltà appena installata l'app ma poi quando
ci sono tornato il giorno dopo la mappa del Parco delle Colline me l'ha
trovata subito.

comunque è impossibile, proprio non ci credo, che per fatti loro hanno
trovato TUTTI gli stessi "miei" toponomi scritti allo stesso identico modo e
posizionati nello stesso punto preciso ;-)

--enrico





--
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: [Talk-it] Violazione OSM

[Andreas Lattmann]

Il problema è che non me lo trova il parco.
Adesso riprovo. 
Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [Talk-it] Violazione OSM

[demon.box]

Andreas Lattmann wrote
> Non puoi mandare un link con foto o altro materiale? Così è più facile
> verificare. 
> Andreas Lattmann

potrò quando avrò la mappa cartacea ma per ora è disponibile soltanto per
gli smartphone.
ciao

--enrico





--
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: [Talk-it] Violazione OSM

[Andreas Lattmann]

Non puoi mandare un link con foto o altro materiale? Così è più facile 
verificare. 
Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

[Talk-it] Violazione OSM

[demon.box]

ciao, la settimana scorsa è stata presentata la nuovissima mappa dei sentieri
del "Parco delle Colline di Brescia", con tanto di pagina intera dedicata
sul principale quotidiano locale.

si tratta di una mappa della 4Land disponibile (a breve) gratuitamente in
versione cartacea è già disponibile invece in versione digitale tramite
l'app Avenza Maps.

dove sta il problema? direte voi

il problema è che in questa nuova mappa ho trovato tutti ma dico tutti i
toponimi che in 8 anni ho faticosamente e minuziosamente caricato in OSM
 
in sostanza questi simpatici signori della 4Land hanno bellamente copiato da
OSM: stessi toponimi nell'identica posizione. saranno almeno 500 ad occhio e
croce...!!

ovviamente OSM non viene citato da nessuna parte, non ho ancora la copia
cartacea ma immagino che non ci sarà nulla nemmeno lì...

conosco personalmente il Direttore del Parco e sicuramente glie lo farò
notare nei prossimi giorni visto che lo incrocio ogni mattina ;-)

c'è qualcos'altro da fare secondo voi?

grazie

--enrico




--
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: [Talk-it] Nomi in forma dialettale

[Andreas Lattmann]

Altro problema che riguarda sempre la mia mail sui nomi dialettali.
Vi invio la domanda posta da un mappatore a cui ho chiesto di togliere le 
virgolette dal name:

"Ho sistemato le virgolette (almeno credo) Rimane qualche caso isolato che si 
configura come situazione particolare e che avrei risolto a modo mio Dimmi cosa 
ne pensi Es.: • se io scrivo - La Pióde dal Cröos - il termine è tutto in 
dialetto e quindi, come mi hai indicato, lo inserisco senza virgolette • 
parimenti se scrivo - Bocchetta di Larécc - il termine è metà in italiano e 
metà in dialetto ma non sussistono conflitti per cui lo inserisco senza 
virgolette • ma se debbo inserire - Baita del Taièe – il termine è ambiguo 
perché la preposizione “del” in italiano è singolare mentre in dialetto è 
plurale (“del” sta per “delle”: sarebbe “delle Tagliate”); in questo caso ho 
ritenuto opportuno mantenere le virgolette a racchiudere la parte dialettale 
per cui ho inserito – Baita “del Taièe” -. Né d’altra parte potrei risolvere il 
problema scrivendo il tutto in dialetto perché sarebbe – Baite del Taièe – e 
“Baite” in dialetto è singolare mentre in italiano è plurale per cui non si 
capirebbe se si tratta di una (se dialetto) o di più baite (se italiano). Che 
casino eh?"

Ed ora che cosa gli rispondo???

Andreas Lattmann
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità. 

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

Re: [Talk-it] Nomi in forma dialettale

[Paolo Monegato]

Il 26/01/2018 19:58, Elena ``of Valhalla'' ha scritto:

On 2018-01-26 at 16:36:07 +0100, Volker Schmidt wrote:

Dove trovo questi codici per i dialetti?
Ho guardato ISO 639-3 ma ho trovato subito un dialetto vicino che manca:
mòcheno

sbaglio o proprio quella pagina dice "ISO 639-3 mhn"?



Si per il mocheno è mhn.

Comunque laddove manchi, dato che comunque sarà una particolare variante 
locale di un altro idioma, metterei il codice del gruppo linguistico 
correlato. Ad esempio un nome in romanesco metterei un "loc_name:it=" 
per distinguerlo dall'eventuale differente name:it dell'italiano standard


ciao
Paolo M

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

Re: [Talk-dk] Busholdepladser

[Michael Andersen]

On mandag den 29. januar 2018 12.35.52 CET Thomas Andersen wrote:
> Kære alle
> 
> Jeg er blevet spurgt om jeg ikke kan smide turistbus-holdepladser ind i OSM
> i en kommune. Altså de steder, som turistbusser dels kan holde og dels kan
> smide aflæse/afhente folk.
> 
> Er der en specifik katagori for dette i OSM, eller hvad foreslår I man gør?

Jeg kan ikke umiddelbart finde en passende kategori og alt hvad jeg kan finde 
af 
referencer til turistbusser er
https://taginfo.openstreetmap.org/keys/tourist_bus (adgangsrettigheder).

Afhængigt af hvad der er brug for vil jeg foreslå at der tilføjes passende 
adgangsrettigheder til p-pladser eller individuelle båse 
(amenity=parking_space).

Sådanne pladser vil ikke blive specielt fremhævet på vores standardkort, så 
derfor vil jeg foreslå:

At disse så findes ved hjælp af f.eks. https://overpass-turbo.eu/s/vxl og 
visualiseres på https://wiki.openstreetmap.org/wiki/UMap, hvis ikke man ønsker 
at lave sin egen rendering på f.eks. https://wiki.openstreetmap.org/wiki/
Mapbox

Jeg kender en rasteplads ved Ribe, der ofte bliver brugt af turistbusser til 
opsamling/afsætning af passagerer der skal på gruppetur sydpå, men det er 
formentlig ikke den slags pladse der tænkes på?


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

Re: [Talk-de] Relationen Radweg gelöscht: Relation 6889944 - [6] Egerradweg

[osm_ww]

Hallo, 

vielen Dank für Eure Hinweise in oben genannter Sache.

Da ich bisher so einen Fall noch nicht erlebt habe und ich auch nur 
gelegentlich bei OSM mitarbeite, habe ich mich erst mal an das Forum gewandt.

Jetzt habe ich aber über das Changeset einen Kommentar geschrieben, den Vorgang 
geschildert und angefragt, warum die Löschungen durchgeführt worden sind.

Vielen Dank für Eure Hilfe und

viele Grüße

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

Re: [Talk-GB] Errors in Street Names in Addresses

[SK53]

Not universally true. Streetname signs in the Boroughs of Gedling and
Rushcliffe actually may show the full postcode. Example here:
https://flic.kr/p/9r747b  . This is both ground
truth & authoritative for postcodes belong to (some) streets :-)

Secondly, OSM mapping is incremental. It is often possible to deduce the
postcode applying to buildings on a street (basically all shorter ones
with, say, under 60 addresses) merely from inspecting the postcode
centroid. Adding the postcode to the street seems reasonable in these
circumstances.

Jerry

On 29 January 2018 at 11:58, David Woolley 
wrote:

> On 29/01/18 11:36, Robert Whittaker (OSM lists) wrote:
>
>> My understanding is that addr:postcode should be used only as part of
>> an address. So if you want to put a postcode on a street (or part of a
>>
>
> As I understand it, postal_code, in a UK context is for the outbound code,
> only, and is most useful in certain cities, where street name have the
> outbound code appended, on the name sign.
>
> On the other hand, sticking the full post code on a road is wrong, because
> it implies that everything on that road has that post code, which is not
> necessarily true, even for short roads, if there is a big user.
>
> For bigger roads, odd and even numbers may have different codes, and you
> cannot normally split the road at the right place without doing a house to
> house survey of the codes.
>
>
> ___
> 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-cz] Taskman pro poštovní schránky

[Miroslav Suchy]

Dne 29.1.2018 v 16:14 r00t napsal(a):
> Asi by taky bylo dobre do popisu prace v taskmanu neco o tomhle pridat, 
> protoze
> ted se to cte tak, ze pokud ve ctverci najdu a opravim vsechny nezelene 
> schranky,
> muzu ho oznacit jako hotovy...

... nebo do ctverce napises "cervena ve Lhote je false-negativ, protoze ve 
skutecnosti neni na namesti ale na kraji obce
u hasicu".

Mirek

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

Re: [Talk-cz] ortofoto mapy.cz

[Matej Lieskovský]

Mně odpověděl na zprávu:

Dobrý den,

Předem bych Vám chtěl velice poděkovat za exemplární péči o
neposkvrněnost OSM. Ortografické fotky ze serveru mapy.cz pro editaci
přímo nepoužívám, jen pro zarovnání snímků DigitalGlobe (bohužel
nutné, jsou špatně zarovnané) a pro následnou vizuální kontrolu mého
díla. K prohlížení materiál z mapy.cz přece je, ne?

Konec citace

Já toho mám teď moc, takže se s ním asi hádat nebudu.

2018-01-29 16:43 GMT+01:00 Jan Martinec :
> Dne 29.1.2018 v 16:23 Lukas Gebauer napsal(a):
>>>
>>> Podival jsem se na Krematora a stale mapuje co muze: Za vcerejsek 20
>>> changesetu,
>>> dneska uz dalsich 20. Do komentare ted dava jenom "..." ale imagery_used
>>> je u
>>> vsech stale mapserver.mapy.cz :(
>>
>>
>> Není to obhajoba tohoto případu, ale něčemu nerozumím, a rád bych
>> našel odpovědi:
>>
>> - Chápu, že se něco nemá kreslit podle zdrojů, které nemají
>> kompatibilní licenci. Ale co když to kreslím podle kompatibilního
>> zdroje, ale třeba na ty mapy.cz se kouknu jen pro kontrolu, jestli je
>> kompatibilni zdroj verohodny?
>
> Ahoj,
>
> De iure ani to ne - tím směrem leží právní houština zjišťování, jestli je to
> teda už podstatné užití díla a blablabla (nejsem právník), kde tvůrce té
> jiné mapy bude tahat za delší konec provazu; prakticky z toho vycházejí dva
> modely: osmácký a wikimapistický. OSM jede "nic než data ze zdrojů, které
> jsou prokazatelně povoleny" a wikimapia "berem cokoli, dyť co nám kdo může."
> Střední cesta "jen jedním očkem na chvilku nakouknu" je ve skutečnosti ta
> druhá cesta - data v OSM nesmí být odvozena z nekompatibilních map, ani
> trošku. (Je zřejmě možné ty mapy okem porovnat - "ha, nový silnice už jsou
> tady měsíc a tam ještě ne", ale nemá jít o přenos informací jedním nebo
> druhým směrem, tj. to porovnání nemá být zdrojem pro mapování - a už se
> boříme do právničtinských nejistot)
>
>> (Napriklad kreslím cestu podle své GPS stopy, a tady jsem si
>> poznamenal neco... vzpominam, ze to mel byt most. Tak se kouknu na
>> orto, jesti si pamatuji dobre, ze tam mel byt most...)
>
> Co zkusit Mapillary? Z toho je povoleno do OSM odvozovat, a právě v takových
> případech mi dobře posloužilo.
>
>>
>> - pokud neco v iD kreslim, a na chvili se prepnu na jiny podklad,
>> zaznamena se to do imagery_used?
>
> To je pointa tagu imagery_used - "jaký podklad byl zobrazen". Zjistit,
> jestli z toho podkladu uživatel něco opravdu použil, to je úloha dalece
> přesahující možnosti současné techniky.
>
>>
>> - nezpusobi to zbytecne falesne poplachy pri honu na carodejnice?
>
> Hon na čarodějnice, tj. uměle vykonstruovaný proces, vedený k předem
> vytyčenému rozsudku? Asi nerozumím výrazu, můžeš vysvětlit?
>>
>>
>> Lukas
>>
>
> Zdar,
> Honza "Piškvor" Martinec
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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

Re: [Talk-cz] ortofoto mapy.cz

[Jan Martinec]

Dne 29.1.2018 v 16:23 Lukas Gebauer napsal(a):

Podival jsem se na Krematora a stale mapuje co muze: Za vcerejsek 20 changesetu,
dneska uz dalsich 20. Do komentare ted dava jenom "..." ale imagery_used je u
vsech stale mapserver.mapy.cz :(


Není to obhajoba tohoto případu, ale něčemu nerozumím, a rád bych
našel odpovědi:

- Chápu, že se něco nemá kreslit podle zdrojů, které nemají
kompatibilní licenci. Ale co když to kreslím podle kompatibilního
zdroje, ale třeba na ty mapy.cz se kouknu jen pro kontrolu, jestli je
kompatibilni zdroj verohodny?

Ahoj,

De iure ani to ne - tím směrem leží právní houština zjišťování, jestli 
je to teda už podstatné užití díla a blablabla (nejsem právník), kde 
tvůrce té jiné mapy bude tahat za delší konec provazu; prakticky z toho 
vycházejí dva modely: osmácký a wikimapistický. OSM jede "nic než data 
ze zdrojů, které jsou prokazatelně povoleny" a wikimapia "berem cokoli, 
dyť co nám kdo může." Střední cesta "jen jedním očkem na chvilku 
nakouknu" je ve skutečnosti ta druhá cesta - data v OSM nesmí být 
odvozena z nekompatibilních map, ani trošku. (Je zřejmě možné ty mapy 
okem porovnat - "ha, nový silnice už jsou tady měsíc a tam ještě ne", 
ale nemá jít o přenos informací jedním nebo druhým směrem, tj. to 
porovnání nemá být zdrojem pro mapování - a už se boříme do 
právničtinských nejistot)



(Napriklad kreslím cestu podle své GPS stopy, a tady jsem si
poznamenal neco... vzpominam, ze to mel byt most. Tak se kouknu na
orto, jesti si pamatuji dobre, ze tam mel byt most...)
Co zkusit Mapillary? Z toho je povoleno do OSM odvozovat, a právě v 
takových případech mi dobře posloužilo.




- pokud neco v iD kreslim, a na chvili se prepnu na jiny podklad,
zaznamena se to do imagery_used?
To je pointa tagu imagery_used - "jaký podklad byl zobrazen". Zjistit, 
jestli z toho podkladu uživatel něco opravdu použil, to je úloha dalece 
přesahující možnosti současné techniky.




- nezpusobi to zbytecne falesne poplachy pri honu na carodejnice?
Hon na čarodějnice, tj. uměle vykonstruovaný proces, vedený k předem 
vytyčenému rozsudku? Asi nerozumím výrazu, můžeš vysvětlit?


Lukas



Zdar,
Honza "Piškvor" Martinec

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

Re: [Talk-it] Complesso residenziale

[Martin Koppenhoefer]

2018-01-29 0:18 GMT+01:00 Luca Delucchi :

> 2018-01-28 19:16 GMT+01:00 Luigi Toscano :
> > Per coerenza con quanto detto prima, -1; sarebbe una ripetizione inutile.
>
> anch'io concordo, sarebbe solo un dato duplicato




stiamo parlando di un POI "poligonale" (=mappato come way). Posso capire,
che per tanti casi semplici (un POI a civico, POI non troppo grande oppure
geometria non interessa al mappatore e mappa come nodo) esiste un
workaround di unire l'ingresso con il POI e di aggiungere i tags addr, e
"funziona" (in realtà funziona solo quasi, c'è un problema topologico, nel
senso che un POI è dentro un edificio, mentre un ingresso è tra edificio e
esterno, ma per la maggiorparte degli casi di utilizzo non crea problemi
pratici). Ma nel caso del POI poligonale esteso, come fai a dire che
l'indirizzo su quel poligono non aggiunge informazioni? Come faccio a
capire l'indirizzo di un POI se non è esplicitato e ci sono civici ad ogni
ingresso e ogni vitrina?

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

Re: [Talk-cz] ortofoto mapy.cz

[Lukas Gebauer]

> Podival jsem se na Krematora a stale mapuje co muze: Za vcerejsek 20 
> changesetu,
> dneska uz dalsich 20. Do komentare ted dava jenom "..." ale imagery_used je u
> vsech stale mapserver.mapy.cz :(

Není to obhajoba tohoto případu, ale něčemu nerozumím, a rád bych 
našel odpovědi:

- Chápu, že se něco nemá kreslit podle zdrojů, které nemají 
kompatibilní licenci. Ale co když to kreslím podle kompatibilního 
zdroje, ale třeba na ty mapy.cz se kouknu jen pro kontrolu, jestli je 
kompatibilni zdroj verohodny? 
(Napriklad kreslím cestu podle své GPS stopy, a tady jsem si 
poznamenal neco... vzpominam, ze to mel byt most. Tak se kouknu na 
orto, jesti si pamatuji dobre, ze tam mel byt most...)

- pokud neco v iD kreslim, a na chvili se prepnu na jiny podklad, 
zaznamena se to do imagery_used?

- nezpusobi to zbytecne falesne poplachy pri honu na carodejnice?

Lukas

-- 
Lukas Gebauer.

http://synapse.ararat.cz/ - Ararat Synapse - TCP/IP Lib.
https://www.geoget.cz/ - Geocaching solution


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

Re: [Talk-cz] Taskman pro poštovní schránky

[r00t]

Ahoj,

Tak jsem podle tabulky z CP tady v okoli domapoval schranky co nemely polohu,
jenom nazvy ulic. Dal jsem jim vsem spravne ref, ale ani potom se jako zelene v
POI importeru neobjevily... takze chapu to tak ze POI importer umi zobrazit
jenom ty co maji polohu v datech CP.
Pokud se vyresi to reverzni geokodovani tak to pro vetsinu asi bude stacit
(pokud je to krizeni dvou ulic tak je to vetsinou jednoznacne a celkem presne).
U par jsem ale jako popis videl treba "konecna MHD" a s tim si geo-dekoder 
neporadi.

Pokud ale mame zmapovat celou CR tak to bude chtit nejake lepsi reseni nez
"corrections.csv", at uz co se tyce vlastni korekce tak vizualizace na mape.

Asi by taky bylo dobre do popisu prace v taskmanu neco o tomhle pridat, protoze
ted se to cte tak, ze pokud ve ctverci najdu a opravim vsechny nezelene 
schranky,
muzu ho oznacit jako hotovy...


J


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

Re: [Talk-de] Königreich Württemberg

[Martin Koppenhoefer]

Es gibt mittlerweile doch einige Mapper, die die historischen Grenzen,
zumindest in diesem Fall, gerne gehabt hätten:
https://www.openstreetmap.org/changeset/55669953

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

Re: [Talk-it-lazio] Proposta incontro GeoBirra stasera 29/01/2018 Finnegan Irish Pub.

[FelynX]

Ci sarò


Il 29 gennaio 2018 13:06:20 CET, Martin Koppenhoefer  
ha scritto:
>confermo la mia presenza stasera.
>
>Il 22/2 alla Sapienza sarebbe bello vedere qualche mappatore
>locale/regionale, l'ingresso è libero, ed è la prima volta che abbiamo
>il
>convegno nazionale (OSMit) a Roma (è già la nona edizione).
>
>Ciao,
>Martin

-- 
Felynx. Sorry x brevità causa smartufone___
Talk-it-lazio mailing list
Talk-it-lazio@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-lazio

Re: [Talk-cz] Ohrožení fungování projektu OpenStreetMap

[Pavel Zbytovský]

Ahoj Matěji,

1) zvážil bych možnost napsat přímo tomu zmíněnému uživateli - to je možná
to, co udělá i provozovatel toho fóra.

2) ještě by bylo dobré upozornit, že editor iD ukládá do informace o
podkladovce do changesetu, čili uživatelé budou odhaleni a zbytečně jejich
úpravy vymazány.

3) možná by nebylo špatné se i podívat, kdopak má v součanosti v
`imagery_used` nějaký substring "mapy.cz".. nemáš náhodou u sebe ty
changesety?

Dík
Pavel

On Sat, Jan 27, 2018 at 7:19 PM Matej Lieskovský 
wrote:

> Dobrý den,
>
> našli jsme na Vašem fóru návod*, jak do editoru pro OpenStreetMap
> dostat ortofoto od Mapy.cz. To je docela problém, protože tyto
> ortofoto jsou zveřejněny pod licencí, která nedovoluje jejich použití
> v OSM. Pokoušíme se odstraňovat nelegálně zakreslené části mapy, ale
> je to obtížný proces.
>
> Bylo by prosím možné nějak tento příspěvek upravit? Uvažoval jsem o
> možnosti na něj odpovědět a poukázat na problémy, ale mám jisté
> pochybnosti o tom, že budou uživatelé číst celé vlákno a zbytečně by
> to na něj poukázalo. Asi by stačilo vymazat tu část příspěvku, která
> obsahuje návod na přidání ortofoto od Seznamu a dopsat k tomu důvod
> této změny. Pokud máte jiné návrhy či otázky, neváhejte nás
> kontaktovat na "talk-cz@openstreetmap.org".
>
> Chápu, že se Vám nejspíše nechce omezovat projevy uživatelů Vašeho
> fóra, ale uživatelé následující tento návod můžou způsobit žalobu na
> provozovatele OpenStreetMap a tím ohrozit fungování tohoto projektu.
>
> S přáním přijemného dne,
> Matej Lieskovský
>
> *:
> http://www.ebastlirna.cz/modules.php?name=Forums=viewtopic=915177
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-GB] Errors in Street Names in Addresses

[Lester Caine]

On 29/01/18 13:27, Ed Loach wrote:

All that is left to be sorted out is should all the current
addr:postcode entries logged against the street ways be replaced
with
postal_code



My suggestion is don't worry about it. Data consumers can easily check for 
both, and as soon as the actual addresses be mapped the tag (whichever) should 
be removed from the road anyway. In fact most data consumers are more likely to 
use CodePoint Open as a more complete dataset anyway.


Certainly most of the 'mistakes' I've looked at to reduce the totals on 
'WR' have not thrown up things that actually want changing! Personally 
however my own list of UK postcodes is based on the street elements of 
OSM so as NOT to be reliant on codepoint which does not supply freely 
usable street names? So being able to simply list 'highway' with 
'addr:postcode' is an unrestricted data source. If that now has to be 
changed to or mixed with 'postal_code' then so be it, but 'don't worry' 
is not the right answer when one IS trying to tidy well defined data sets.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-it] Ubicazione defibrillatori

[Matteo Fortini]

Quelli del Comune di Cento su OSM dovrebbero essere tutti aggiornati, li 
ho curati personalmente.


Il 118 dell'Emilia Romagna ha un'app https://www.118er.it/dae/ e gli ho 
chiesto già una volta di aprire i dati, sarebbe molto bello, purtroppo 
non hanno ancora risposto.


Il 29/01/2018 14:26, Dino Michelini ha scritto:
Ho verificato l'unico DAE che avevo mappato nel mio paese... ottimo 
lavoro, grazie!


Il 29.01.2018 14:15 Cascafico Giovanni ha scritto:

Ho aggiunto alcuni layer alla mappa nazionale DAE che sto compilandio 
da scrap in giro. Il layer più affidabile sembra quello del portale 
sanità regione piemonte. Se qualcuno vuol dare un'occhiata [1].
E' possibile usare "access" od altro per indicare se vi sono problemi 
di accessibilità oraria (p. es. il DAE è all'interno di una scuola)?



[1] 
https://umap.openstreetmap.fr/en/map/defibrillatori-dae_192615#10/44.7536/7.5854




Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di 
Internet e hai 200 minuti ed SMS a 12 cent. Passa a Tiscali Mobile! 
http://tisca.li/OPEN7GBFirma




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


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

Re: [Talk-cz] ortofoto mapy.cz

[majka]

Tak to je milé zjištění, které se hodí. A nezbývá, než závidět. Protože o
opendata v ČB jsem ještě nezavadila, pravděpodobně díky průšvihu s IT na
magistrátu.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Taskman pro poštovní schránky

[majka]

Mohla bych zvládnout ty schránky bez souřadnic - počkám na čerstvá data,
projedu tím skriptem a přes reverzní geokódování dotáhnu předběžné
souřadnice toho zbytku. Co si vzpomínám, umí to vrátit i přesnost toho
kódování minimálně na úrovni dům/ulice/obec.

Dala bych pak k dispozici zpátky soubor s doplněnými souřadnicemi +
případně tou přesností + dalšími informacemi.

Ta vlastní databáze není špatný nápad, protože časy výběrů okolních
schránky se změnily už minimálně 3x od chvíle, kdy jsem myslela, že mám
hotovo. Poslední velká změna bylo hromadné zrušení sobotních výběrů
schránek + posunutí výběrů některých schránek v pracovních dnech o cca 10
min. Pokud se nám podaří do OSM dostat ref, nebyl by pak problém to
udržovat aktuální importem, nebo minimálně vyhozením schránek se změnou.

Majka

2018-01-29 12:24 GMT+01:00 Marián Kyral :

>
> No asi by stálo za to to všechno narvat někam do databáze a pak jen
> kontrolovat data a řešit změny. Podobně jako to řeší Petr s daty RÚIANu.
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-lv] izmaiņas jelgavā

[Martins M]

Jā, abās pusēs loka maģistrālei atļautais ir 50km/h.


On 2018.01.29. 15:34, Rihards wrote:

On 2018.01.29. 14:56, Martins M wrote:

Tajā posmā tagad atļautais ir 50km/h. Agrākās ceļazīmes, kas ļāva braukt
ar 70km/h ir novāktas.

aiz loka maģistrāles ? vai tur varam pielikt maxspeed=50 ?


On 2018.01.29. 14:43, Rihards wrote:

On 2017.10.23. 21:28, Rihards wrote:

tā, jelgavnieki, vai šis ir pareizi un vai kartē jāmaina ? :)

http://www.pilsetsaimnieciba.lv/atlautais-brauksanas-atrums-visa-kalnciema-cela-lidz-50-kmh/


paskatījos datos. līdz loka maģistrālei ir 50, tālāk nav vispār.
izskatās, ka vismaz nepareizi nav.



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

Re: [Talk-lv] izmaiņas jelgavā

[Rihards]

On 2018.01.29. 14:56, Martins M wrote:
> Tajā posmā tagad atļautais ir 50km/h. Agrākās ceļazīmes, kas ļāva braukt
> ar 70km/h ir novāktas.

aiz loka maģistrāles ? vai tur varam pielikt maxspeed=50 ?

> On 2018.01.29. 14:43, Rihards wrote:
>> On 2017.10.23. 21:28, Rihards wrote:
>>> tā, jelgavnieki, vai šis ir pareizi un vai kartē jāmaina ? :)
>>>
>>> http://www.pilsetsaimnieciba.lv/atlautais-brauksanas-atrums-visa-kalnciema-cela-lidz-50-kmh/
>>>
>> paskatījos datos. līdz loka maģistrālei ir 50, tālāk nav vispār.
>> izskatās, ka vismaz nepareizi nav.
-- 
 Rihards

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Steve Doerr]

On 29/01/2018 11:36, Robert Whittaker (OSM lists) wrote:


Ah, I see that tagging would create a lot of false positives in my
tool and make it much less useful!

My understanding is that addr:postcode should be used only as part of
an address. So if you want to put a postcode on a street (or part of a
street) then addr:postcode isn't the best tag to use. Instead, there's
a postal_code=* tag defined in the wiki at
https://wiki.openstreetmap.org/wiki/Key:postal_code which would seem
to be more appropriate for this use case.




Maybe. But rather than open up a whole tagging debate and then 
potentially start a retagging exercise, would it make sense as an 
immediate fix for the tool to ignore objects with a highway tag?


--
Steve

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


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

Re: [Talk-it] Ubicazione defibrillatori

[Dino Michelini]

  Ho verificato l'unico DAE che avevo mappato nel mio paese... ottimo
lavoro, grazie!

Il 29.01.2018 14:15 Cascafico Giovanni ha scritto: 

>
Ho aggiunto alcuni layer alla mappa nazionale DAE che sto compilandio da
scrap in giro. Il layer più affidabile sembra quello del portale sanità
regione piemonte. Se qualcuno vuol dare un'occhiata [1]. 
> E' possibile
usare "access" od altro per indicare se vi sono problemi di
accessibilità oraria (p. es. il DAE è all'interno di una scuola)?
> 
>
[1]
https://umap.openstreetmap.fr/en/map/defibrillatori-dae_192615#10/44.7536/7.5854
[1]
  


Con Mobile Open 7 GB a 9 euro/4 sett navighi veloce con 7 GB di Internet e hai 
200 minuti ed SMS a 12 cent. Passa a Tiscali Mobile! 
http://tisca.li/OPEN7GBFirma

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Ed Loach]

> All that is left to be sorted out is should all the current
> addr:postcode entries logged against the street ways be replaced
> with
> postal_code 

My suggestion is don't worry about it. Data consumers can easily check for 
both, and as soon as the actual addresses be mapped the tag (whichever) should 
be removed from the road anyway. In fact most data consumers are more likely to 
use CodePoint Open as a more complete dataset anyway.

Ed


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

Re: [Talk-it] Ubicazione defibrillatori

[Cascafico Giovanni]

Ho aggiunto alcuni layer alla mappa nazionale DAE che sto compilandio da
scrap in giro. Il layer più affidabile sembra quello del portale sanità
regione piemonte. Se qualcuno vuol dare un'occhiata [1].

E' possibile usare "access" od altro per indicare se vi sono problemi di
accessibilità oraria (p. es. il DAE è all'interno di una scuola)?


[1]
https://umap.openstreetmap.fr/en/map/defibrillatori-dae_192615#10/44.7536/7.5854
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] ortofoto mapy.cz

[Jan Macura]

Ahoj,

2018-01-29 11:14 GMT+01:00 majka :

> Pokud vím, tak "české" letecké snímky v nějaké podobě má k dispozici jen
> Praha, všichni ostatní jsou odkázaní na Digital Globe / Esri / Bing.
>

..a Plzeň. Akorát, že všechny letecký snímky jsou schovaný v pitomý
Marushce a ke zdroji se stejně nedá dostat...
https://opendata.plzen.eu/dataset/gis-rastrovy-podklad-letecke-snimky-letecke-snimky-2002/


Btw, na wiki to asi furt není, ale všechny data od města Plzně
 jsou už nějakou dobu CC-0,
takže plně k použití v OSM.

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Mark Goodge]

On 29/01/2018 12:38, Lester Caine wrote:


UK post codes are based on the postmans walk, so follow the footpaths 
that a postman can follow to deliver mail. Yes a street may have a 
different postcode on each side, and long roads are broken down into 
smaller blocks each with it's own postcode. One rule for postcodes is 
that each will only cover one primary street name and so ignoring the 
'postal address file', postcodes ARE essentially a list of streets.


For residential streets, that's generally true (although there are 
exceptions). It's not at all a reliable guide in commercial areas, 
though, where a significant number of properties will have large user 
postcodes of their own.


Mark

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

Re: [Talk-lv] izmaiņas jelgavā

[Martins M]

Tajā posmā tagad atļautais ir 50km/h. Agrākās ceļazīmes, kas ļāva braukt 
ar 70km/h ir novāktas.



On 2018.01.29. 14:43, Rihards wrote:

On 2017.10.23. 21:28, Rihards wrote:

tā, jelgavnieki, vai šis ir pareizi un vai kartē jāmaina ? :)

http://www.pilsetsaimnieciba.lv/atlautais-brauksanas-atrums-visa-kalnciema-cela-lidz-50-kmh/

paskatījos datos. līdz loka maģistrālei ir 50, tālāk nav vispār.
izskatās, ka vismaz nepareizi nav.



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

Re: [Talk-at] Neighbourhoods in Wien

[Kevin Kofler]

Friedrich Volkmann wrote:
> Das Problem mit vergessenen Namen betrifft nicht nur Siedlungen, sondern
> auch Flurnamen, Namen von Bergen, Tälern, Wäldern, Wiesen, Bächen,
> Steigen, sogar Eisenbahnen (z.B. Innere Aspangbahn, siehe
> http://www.openstreetmap.org/way/27798063/history).

Bzgl. Bergen fällt mir da der Gipfel bei der Schwabenwiese ein, wo im 
franziszeischen Kataster der Name "Handleinsberg" aufscheint, auf einer 
anderen historischen Karte auf wien.at habe ich "Handelsberg" gelesen, 
offiziell hat der Gipfel keinen Namen. Da gab es schon Revert-Wars zwischen 
dem oder den Befürworter(n) eines Phantasienamen (offenbar eine Benennung 
durch einen Beitragenden nach sich selbst), den Befürwortern von 
"Handleinsberg" und denen, die den Gipfel ganz namenlos sehen wollen. 
Derzeit ist kein Name eingetragen.

Stefan Nagy wrote:
> Wenn du von Flurnamen, Namen von Bergen, Tälern, Wäldern, Wiesen,
> Bächen, Steigen etc. schreibst, dann ist das etwas völlig anderes. Ich
> gehe davon aus, dass die Flur, der Berg, das Tal, die Wälder, Wiesen,
> Bäche, Steige nach wie vor da sind. Wenn die ehemalige Flur jetzt eine
> Ansammlung von Kreisverkehren, Parkplätzen und Hofer-, Billa-, OMV-,
> usw. usf. Filialen ist, dann würde ich wieder meinen Standpunkt
> vertreten: Dann ist die Flur tot. Das Shopping-Paradies kann sich
> natürlich gern des alten Namens bedienen – dann ist er wieder da. Das
> ändert aber nichts daran, dass die Flur tot ist.

Genau das ist aber in Nikolsdorf nicht passiert, da sehe ich auf der Karte 
keinen einzigen Kreisverkehr oder Parkplatz und nur einen Diskonter, der 
nicht wesentlich größer ist als andere Filialen überall in Wien.

Die Umgebung mitten in Margareten würde sich auch nicht für derartige 
Konstruktionen eignen, das Problem betrifft eher ländliche Gemeinden bzw. in 
Wien höchstens Gegenden am Stadtrand wie das von Friedrich Volkmann erwähnte 
Rothneusiedl.

> Im verlinkten Fehlerbericht erwähnt jemand, dass die Ortschaftsgrenzen
> fehlen. Ich kenne die örtlichen Katastralgemeindegrenzen nicht –
> vielleicht entsprechen die wirklich den gewünschten Ortschaftsgrenzen…
> 
> Auf der Wikipedia steht zu dem Thema:
> 
> "Nicht zu verwechseln mit den Katastralgemeinden sind die Ortschaften
> oder Orte, ursprünglich eine Ansammlung von Häusern, die durch eine
> gemeinsame Konskriptionsnummerierung zusammengefasst wurden (also
> Adressbereiche). Die Begründung einer Ortschaft – immer als
> Siedlungsraum – kann eine Katastralgemeinde sein, ist es aber nicht
> zwingend: In einer Katastralgemeinde können auch mehrere Ortschaften
> liegen, oder umgekehrt, oder die beiden Systeme keinen Zusammenhang
> haben. In manchen Bundesländern sind in weiten Bereichen
> Katastralgemeindegliederung und Ortschaftsgliederung bis heute
> übereinstimmend, in Niederösterreich etwa werden für die allgemeine
> Ortsgliederung vornehmlich die Katastralgemeinden angegeben, in anderen
> Bundesländern die Ortschaften. In Tirol und Vorarlberg bezeichnet man
> übereinstimmende Katastralgemeinden und Ortschaften meist als
> Fraktion." (siehe https://de.wikipedia.org/wiki/Katastralgemeinde#Katas
> tralgemeinde_und_Ort(schaft)
> 
> Wäre es angesichts dessen nicht sinnvoller, Ortschaften (bzw.
> Ortsteile) als boundary=administrative + admin_level=10 einzutragen und
> Katastralgemeinden mit admin_level=11?

Zur Situation im Burgenland (auf das sich der oben erwähnte Fehlerbericht 
bezieht) kann ich nichts sagen, für Wien gilt aber:
* Innenbezirke: Katastralgemeinde = Bezirk (mit geringfügigen Abweichungen).
  Eine Katastralgemeinde besteht aus mehreren Grätzeln bzw. historischen
  Ortschaften. Die von dir vorgeschlagenen "admin_level"s wären da genau
  verkehrt. Und wirklich benötigt werden die Katastralgemeinden da auch eher
  selten (weil sie fast deckungsgleich mit den Bezirken sind), aber sie sind
  halt der Vollständigkeit halber eingetragen.
* Außenbezirke: Katastralgemeinde = historische Ortschaft. Da ist eine
  Unterscheidung überhaupt nicht sinnvoll.

In Nikolsdorf gilt wie von dir bereits erwähnt die erste Situation, die 
Katastralgemeinde ist die KG Margarethen, die dem Bezirk Margareten (sowie 
genau 1 ha im Bezirk Mariahilf) entspricht.

Kevin Kofler


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

Re: [Talk-it] Numero civico e basta

[Andrea Musuruane]

Ciao,

2018-01-29 13:02 GMT+01:00 Martin Koppenhoefer :

>
>
> 2018-01-29 12:43 GMT+01:00 Martin Koppenhoefer :
>
>> 2018-01-29 10:35 GMT+01:00 Andrea Musuruane 
>>
>>>
>>> *Se un indirizzo è associato a un'area di circolazione (via, piazza,
>>> ecc) bisognerà inserire questa informazione nel tag addr:street=* (o in
>>> alternativa bisognerà utilizzare le relazioni "street" e
>>> "associatedStreet"). *
>>>
>>
>>
>> Questo non è scritto molto bene nella wiki, perché le relazioni "street"
>> e "associatedStreet" sono alternative soltanto nel caso che il mappatore è
>> il primo a mappare quei civici, invece quando si tratta di un posto con
>> mappatura pre-esistente, queste relazioni possono essere _aggiunte_ senza
>> però rimuovere i tag addr:street ecc. già esistenti.
>> (cfr. https://wiki.openstreetmap.org/wiki/Relation:street )
>>
>
>
>
> questo, perché entrambe le relazioni sono già fallite, sopratutto per la
> "street" si potrebbe anche scrivere esplicitamente nel wiki, mentre la
> associatedStreet ancora si muove un pochino. Pratticamente type=street non
> è cresciuto dal 2011, e type=associatedStreet (utilizzato 10-20 volte di
> più) cresce meno veloce di highway=residential. Attualmente ci sono 40
> millioni di residential e 250.000 associatedStreet. Nel 2015 durante una
> votazione informale si è dimostrato che da 100 partecipanti, la metà era
> per e l'altra metà contro queste relazioni.
>

Queste informazioni non sono scritte nella pagina Addresses in inglese, la
cui traduzione è stata inserita nella pagina italiana:
https://wiki.openstreetmap.org/wiki/IT:Addresses#Utilizzo_delle_relazioni

Quindi, a questo riguardo, ti consiglio di spostare sui gruppi
internazionali la discussione.

Ciao,

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

Re: [Talk-lv] izmaiņas jelgavā

[Rihards]

On 2017.10.23. 21:28, Rihards wrote:
> tā, jelgavnieki, vai šis ir pareizi un vai kartē jāmaina ? :)
> 
> http://www.pilsetsaimnieciba.lv/atlautais-brauksanas-atrums-visa-kalnciema-cela-lidz-50-kmh/

paskatījos datos. līdz loka maģistrālei ir 50, tālāk nav vispār.
izskatās, ka vismaz nepareizi nav.
-- 
 Rihards

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Lester Caine]

(Send to pigging list ...)

On 29/01/18 11:58, David Woolley wrote:

On 29/01/18 11:36, Robert Whittaker (OSM lists) wrote:

My understanding is that addr:postcode should be used only as part of
an address. So if you want to put a postcode on a street (or part of a


As I understand it, postal_code, in a UK context is for the outbound 
code, only, and is most useful in certain cities, where street name have 
the outbound code appended, on the name sign.


On the other hand, sticking the full post code on a road is wrong, 
because it implies that everything on that road has that post code, 
which is not necessarily true, even for short roads, if there is a big 
user.


For bigger roads, odd and even numbers may have different codes, and you 
cannot normally split the road at the right place without doing a house 
to house survey of the codes.


UK post codes are based on the postmans walk, so follow the footpaths 
that a postman can follow to deliver mail. Yes a street may have a 
different postcode on each side, and long roads are broken down into 
smaller blocks each with it's own postcode. One rule for postcodes is 
that each will only cover one primary street name and so ignoring the 
'postal address file', postcodes ARE essentially a list of streets.


Two new estates are going up either side of here and both currently have 
plot numbers for selling the houses, but they will be replaced with new 
road names and house numbers which the council will allocate, and then 
the post office will add new postcodes to those new road names.


All that is left to be sorted out is should all the current 
addr:postcode entries logged against the street ways be replaced with 
postal_code ... that should probably have been used originally, bu this 
material is ONLY relevant to the addr: group of tags ... except most sat 
nav's these days understand a postcode better than a street name.


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

[Talk-lv] dzeramā ūdens vietas rīgā

[Rihards]

https://www.riga.lv/lv/news/kur-riga-atrodas-pumpji-ar-bezmaksas-dzeramo-udeni?11531

te gan nav vietas, tikai aptuvenas adreses. vai mums kāds no šiem ir
iezīmēts ?
-- 
 Rihards

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

Re: [Talk-it-lazio] Digest di Talk-it-lazio, Volume 64, Numero 6

[Ubaldo Musco]

Ciao a tutti,
salvo imprevisti dell’ultimo momento ci sarò anch’io
ciao a tutti

Ubaldo

> Il giorno 29 gen 2018, alle ore 13:00, 
> talk-it-lazio-requ...@openstreetmap.org 
>  ha scritto:
> 
> Invia le richieste di iscrizione alla lista Talk-it-lazio
> all'indirizzo
>   talk-it-lazio@openstreetmap.org 
> 
> Per iscriverti o cancellarti attraverso il web, visita
>   https://lists.openstreetmap.org/listinfo/talk-it-lazio 
> 
> oppure, via email, manda un messaggio con oggetto `help' all'indirizzo
>   talk-it-lazio-requ...@openstreetmap.org 
> 
> 
> Puoi contattare la persona che gestisce la lista all'indirizzo
>   talk-it-lazio-ow...@openstreetmap.org
> 
> Se rispondi a questo messaggio, per favore edita la linea dell'oggetto
> in modo che sia più utile di un semplice "Re: Contenuti del digest
> della lista Talk-it-lazio..."
> Argomenti del Giorno:
> 
>   1. Proposta incontro GeoBirra stasera 29/01/2018Finnegan Irish
>  Pub. (pelatom)
> 
> Da: pelatom 
> Oggetto: [Talk-it-lazio] Proposta incontro GeoBirra stasera 29/01/2018 
> Finnegan Irish Pub.
> Data: 29 gennaio 2018 12:03:18 CET
> A: talk-it-lazio@openstreetmap.org
> 
> 
> Ciao a tutti,
> mi rendo conto che mi sono svegliato all'ultimo momento, ma stasera
> riusciamo ad incontrarci?
> 
> C'è l'incontro del 22/01 e magari potremmo accordarci per qualche workshop
> del GFoss
> 
> Per ora siamo io e Martin (salvo imprevisti), e spero riesca ad accodarsi
> qualcun altro.
> La location del  Finnegan Irish Pub, a Monti
>    a me piace, quindi
> propongo lì attorno le 20:00.
> C'è il wifi ed alle brutte mi metto a mappare.
> 
> 
> 
> 
> -
> 
> 
> M.P.
> --
> Sent from: http://gis.19327.n8.nabble.com/Lazio-f5372285.html
> 
> 
> 
> 
> ___
> Talk-it-lazio mailing list
> Talk-it-lazio@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-lazio

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Paul Berry]

>  On the other hand, sticking the full post code on a road is wrong,
because it implies that everything on that road has that post code, which
is not necessarily true, even for short roads, if there is a big user.

But on roads where that *is* true, which granted might not be many, I have
done so (and I suspect others have).

Also, in terms of address density a short urban road is equivalent to a
long rural one. My postcode maps to a road 1.5 miles long, allocated to
properties on both sides :) For every rule...

Regards,
*Paul*

On 29 January 2018 at 11:58, David Woolley 
wrote:

> On 29/01/18 11:36, Robert Whittaker (OSM lists) wrote:
>
>> My understanding is that addr:postcode should be used only as part of
>> an address. So if you want to put a postcode on a street (or part of a
>>
>
> As I understand it, postal_code, in a UK context is for the outbound code,
> only, and is most useful in certain cities, where street name have the
> outbound code appended, on the name sign.
>
> On the other hand, sticking the full post code on a road is wrong, because
> it implies that everything on that road has that post code, which is not
> necessarily true, even for short roads, if there is a big user.
>
> For bigger roads, odd and even numbers may have different codes, and you
> cannot normally split the road at the right place without doing a house to
> house survey of the codes.
>
>
>
> ___
> 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-it] Numero civico e basta

[Martin Koppenhoefer]

2018-01-29 12:43 GMT+01:00 Martin Koppenhoefer :

> 2018-01-29 10:35 GMT+01:00 Andrea Musuruane 
>
>>
>> *Se un indirizzo è associato a un'area di circolazione (via, piazza, ecc)
>> bisognerà inserire questa informazione nel tag addr:street=* (o in
>> alternativa bisognerà utilizzare le relazioni "street" e
>> "associatedStreet"). *
>>
>
>
> Questo non è scritto molto bene nella wiki, perché le relazioni "street" e
> "associatedStreet" sono alternative soltanto nel caso che il mappatore è il
> primo a mappare quei civici, invece quando si tratta di un posto con
> mappatura pre-esistente, queste relazioni possono essere _aggiunte_ senza
> però rimuovere i tag addr:street ecc. già esistenti.
> (cfr. https://wiki.openstreetmap.org/wiki/Relation:street )
>



questo, perché entrambe le relazioni sono già fallite, sopratutto per la
"street" si potrebbe anche scrivere esplicitamente nel wiki, mentre la
associatedStreet ancora si muove un pochino. Pratticamente type=street non
è cresciuto dal 2011, e type=associatedStreet (utilizzato 10-20 volte di
più) cresce meno veloce di highway=residential. Attualmente ci sono 40
millioni di residential e 250.000 associatedStreet. Nel 2015 durante una
votazione informale si è dimostrato che da 100 partecipanti, la metà era
per e l'altra metà contro queste relazioni.

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

Re: [Talk-it] Numero civico e basta

[Martin Koppenhoefer]

2018-01-29 10:35 GMT+01:00 Andrea Musuruane 

>
> *Se un indirizzo è associato a un'area di circolazione (via, piazza, ecc)
> bisognerà inserire questa informazione nel tag addr:street=* (o in
> alternativa bisognerà utilizzare le relazioni "street" e
> "associatedStreet"). *
>


Questo non è scritto molto bene nella wiki, perché le relazioni "street" e
"associatedStreet" sono alternative soltanto nel caso che il mappatore è il
primo a mappare quei civici, invece quando si tratta di un posto con
mappatura pre-esistente, queste relazioni possono essere _aggiunte_ senza
però rimuovere i tag addr:street ecc. già esistenti.
(cfr. https://wiki.openstreetmap.org/wiki/Relation:street )

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

[Talk-dk] Busholdepladser

[Thomas Andersen]

Kære alle

Jeg er blevet spurgt om jeg ikke kan smide turistbus-holdepladser ind i OSM
i en kommune. Altså de steder, som turistbusser dels kan holde og dels kan
smide aflæse/afhente folk.

Er der en specifik katagori for dette i OSM, eller hvad foreslår I man gør?


-- 
Med Venlig Hilsen / Regards

cand.scient in geography and geoinformatics
Thomas Kristian Andersen
mobile: + 45 2083 1505 (DK)
mail: thomas.kristian.ander...@gmail.com

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

Re: [Talk-cz] Taskman pro poštovní schránky

[Marián Kyral]

-- Původní e-mail --
Od: majka 
Komu: OpenStreetMap Czech Republic 
Datum: 29. 1. 2018 12:04:48
Předmět: Re: [Talk-cz] Taskman pro poštovní schránky
"




Neměla ta česká pošta v jednom z importů souřadnice v Křovákovi? Udělala
bych k tomu dávkově překódování a připravila tabulku nebo json.


"



No asi by stálo za to to všechno narvat někam do databáze a pak jen
kontrolovat data a řešit změny. Podobně jako to řeší Petr s daty RÚIANu.




Marián___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-GB] Errors in Street Names in Addresses

[Lester Caine]

On 29/01/18 09:27, Robert Whittaker (OSM lists) wrote:

So it ignores a simple 'name' ? which is why a lot of my streets are getting
tagged as wrong? I don't see any reason to have to add addr:street= when the
road already has name= ... The adjacent building use addr:street= ...

You're right that it doesn't look at the name=* key (except on
associatedStreet relations). But that shouldn't be a problem, as the
tool is only checking objects with an addr:postcode=* tag -- which
should be houses and other addressable premises, not the roads/streets
themselves. Sorry if that wasn't clear in my original post. (There's
currently no check that the values in addr:street=* on premises match
the name=* any mapped highway=* nearby.)

If you're not sure what's causing anything that's flagged by the tool,
let me know know the postcode(s) and I'll take a look.


So you are saying that the postcode should be removed from the street to 
fix your listings? I would prefer things the other way around and always 
have. The street and associated data does not need duplicating on every 
house if there is a matching street with the same addr:postcode ... but 
I think that boat has sailed ... However I see no reason to remove the 
addr:postcode from the street especially where routing to the property 
can take you to the wrong street where the building is closer to another 
road but has no access from it. So I'm not going to remove valid tagging ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

[Talk-it-lazio] Proposta incontro GeoBirra stasera 29/01/2018 Finnegan Irish Pub.

[pelatom]

Ciao a tutti,
mi rendo conto che mi sono svegliato all'ultimo momento, ma stasera
riusciamo ad incontrarci?

C'è l'incontro del 22/01 e magari potremmo accordarci per qualche workshop
del GFoss

Per ora siamo io e Martin (salvo imprevisti), e spero riesca ad accodarsi
qualcun altro.
La location del  Finnegan Irish Pub, a Monti
   a me piace, quindi
propongo lì attorno le 20:00.
C'è il wifi ed alle brutte mi metto a mappare.




-


M.P.
--
Sent from: http://gis.19327.n8.nabble.com/Lazio-f5372285.html

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

Re: [Talk-GB] Errors in Street Names in Addresses

[Paul Berry]

Hi Rob,

This is a really useful tool and I've already started making tweaks to
address data based on it.

Could I make a suggestion? I think an ampersand is a legitimate character
to see in an address or street name:
Other Odd Characters

Street names containing anything other than letters, punctuation, spaces
and numbers.
Regular expression: /[^A-Za-z0-9 '\.,:;()/\\-]/.
SectorPostcodeMappedDominant Street Name
WF1 1  WF1 1UQ 2

George␣&␣Crown␣Yard

In this example, the street they're on is given by
https://osm.org/way/252054368

Thanks again.

Regards,
*Paul*


On 29 January 2018 at 09:27, Robert Whittaker (OSM lists) <
robert.whittaker+...@gmail.com> wrote:

> On 29 January 2018 at 09:18, Lester Caine  wrote:
> > So it ignores a simple 'name' ? which is why a lot of my streets are
> getting
> > tagged as wrong? I don't see any reason to have to add addr:street= when
> the
> > road already has name= ... The adjacent building use addr:street= ...
>
> You're right that it doesn't look at the name=* key (except on
> associatedStreet relations). But that shouldn't be a problem, as the
> tool is only checking objects with an addr:postcode=* tag -- which
> should be houses and other addressable premises, not the roads/streets
> themselves. Sorry if that wasn't clear in my original post. (There's
> currently no check that the values in addr:street=* on premises match
> the name=* any mapped highway=* nearby.)
>
> If you're not sure what's causing anything that's flagged by the tool,
> let me know know the postcode(s) and I'll take a look.
>
> Robert.
>
> --
> Robert Whittaker
>
> ___
> 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-br] Importar dados rastreamentos .gpx

[Jander Dutra]

Pessoal bom dia,
Importamos um monte de trilhas de cada motorista separado por dia pela API
Java que achei, só que precisa confirmar a trilha manual no mapa para
efetivar a atualização. Não temos tempo pra isso, tem alguma chance de
outras pessoas confirmarem isso ? Queríamos muito contribuir com o mapa.

Em 12 de out de 2017 8:34 AM, "Sérgio V."  escreveu:

> Bom dia Jander,
>
> o Aun Johnsen tem um programa no github para fazer upload de gpx em
> quantidade:
>
> https://github.com/Skippern/gpxupload
>
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
>
>
> --
> *De:* Jander Dutra 
> *Enviado:* quarta-feira, 11 de outubro de 2017 16:25
> *Para:* talk-br@openstreetmap.org
> *Assunto:* [Talk-br] Importar dados rastreamentos .gpx
>
> Bom dia Pessoal,
> Usamos o openstreetmap comercialmente nos nossos sistemas e gostaríamos de
> contribuir enviando o rastreamento da nossa frota de veículo para o mapa,
> para manter mais atualizado as vias, atendemos todo o Brasil.
> Temos 100MB de dados dos ultimos 60 dias.
> Quais as recomendações para enviar os arquivos ?
>
> No aguardo.
> Obrigado.
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [talk-au] How do I map left only turning lanes on a motorway?

[Marc Gemis]

One could use change:lanes to indicate that one cannot change lanes
over during those 200m.
Unfortunately no data consumer understands this tag yet.

As for the exact position of the split, there are several opinions, as
one can see from the comments on this [1] diary entry.
AFAIK, Belgium,The Netherlands and Germany, split at the physical divider.

regards

m


[1] https://www.openstreetmap.org/user/daniel-j-h/diary/43148

On Mon, Jan 29, 2018 at 11:09 AM, cleary  wrote:
>
> I am no expert on mapping lanes and I defer to those with better knowledge.
> However common sense suggests to me that vehicles are able to move between
> lanes, whether into other lanes for vehicles travelling in the same
> direction or overtaking in a lane normally used for traffic in the oppisite
> direction.
>
> However if it is not possible or permissible for traffic to move into a
> nearby way, then I think it is a separate way, not a lane. I mapped one
> location in suburban Sydney where the left lane was for traffic turning left
> a couple of hundred metres further along, but traffic was not permitted to
> change in that last 200 metres. The left lane traffic had to turn left while
> other lanes could not move into the left lane or vice versa. I think it
> correct to map a separate way for that 200m.
>
> The most extreme example I know is on the Sydney Harbour Bridge where the
> most eastern lanes are physically separated from other lanes for a couple of
> kilometres and they are signposted with different names Cahill Expressway
> and Bradfield Highway. They may be physically adjacent but there is no
> crossover except one place for buses in the buses-only lane. It would only
> confuse people if the two ways were merged and regarded as lanes of the same
> way.
>
> I don't know the road about which this discussion started but, if not
> possible to change lanes, then I think it is correctly mapped as a separate
> way. If it is possible to change lanes, then they would be correctly mapped
> as lanes.
>
> I would say that physical proximity is not the determining characteristic.
> However I defer to those with better knowledge, if they hold a different
> view.
>
>
>
>
>
>
>
>
> On Mon, Jan 29, 2018, at 8:20 PM, Joel H. wrote:
>
> Hey everyone scrap that last message, I found out myself it has to be
>
> turn:lanes=slight_left|left;through
>
>
> On 29/01/18 17:02, David Dean wrote:
>
> Hi Joel,
>
> I believe that that example is not mapped correctly, as the turning lane
> should only become a separate way when it reaches an actually, physical
> separation. While it is just a turning lane, it should just be indicated by
> lane tagging on the main way.
>
> I'd move the separation up to the physical separation, and map the turning
> lane information on the main way.
>
> We have a few of those in the Brisbane area where intersections are overly
> complicated because an early (no longer active) mapper really liked mapping
> turning lanes as separate ways, and not all have been fixed.
>
> - David
>
> On Mon, 29 Jan 2018 at 16:59 Joel H. <95.5.ra...@gmail.com> wrote:
>
> Hello, I'm adding lane data to the Inner City Bypass in Brisbane.
>
> In this spot here: https://www.openstreetmap.org/way/23615424 there is 3
> lanes, however the left turn only lane is already mapped as a separate
> motorway link. My intention is to add turning lane data to this part of
> the ICB.
>
> Should I map this third left lane on the ICB and move the linking lane
> closer to the turn off. Or should these lanes be as separate roads, as
> it is now with the linking lane having 1 lane and the ICB having 2.
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
> --
>
> http://dbdean.com
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>

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

Re: [Talk-cz] Taskman pro poštovní schránky

[majka]

2018-01-29 10:37 GMT+01:00 r00t :

> Ahoj,
>
>
>
> Ty o kterych vim a mam tu v okoli snad domapuju rucne, ale ten reverse
> geocoding
> by to chtelo pro celou CR.
>
> Je nekde ten seznam k nahlednuti, abych aspon vedel kolik mi jich tu v
> okoli
> chybi nebo udelal ten geo-decoding rucne a podival se po nich ve
> streetview?
>
>
Můžu zkusit příští týden připravit pár dalších dep, případně pokud je
zájem, ještě někdy tenhle týden třeba tu Prahu. Bude ale třeba to potom
ručně projít a vložit do OSM.

Zatím jsem osobně takhle dělala depa České Budějovice, Český Krumlov a
Jindřichův Hradec + něco málo v Plzni.

Popis toho, jak jsem to dělala tu padl někdy v únoru loňského roku, můžu
sepsat nový / vylepšený návod.

Chyby souřadnic v poi-importeru (tedy souboru ČP) - hlásila jsem Mariánovi
a ten ručně opravoval souřadnice pro POI-importer. Mám za to, že někde
existuje csv, osobně jsem zatím posílala mailem.


Ke datům: 01.02. budou zase "čerstvá" od České pošty.

Na Mariána:

Neměla ta česká pošta v jednom z importů souřadnice v Křovákovi? Udělala
bych k tomu dávkově překódování a připravila tabulku nebo json.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] Taskman pro poštovní schránky

[Jakub Jelen]

Ano, Brno, severovychod. Nekolik jsem jich nasel, kterym chybely REF. Je to
sepsane v TM, takze klidne muzeme pokracovat diskuzi tam.

Zdroj je asi jenom detail. Spis me zajimalo, jeslti je zpusob jak to delat
"spravne". Hashtag jsem pridal.

Jakub

2018-01-29 1:04 GMT+01:00 Miroslav Suchý :

> Dne 28.1.2018 v 22:48 Jakub Jelen napsal(a):
> > super, koukl jsem na okoli a hned v prvnim ctverci mam dva cervene,
> > protoze nejsou sparovane s POI v OSM (protoze jsou nekolik set metru od
> > souradnic v POI importeru. Jak pracovat s temito? Posledni editace na
> > nich je od tebe. Uz jsi to nekam reportoval, nebo ti to mam poslat?
>
> Jestli se bavime o Brnu, tak Brno je hotove. Vsechny cervene v Brne jsou
> false-negative.
> Jeste to musim napsat do toho taskmanu.
>
> Vsechny ty spatne veci jsem preposlal na postu. Neco spravili (Svazna),
> neco ne (Obla).
>
> > Dale mi chybi informace co pouzit jako zdroj dat pro OSM changeset.
> > Tvoje zmeny obsahuji z iD pouze informaci "Bing aerial imagery", i kdyz
> > komentar rika "dle seznamu CP". Asi by bylo fajn toto nejak
> standardizovat.
>
> Nevim jestli je to nutne. Ale v taskmanu jsem navrhl hash tag
> #taskman-cz-postbox
> On to neni jenom jeden zdroj. Tomu exportu CP neni mozne slepe verit,
> proto jeste to overovani jak pisu v instrukcich.
>
> Mirek
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-it] Import Dati regione Puglia

[Luca Riccardi]

Ciao,

scusami con import intendevo un inserimento da 0, manuale.

Luca


Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno 29 gennaio 2018 10:50, Andrea Musuruane  ha
scritto:

> Ciao,
>
> 2018-01-29 10:45 GMT+01:00 Luca Riccardi :
>
>> Ciao,
>>
>> proverò a fare qualche import, ho già seguito il tutorial che mette a
>> disposizione OSM, e stavo provando a creare un nodo con JOSM, anche solo
>> per vedere il file OSM XML che genera ( nel caso fosse possibile).
>>
>
> Il suggerimento era di fare qualche edit (non qualche import) prima di
> avventurarsi con l'import per capire il funzionamento di OSM (ad esempio
> cos'è un changeset).
>
> Ciao,
>
> Andrea
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-cz] ortofoto mapy.cz

[majka]

Psal mu někdo rovnou? A ozvali se z DWG? Ten ban většinou přichází dost
rychle, pokud je dobře zdokumentovaný důvod.

Jen tak mimo, jako alternativní (i když podle Krematora horší) možný zdroj
uvádí ČÚZK, což je taky průšvih, protože podle souvislostí jde také o
ortofoto. Jednoznačně si s legálností zdrojů hlavu nikdy nelámal.

Pokud vím, tak "české" letecké snímky v nějaké podobě má k dispozici jen
Praha, všichni ostatní jsou odkázaní na Digital Globe / Esri / Bing.

2018-01-29 10:41 GMT+01:00 r00t :

> Ahoj,
>
> > Jdu napsat na DWG, ať ho zastaví.
> Podival jsem se na Krematora a stale mapuje co muze: Za vcerejsek 20
> changesetu,
> dneska uz dalsich 20. Do komentare ted dava jenom "..." ale imagery_used
> je u
> vsech stale mapserver.mapy.cz :(
>
> J
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [talk-au] How do I map left only turning lanes on a motorway?

[cleary]

I am no expert on mapping lanes and I defer to those with better
knowledge. However common sense suggests to me that vehicles are able to
move between lanes, whether into other lanes for vehicles travelling in
the same direction or overtaking in a lane normally used for traffic in
the oppisite direction.
However if it is not possible or permissible for traffic to move into a
nearby way, then I think it is a separate way, not a lane. I mapped one
location in suburban Sydney where the left lane was for traffic turning
left a couple of hundred metres further along, but traffic was not
permitted to change in that last 200 metres. The left lane traffic had
to turn left while other lanes could not move into the left lane or vice
versa. I think it correct to map a separate way for that 200m.
The most extreme example I know is on the Sydney Harbour Bridge where
the most eastern lanes are physically separated from other lanes for a
couple of kilometres and they are signposted with different names Cahill
Expressway and Bradfield Highway. They may be physically adjacent but
there is no crossover except one place for buses in the buses-only lane.
It would only confuse people if the two ways were merged and regarded as
lanes of the same way.
I don't know the road about which this discussion started but, if not
possible to change lanes, then I think it is correctly mapped as a
separate way. If it is possible to change lanes, then they would be
correctly mapped as lanes.
I would say that physical proximity is not the determining
characteristic. However I defer to those with better knowledge, if they
hold a different view.







On Mon, Jan 29, 2018, at 8:20 PM, Joel H. wrote:
> Hey everyone scrap that last message, I found out myself it has to be> 
> turn:lanes=slight_left|left;through


> 
> On 29/01/18 17:02, David Dean wrote:
>> Hi Joel, 
>> 
>> I believe that that example is not mapped correctly, as the turning
>> lane should only become a separate way when it reaches an actually,
>> physical separation. While it is just a turning lane, it should just
>> be indicated by lane tagging on the main way.>> 
>> I'd move the separation up to the physical separation, and map the
>> turning lane information on the main way.>> 
>> We have a few of those in the Brisbane area where intersections are
>> overly complicated because an early (no longer active) mapper
>> really liked mapping turning lanes as separate ways, and not all
>> have been fixed.>> 
>> - David
>> 
>> On Mon, 29 Jan 2018 at 16:59 Joel H. <95.5.ra...@gmail.com> wrote:
>>> Hello, I'm adding lane data to the Inner City Bypass in Brisbane.
>>> 
>>>  In this spot here: https://www.openstreetmap.org/way/23615424
>>>  there is 3>>>  lanes, however the left turn only lane is already mapped as 
>>> a
>>>  separate>>>  motorway link. My intention is to add turning lane data to 
>>> this
>>>  part of>>>  the ICB.
>>> 
>>>  Should I map this third left lane on the ICB and move the
>>>  linking lane>>>  closer to the turn off. Or should these lanes be as 
>>> separate
>>>  roads, as>>>  it is now with the linking lane having 1 lane and the ICB 
>>> having 2.>>> 
>>> 
>>>  ___
>>>  Talk-au mailing list
>>> Talk-au@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-au
>> --
>> 
>> http://dbdean.com
> 
> _
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [Talk-it] Numero civico e basta

[Andrea Musuruane]

Ciao,

2018-01-29 10:50 GMT+01:00 demon.box :

> ...intendo dire se ho soltanto il civico ma non ho niente da mettere in
> addr:street e nemmeno in addr:place lo mappo lo stesso o no?
>
> certo addr:place potrei "tirare ad indovinare" in base a qualche deduzione
> ma non si sembra il massimo della precisione...
>
> meglio allora non mappare nulla in questo caso?
>

Meglio il numero che niente, nella speranza che poi l'informazione venga
completata in futuro.

Ciao,

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

Re: [Talk-it] Import Dati regione Puglia

[Andrea Musuruane]

Ciao,

2018-01-29 10:45 GMT+01:00 Luca Riccardi :

> Ciao,
>
> proverò a fare qualche import, ho già seguito il tutorial che mette a
> disposizione OSM, e stavo provando a creare un nodo con JOSM, anche solo
> per vedere il file OSM XML che genera ( nel caso fosse possibile).
>

Il suggerimento era di fare qualche edit (non qualche import) prima di
avventurarsi con l'import per capire il funzionamento di OSM (ad esempio
cos'è un changeset).

Ciao,

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

Re: [Talk-it] Numero civico e basta

[demon.box]

...intendo dire se ho soltanto il civico ma non ho niente da mettere in
addr:street e nemmeno in addr:place lo mappo lo stesso o no?

certo addr:place potrei "tirare ad indovinare" in base a qualche deduzione
ma non si sembra il massimo della precisione...

meglio allora non mappare nulla in questo caso?

grazie

--enrico





--
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: [Talk-de] Relationen Radweg gelöscht: Relation 6889944 - [6] Egerradweg

[Volker Schmidt]

> Ja. Eine gelöschte Relation ist ja nicht wirklich weg, sondern nur als
> gelöscht markiert.
> Da du mit JOSM arbeitest, wäre hier das https://wiki.openstreetmap.org
> /wiki/JOSM/Plugins/Undelete zu empfehlen, mit dem du gezielt einzelne
> Objekte reaktivieren kannst. Es empfiehlt sich, das erstmal als
> Trockenübung zu machen und zu schauen ob die enthaltenen Wege noch da sind.
>

... und ich wuerde dringend empfehlen, das mit Glogi abzusprechen.

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

Re: [Talk-it] Import Dati regione Puglia

[Luca Riccardi]

Ciao,

proverò a fare qualche import, ho già seguito il tutorial che mette a
disposizione OSM, e stavo provando a creare un nodo con JOSM, anche solo
per vedere il file OSM XML che genera ( nel caso fosse possibile).

Per quanto riguarda il tag description, a dire il vero stavo pensando di
rimuoverlo, infatti è stato pensato come tag opzionale. Adesso dispongo dei
riferimenti della risorsa al portale, che contiene informazioni più
complete.

Le colonne che ho deciso di gestire del dataset sono: id della risorsa,
nome della risorsa, riferimento della risorsa al portale d'origine,
categoria della risorsa. Il riferimento come già detto conduce al portale
di origine dove vi sono altre info.

@ Martin se il nodo esiste già su osm (come node o poligono) , per il
momento, abbiamo deciso di non gestirlo. Per controllare  l'esistenza ho
seguito il consiglio di Maurizio Napolitano.

Luca Riccardi


Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno 26 gennaio 2018 20:02, Martin Koppenhoefer  ha scritto:

> 2018-01-26 18:12 GMT+01:00 Andrea Musuruane :
>
>> Perdonami, ma vedo che hai zero edit. Prima di fare un import, non
>> sarebbe meglio fare un po' di esperienza con OSM? ;-)
>>
>
>
>
> su questo sono d'accordo con Andrea, prima di importare dati ti inviterei
> a rilevarne e inserirne qualcuno "da zero". Proprio per capire in generale
> come funziona, qual'è il metodo, e come sono strutturati e taggati i dati
> già presenti.
>
> Vorrei anch'io vedere i file OSM da caricare, e se possibile delle liste
> di trasformazioni (quale informazione del dataset esterno diventa quale tag
> in OSM), e capire come il tool si comporta nel caso che già c'è qualche
> oggetto corrispondente, anche nel caso che certi valori sono diversi nel
> dettaglio (per esempio "name", ma in realtà tutti i dati). Segnalo che il
> tag "description" non è comunemente in uso per fornire descrizioni lunghi
> su oggetti (anche perché il limite per valori è di 255 charatteri). Invece
> usiamo molto i riferimenti esterni per questo (sopratutto wikipedia, e
> anche wikidata). Ci sono però anche tag per associare singole immagini
> (una) con "image".
>
> Ciao,
> Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Numero civico e basta

[demon.box]

ok, ma quindi?

in sostanza se ho soltanto il civico lo mappo oppure no?

grazie ancora.

--enrico




--
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: [Talk-cz] ortofoto mapy.cz

[r00t]

Ahoj,

> Jdu napsat na DWG, ať ho zastaví.
Podival jsem se na Krematora a stale mapuje co muze: Za vcerejsek 20 changesetu,
dneska uz dalsich 20. Do komentare ted dava jenom "..." ale imagery_used je u
vsech stale mapserver.mapy.cz :(

J


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

Re: [Talk-cz] Taskman pro poštovní schránky

[r00t]

Ahoj,


> Ty schránky opravdu chybí v tom importu od České pošty?
> ...
Majko, diky za presny popis...
Zkusim nejake projit v terenu a podle toho je doplnit.


> docela dost schránek nemá v tom seznamu ČP souřadnice, ale pouze adresu.
> Majka použila pro Plzeň reverze geokoding, ale já se k tomu ještě nedostal.
Aha, takze potom je to jasne.
Ty o kterych vim a mam tu v okoli snad domapuju rucne, ale ten reverse geocoding
by to chtelo pro celou CR.

Je nekde ten seznam k nahlednuti, abych aspon vedel kolik mi jich tu v okoli
chybi nebo udelal ten geo-decoding rucne a podival se po nich ve streetview?


J


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

Re: [Talk-it] Numero civico e basta

[Andrea Musuruane]

Ciao,

2018-01-29 10:26 GMT+01:00 demon.box :

> ciao scusate, riapro questa questione ma per una domanda ben specifica.
>
> ha senso, secondo voi, caricare civici senza nome della via ne nient'altro?
>
> esempio della situazione:
>
> attaccata all'edificio c'è la targhetta del civico e basta.
> ovviamente addr:city lo si può desumere dai confini ma niente di più...
>
> in sostanza voglio dire: è giusto mappare soltanto un civico?
>
> ho parecchi casi del genere in presenza di edifici di montangna isolati e
> mi
> chiedo se è giusto / se ha qualche utilità mappare soltanto il civico...
>
> nel wiki è previsto
>
> https://wiki.openstreetmap.org/wiki/IT:Addresses#Regole_
> specifiche_per_l.27Italia
>
> "Alcuni indirizzi non contengono il nome di una strada. Ad esempio, nei
> piccoli insediamenti l'indirizzo può contenere solo il nome
> dell'insediamento e il nome della casa o *il numero civico*"
>


Questo non è scritto nelle regole specifiche per l'Italia ma è parte della
traduzione della pagina in inglese.

Nelle regole specifiche per l'Italia invece è scritto:



*Se un indirizzo è associato a un'area di circolazione (via, piazza, ecc)
bisognerà inserire questa informazione nel tag addr:street=* (o in
alternativa bisognerà utilizzare le relazioni "street" e
"associatedStreet"). Es: addr:street=Via Cristoforo Colombo.Se un indirizzo
invece è associato a una località (Cascina, Regione, Frazione, Casale,
Borgata, ecc) allora si deve inserire questa informazione nel tag
addr:place=*. Es: addr:place=Cascina Molino Torrine; addr:place=Frazione
Fucina.*


*[...]*



*Il tag addr:place=* deve essere usato anche per indicare i sestieri negli
indirizzi di Venezia. Es: addr:place=San Polo + addr:housenumber=2307.Nota
bene: non si devono usare contemporaneamente addr:street=* e addr:place=*.
Il loro uso è mutuamente esclusivo. *

Ciao,

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

Re: [Talk-de] Relationen Radweg gelöscht: Relation 6889944 - [6] Egerradweg

[Tom Pfeifer]

On 29.01.2018 08:01, osm_ww wrote:

Jetzt muss ich erkennen, dass die von mir erstellten Relationen zum Teil 
vollständig von einem anderen User (Glogi) gelöscht worden sind.
https://www.openstreetmap.org/changeset/55019975
Als Begründung wird nur kurz „add part of route 6“ angegeben.


Das ist für das Löschen von 7 Relationen keine sinnvolle Begründung. Wie Volker schon empfahl, nimm 
über die CS-Diskussion Kontakt auf. Glogi arbeitet aber offenbar auch an Routen, da wuare besinders 
wichtig zu wissen was er vorhat. Vielleicht war es ja ein Versehen, mit 200 CS fehlt vielleicht noch 
Erfahrung.


In dem Changeset hat er aber auch Relationen verändert, insbesondere eine mit name=6 in Version 91, 
die solltest du dir anschauen, vielleicht hat er die Routen ja nur anders zusammengebaut?



Was kann man in solch einem Fall machen?
Kann ein anderer User einfach solche Löschungen vornehmen?
(Insbesondere, wenn das Ergebnis der Änderung schlechter ausfällt als der 
Anfangszustand?)


Können schon, die Absichten müssen halt geklärt werden, siehe oben.


Kann ich den von mir erstellten Radweg (Relation 6.889.944) wieder vollständig 
herstellen?


Ja. Eine gelöschte Relation ist ja nicht wirklich weg, sondern nur als gelöscht 
markiert.
Da du mit JOSM arbeitest, wäre hier das https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Undelete zu 
empfehlen, mit dem du gezielt einzelne Objekte reaktivieren kannst. Es empfiehlt sich, das erstmal 
als Trockenübung zu machen und zu schauen ob die enthaltenen Wege noch da sind.


tom


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

Re: [Talk-GB] Errors in Street Names in Addresses

[Robert Whittaker (OSM lists)]

On 29 January 2018 at 09:18, Lester Caine  wrote:
> So it ignores a simple 'name' ? which is why a lot of my streets are getting
> tagged as wrong? I don't see any reason to have to add addr:street= when the
> road already has name= ... The adjacent building use addr:street= ...

You're right that it doesn't look at the name=* key (except on
associatedStreet relations). But that shouldn't be a problem, as the
tool is only checking objects with an addr:postcode=* tag -- which
should be houses and other addressable premises, not the roads/streets
themselves. Sorry if that wasn't clear in my original post. (There's
currently no check that the values in addr:street=* on premises match
the name=* any mapped highway=* nearby.)

If you're not sure what's causing anything that's flagged by the tool,
let me know know the postcode(s) and I'll take a look.

Robert.

-- 
Robert Whittaker

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

[Talk-it] Numero civico e basta

[demon.box]

ciao scusate, riapro questa questione ma per una domanda ben specifica.

ha senso, secondo voi, caricare civici senza nome della via ne nient'altro?

esempio della situazione:

attaccata all'edificio c'è la targhetta del civico e basta.
ovviamente addr:city lo si può desumere dai confini ma niente di più...

in sostanza voglio dire: è giusto mappare soltanto un civico?

ho parecchi casi del genere in presenza di edifici di montangna isolati e mi
chiedo se è giusto / se ha qualche utilità mappare soltanto il civico...

nel wiki è previsto 

https://wiki.openstreetmap.org/wiki/IT:Addresses#Regole_specifiche_per_l.27Italia

"Alcuni indirizzi non contengono il nome di una strada. Ad esempio, nei
piccoli insediamenti l'indirizzo può contenere solo il nome
dell'insediamento e il nome della casa o *il numero civico*"

ma vorrei sentire comunque un vostro parere.
grazie

--enrico





--
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: [talk-au] How do I map left only turning lanes on a motorway?

[Joel H.]

Hey everyone scrap that last message, I found out myself it has to be

turn:lanes=slight_left|left;through


On 29/01/18 17:02, David Dean wrote:

Hi Joel,

I believe that that example is not mapped correctly, as the turning 
lane should only become a separate way when it reaches an actually, 
physical separation. While it is just a turning lane, it should just 
be indicated by lane tagging on the main way.


I'd move the separation up to the physical separation, and map the 
turning lane information on the main way.


We have a few of those in the Brisbane area where intersections are 
overly complicated because an early (no longer active) mapper really 
liked mapping turning lanes as separate ways, and not all have been fixed.


- David

On Mon, 29 Jan 2018 at 16:59 Joel H. <95.5.ra...@gmail.com 
> wrote:


Hello, I'm adding lane data to the Inner City Bypass in Brisbane.

In this spot here: https://www.openstreetmap.org/way/23615424
there is 3
lanes, however the left turn only lane is already mapped as a separate
motorway link. My intention is to add turning lane data to this
part of
the ICB.

Should I map this third left lane on the ICB and move the linking lane
closer to the turn off. Or should these lanes be as separate roads, as
it is now with the linking lane having 1 lane and the ICB having 2.


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

--
http://dbdean.com


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

Re: [Talk-GB] Errors in Street Names in Addresses

[Lester Caine]

On 27/01/18 20:09, Robert Whittaker (OSM lists) wrote:

[1] Due to the way addresses are recorded in OSM, and the formatting
of UK addresses by Royal Mail (see also [3] below), the "Street Name"
for an object is picked up by the tool from a variety of tags.
Currently it uses the following, in order of precedence: the
addr:place tag, the addr:parentstreet tag, the addr:street tag, the
name tag on associatedStreet relation if present, and the
addr:locality tag


So it ignores a simple 'name' ? which is why a lot of my streets are 
getting tagged as wrong? I don't see any reason to have to add 
addr:street= when the road already has name= ... The adjacent building 
use addr:street= ...


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [Talk-de] Relationen Radweg gelöscht: Relation 6889944 - [6] Egerradweg

[Volker Schmidt]

Hast du user Glogi irgendwie
kontaktiert? Ueber Changeset comment oder OSM message?
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-cz] Taskman pro poštovní schránky

[majka]

2018-01-29 1:34 GMT+01:00 r00t :

> Ahoj,
>
> Otestoval jsem import schranek a zkontroloval jsem neco malo v Praze.
> Zatim v kazdem ctverci byla alespon jedna schranka co se mi nepodarilo
> najit
> (pouzival jsem GE/SV, mapy.cz, IPR orto.. vsechny ostatni byly tam kde
> mely byt).
>
> Hodne schranek v POI importeru uplne chybi, pritom vsechny opravdu existuji
> (overeno) tak jak jsou v OSM zmapovane. Co s nimi, ma smysl je nejak
> zpatky hlasit?
> U tech kolem kterych chodim muzu zjistit a doplnit ref (tedy jestli to na
> schrance
> je nekde napsane...).


Ty schránky opravdu chybí v tom importu od České pošty?

Protože při mapování schránek po jižních Čechách jsem zjistila, že ten
import pošty je kompletní. Přesnost je věc druhá.
"Od počítače" se mi nepodařilo dohledat snad 5 schránek po jižních Čechách,
a to tam, kam google streetview nebo seznam panorama nedohlédne. Schránky
na železničních stanicích se dají dohledat na fotkách.

Id schránky - červeně označené na obrázku, tj. 37271:7 (nebo 37271:007,
netuším, zda dáváme úvodní nuly):

​



Z mých zkušeností:

   - největší rozdíly byly dané geokódováním adresa -> gps souřadnice
   (adresa nenalezena, takže se bere např. obec, případně číslo domu
   nenalezeno -> bere se zhruba geografický prostředek ulice)
   - chyby u České pošty - projeví se hlavně v menších obcích: psáno např.
   "obec č. 45", přitom schránka je "obec č. 25"

Dohledání "červených schránek", aneb kde hledat - nejčastější umístění:

ve městech:

   - křižovatky
   - blízko telefonních automatů
   - úřady / policie / zdravotnická zařízení apod.

v obcích:

   - náves
   - zastávka autobusů (i zevnitř)
   - obecní úřad
   - obchod
   - hasičská zbrojnice

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