Re: [OSM-talk] Woods vs Forests

[Oleksiy Muzalyev]

On 27.10.17 00:49, Dave F wrote:

[...]
I think you'd be hard pressed to find any area of trees which hasn't 
been managed in one way or another by humans; especially in the 
Western world. [...]


There is a theory nowadays that woods should be left alone to natural 
cycles which may last hundreds of years. At least that a forest is not a 
park where everything should be cleaned up and tidy. Dead wood in a 
forest is the food for numerous insects. These insects are the basis of 
a biodiversity pyramid. Here is some information on it: 
http://blogs.helsinki.fi/deadwoodmeeting/files/2016/02/Barbalat_dead-wood-insects_web.pdf


Best regards,

O.


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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Andreas Lattmann]

>Io sarei per tenerli, secondo me sono mappati in modo chiarissimo.

Anch'io sono per tenerli.

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] Mappatura di oggetti "virtuali"

[Andreas Lattmann]

>Andreas, i waypoint non sono dati variabili che cambiano col meteo :)

Grazie. Ora lo so. 
È quello che avevo capito dal wiki.

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

[OSM-talk-fr] Re : Rapprochement Bano

[Francois Gouget]

Le jeudi 26 octobre 2017 à 10:45 +0200, Christian Quest a écrit :
> Les applis qui ont besoin d'adresses peuvent utiliser celles d'OSM et
> compléter avec d'autres sources (BANO en est une).
[...]
> On va aussi pouvoir bien mieux exploiter les données du cadastre dans
> un avenir très proche, vu qu'on a accès depuis quelques semaines aux
> données EDIGEO brutes. Donc je patienterai un peu pour voir ce qu'on
> peut faire de mieux que ce qui a été fait jusque maintenant avec les
> extractions faites uniquement à partir de fichiers PDF sur
> cadastre.gouv.fr

Donc ce que je retiens :
* Priorité aux noms de rues.
  Tout à fait d'accord. Mais c'est pas évident de contribuer si on
n'est pas sur place. Quelles sont vos techniques ?
  A-t-on une idée du temps que vont prendre les 16 dernières voies
? Si elles restent c'est qu'il n'y a pas de contributeur dans ces
villes ?
  Enfin, si on arrive effectivement au bout de cet aspect, je pense que
ça a du sens de revisiter comment va s'organiser la suite.

* Attendre voir si on peut mieux faire avec le nouveau cadastre.
  Mieux = import massif ? Points "adresse manquante" dans Osmose ? (20
millions de points ça va être joli ;-)

* En l'absence d'import massif alors on continue avec une intégration
manuelle qui prendra 10 à 15 ans.
  Peut-on déveloper des stratégies pour maximiser le rendement des
efforts d'intégration ?
  - Par exemple si un contributeur ajoute un commerce / restaurant et
pointe vers son site web, il aura probablement vu son adresse quelque
part. Donc on pourrait recommander l'ajout de l'adresse dans les pages
Wiki de amenity, shop et office. Mais cela fera quelques rues
commerçantes avec plein d'adresses et pas grand chose ailleurs.
  - Ajouter les adresses aux intersections. Je pense qu'avoir ces
données dans OSM serait presque suffisant pour les usages courants.
Mais pour un contributeur ce n'est pas le cas le plus simple à traiter
: à chaque fois la question se pose de savoir sur quelle rue est le
numéro. Aussi, un contributeur gagne-t-il en temps à se concentrer sur
les intersections ?
  - Ajouter une adresse par rue bordant un paté de maison. Là on évite
le problème des intersections mais on répond un peu moins bien à la
question "je tourne à droite ou à gauche ?".
  - Se concentrer sur les rues couvertes par Mapillary. Ca permet de
gagner du temps et de couvrir une zone plus étendue en évitant d'avoir
à aller sur place. Mais la couverture Mapillary est très loin d'être
complète mais j'ai l'impression qu'assez peu de numéros sont lisibles
et donc si je compte le temps passé à chercher une image où un numéro
est lisible je ne suis pas sûr que le rendement soit si bon.

* Les outils peuvent s'appuyer sur la BANO.
  Si on table sur une intégration qui prend 10 ans ou plus alors
effectivement les outils ont plutôt intérêt à ajouter du support pour
la BANO afin d'être utilisables. Mais dans ce cas il faudrait les en
informer clairement.
  Ca veut aussi dire qu'ils devront intégrer du code spécifique pour la
France, soit au niveau de l'outil même, soit au niveau de la
préparation des fichiers OSM qu'ils utilisent en faisant leur propre
'import massif' de la BANO.

-- 
Francois Gouget 

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

[Talk-ko] Telegram (was: Re: Romanisation: a solution)

[Max]

I agree on this assessment of Telegram as a platform. However, it is 
very useful as a low-entry barrier place for casual discussion, quick 
question and dialogue type conversation that are harder in email, that 
requires a style that resembles more a letter exchange.


The mailinglist is the place where anything consensus forming is and 
will be taking place. It is also better for more complex issues.


The Telegram group is not meant as a replacement, but rather a 
complement to the mailinglist. Yes that fragments the discussion in 
smaller groups, but I think that's something we can live with. More 
problematic would be if discussion only takes place in a meduim that is 
unknown tou younger users and seems overly complicated and difficult to 
set up. Because let's face it: email only is a comfortable medium if you 
know what an email client is and you can use automatic filters, 
thread-view, etc. Mailinglists are another abstraction on top of this 
that the pokemon generation is not comfortable with. I don't even try to 
read the 19 mailinglists I am subscribed to on a mobile device, While 
it's entertaining to read the Telegram chat on a phone.


my 2 ct.

m.

On 2017년 10월 26일 13:20, Andrew Errington wrote:


Regarding the osmKorea group on telegram.me  I think 
it should not be promoted for two reasons.  Firstly, it seems that the 
messages can only be seen with the Telegram app.  They are not visible 
on a webpage therefore no-one can read any discussion or contribute 
without the app.  Secondly, the OSM community in Korea is small.  Not 
many people are subscribed to this list (Talk-ko) and using Telegram 
will fragment discussions further.  I suppose there is a third reason, 
and that is the most popular chat program in Korea is Kakao Talk.


In summary, I support changing ko_rm to ko-Latn, but I don't support 
using Telegram for discussion.


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

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[Kevin Kenny]

On Thu, Oct 26, 2017 at 5:12 PM, Nathan Mills  wrote:
> The tree cover issue is precisely why many states that have seasons have a
> recurrent leaf-off (sometimes even in IR) imaging program.
>
> Arkansas has their imagery, along with a raft of other open data, available
> on Geostor as a WMS service that should be usable in JOSM and also as
> downloadable data in your choice of extent and format. Oklahoma's is also
> available somewhere, but I'm not sure where. They lack a statewide data
> repository, so their data is scattered about various state and university
> sites.
>
> I know the wiki has a list of imagery sources, but I don't think it has any
> listed specifically as leaf off. Maybe someday I'll find some time to
> compile one.

New York definitely has leaves-off data, in 4-band R/G/B/NIR:

https://orthos.dhses.ny.gov/

although we also have some
significant amount of coniferous and mixed forest where tracing is
still difficult.  I would absolutely love it if this data source were available
for tracing in JOSM. I've emailed the data custodian repeatedly asking
for confirmation that this is an acceptable use, but never received a
reply.

Is the statement in the accompanying metadata,

Access_Constraints: Some imagery tiles are classified as sensitive due
to their content.

Use_Constraints:Use of sensitive imagery, if granted, is only for the
use specified in the request.

something on which we may rely? I was proceeding with a formal request
out of a superabundance of caution, and because I live in a jurisdiction
where County of Suffolk v First American is still good law. That said,
the State's official position (https://docs.dos.ny.gov/coog/ftext/f15695.htm)
is that its own open records are, to all intents and purposes,
in the public domain. If I were hosting the data on my own server,
I'd have no reservations at all, but I surely do not want to risk
the project in any way.

For that matter, do we also need further assurance that an official
who grants us permission is, in fact, authorized to grant it?
How far does our (justified!) official paranoia about external data
extend?

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

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[Clifford Snow]

You had me all excited to see Washington in your list, turns out it's DC. I
am impressed with the quality of work the locals are doing. Very few ways
in your extract.

Do you have your process document anywhere so we can reproduce the results
for other areas?

Clifford

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

[OSM-talk] Woods vs Forests

[Dave F]

(Split to a separate thread)

The woods/forest problem is one of the worst tagging cock-ups in OSM. 
It's bad enough when alternate values are used to differentiate what is 
actually the same object, but in this case it's also the key!


I think you'd be hard pressed to find any area of trees which hasn't 
been managed in one way or another by humans; especially in the Western 
world. Even in the depths of the Amazonian rainforest or Borneo the 
locals use wood for tools/fire/building etc.


Ignoring the landcover argument for a moment, all areas of trees should 
be primarily tagged as natural=wood. As with other entities, any further 
details which gives clarity should be provided in sub-tags.


Approach 2 is the appropriate example: 
https://wiki.openstreetmap.org/wiki/Forest,


The four render options on the website render wood & forest primary tags 
the same


DaveF

--
On 26/10/2017 13:37, Janko Mihelić wrote:,> A problem i find is with 
landuse=forest. Formally, those are zones that are used for growing 
trees. But practically in OSM, that tag is used for any land that is 
covered with trees. So formally, landuse=forest shouldn't overlap with 
other zones, but practically, until a new tag (landcover=trees) is 
rendered, this rule isn't going to be followed.


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


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

[OSM-talk] Woods Vs Forests (Was Topology rules)

[Dave F]

Started a new thread as it's gone of subject.

DaveF.


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


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

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[Clifford Snow]

Washington State just completed a aerial imagery program this spring, a
leaf-off program. It was funded by individual sources so the rasters aren't
available. Fortunately, many of the counties have open data with road
centerlines.

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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Francesco Pelullo]

Il 26 ott 2017 11:10 PM, "David Paleino"  ha scritto:

Andreas, i waypoint non sono dati variabili che cambiano col meteo :)


Ciao e bentornato,

Io sarei per tenerli, secondo me sono mappati in modo chiarissimo.

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

Re: [OSM-talk] Topology rules

[Daniel Koć]

W dniu 26.10.2017 o 23:36, Warin pisze:
While natural=wood renders, I also tag them as landcover=trees as that 
is more truthful of what is there.
So these tree areas get two tags from me until such time as landcover 
is rendered then I will remove the natural tag.


If you mean standard tile layer (osm-carto), landcover=* tag is far from 
being accepted:


https://github.com/gravitystorm/openstreetmap-carto/issues/2548#issuecomment-330002296

--
"My method is uncertain/ It's a mess but it's working" [F. Apple]


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

Re: [OSM-talk] Topology rules

[Warin]

On 27-Oct-17 12:00 AM, Joseph Reeves wrote:


A problem i find is with landuse=forest. Formally, those are zones
that are used for growing trees. But practically in OSM, that tag
is used for any land that is covered with trees. So formally,
landuse=forest shouldn't overlap with other zones, but
practically, until a new tag (landcover=trees) is rendered, this
rule isn't going to be followed.


Getting off topic, I think you want natural=wood :

http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood


While natural=wood renders, I also tag them as landcover=trees as that 
is more truthful of what is there.
So these tree areas get two tags from me until such time as landcover is 
rendered then I will remove the natural tag.




On 26 October 2017 at 13:37, Janko Mihelić > wrote:


I like the idea of formalizing OSM topology!

An example: power lines should share nodes with nothing except
power towers, portals and buildings (substation buildings).

A problem i find is with landuse=forest. Formally, those are zones
that are used for growing trees. But practically in OSM, that tag
is used for any land that is covered with trees. So formally,
landuse=forest shouldn't overlap with other zones, but
practically, until a new tag (landcover=trees) is rendered, this
rule isn't going to be followed.

Janko

sri, 25. lis 2017. u 18:41 Martin Koppenhoefer
> napisao je:



sent from a phone

> On 25. Oct 2017, at 17:36, Gaurav Thapa
> wrote:
>
> In Nepal we have been trying to make sure that each
constructed building has its own footprint and is not
connected to a neighbouring structure via a shared wall. We do
this as in reality this is the case as each building structure
though built next to each other has its own footprint
(independent foundation).


yes, you can find both situations: a single dividing wall used
by both neighboring buildings (in Europe this occurs mostly
with medieval buildings), or each building has its own walls
(and foundations), but without a significant space between
them (e.g. 2 cm of insulating material).

I would treat both situations the same and use shared nodes,
but maybe wouldn’t object if someone purposefully mapped the
latter as 2 almost-touching buildings, although the osm
building ways usually describe the footprint of the completed
building (i.e. with facades, cladding etc.) and not the raw
load bearing structure.

cheers,
Martin
___



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

Re: [Talk-es] Ediciones realizadas como función de un puesto de trabajo

[Esther Mingot]

Buenas,


partiendo de la base que OSM está creciendo en número de usuarios y cada vez 
habrá más ediciones comunitarias o guiadas, hace poco se estuvo haciendo una 
encuesta sobre cómo deberían ser las directrices para este tipo de ediciones. 
Se contemplaron tanto los casos de grupos de edición que se unen para mejorar 
una zona concreta, tipo mapatón o cursos de formación, como los casos donde una 
o más personas editan a cuenta de un tercero (ya sea por subvención, contrato, 
etc). No sé cómo estará el tema, tal vez algún otro miembro tenga más datos al 
respecto o te pueda orientar sobre dónde dirigir la consulta.


Sin ser una experta en el tema, los tres puntos que expones me parecen bien. 
Tener una cuenta para todas las ediciones, o tener una para ediciones 
personales y otra para "profesionales", va a gusto del consumidor. Mirando a 
futuro, si hubiera alguna duda o conflicto con una de las ediciones, la 
comunidad se pondría en contacto contigo a través del propio conjunto de 
cambios o a través de la cuenta de usuario que esté asociada al mismo. Que las 
ediciones hagan referencia a un proyecto, más o menos se suele hacer, aunque 
una vez más va a gusto del consumidor. Un ejemplo serían las ediciones del HOT, 
donde se pide expresamente que se conserve la referencia al proyecto al subir 
el conjunto de cambios.


En todo caso, toda edición que enriquezca el proyecto será bienvenida ;-)


Saludos!




De: Iván Hernández Cazorla 
Enviado: martes, 24 de octubre de 2017 21:51
Para: talk-es@openstreetmap.org
Asunto: [Talk-es] Ediciones realizadas como función de un puesto de trabajo


Buenas,

No tengo claro cómo va el asunto de las ediciones realizadas a partir de una 
función que un trabajador tiene que ejercer en su puesto de trabajo. En los 
proyectos Wikimedia a estas cuentas se las denomina «cuentas remuneradas», es 
decir, usuarios que cobran por un trabajo. Sus condiciones son las mismas que 
las del resto, es decir, cumplir con la normativa; pero sobre todo se vigila 
mucho que esa cuenta no esté haciendo ediciones promocionales ―por ej. un 
usuario contratado por una empresa o político que quiere limpiar sus «trapos 
sucios» presentes en los proyectos―.

No sé si hay algo escrito sobre ello, o si alguno podría orientarme, pero ahí 
van algunas preguntas. Si tuviese que realizar esas ediciones como parte de mi 
trabajo:

  *   ¿Se tendría que utilizar una cuenta solo para esas ediciones?
  *   ¿Habría que declarar que esa cuenta es la de X persona que trabajo para Y 
en un proyecto?
  *   ¿Habría que indicar algo a la hora de subir las ediciones?

Son dudas que tengo porque estoy a la espera de que me confirmen si sale 
adelante un proyecto. En él se trabajaría todo como contenido libre y, de cara 
a los geodatos, lo ideal sería trabajar con OpenStreetMap.

Muchas gracias de antemano. Y disculpen si el asunto del correo es algo lioso, 
ahora mismo no se me ocurre otro.

Saludos, Iván

--
Iván Hernández Cazorla
Miembro de Wikimedia España
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[Nathan Mills]

The tree cover issue is precisely why many states that have seasons have a 
recurrent leaf-off (sometimes even in IR) imaging program. 

Arkansas has their imagery, along with a raft of other open data, available on 
Geostor as a WMS service that should be usable in JOSM and also as downloadable 
data in your choice of extent and format. Oklahoma's is also available 
somewhere, but I'm not sure where. They lack a statewide data repository, so 
their data is scattered about various state and university sites.

I know the wiki has a list of imagery sources, but I don't think it has any 
listed specifically as leaf off. Maybe someday I'll find some time to compile 
one.

-Nathan


On October 26, 2017 1:00:05 PM EDT, OSM Volunteer stevea 
 wrote:
>I don't know where all of this is going, and wanted to see for myself,
>so I downloaded the California file (the largest one of all) and zoomed
>in on where I live and am most familiar with, Santa Cruz County.  Thank
>you for providing the ten states worth of translated data for us to
>take a look.
>
>What I found was, um, "interesting."  In urban areas, there were indeed
>a few highway=service, service=alley ways which Bing confirms are
>either there, mostly there, or "almost there," as in "slightly offset
>by a meter or three."  However, many of these were also clearly
>service=driveway instead of alley, a subtle distinction, but a crucial
>one, in my opinion (driveway implies access=private).  In more rural
>areas (and by no means is this a hard-and-fast delineation), there were
>many similar entries, but tree cover (2/3 of my county) made these
>impossible to distinguish via Bing.  Also, many had a name= tag with an
>empty value.  I'd rather that simply be no name tag at all, so that
>should be an easy improvement to make in any future/additional
>translations.
>
>There are literally thousands of these in my little county (2nd
>smallest geographically in the state) and it would take many hours
>(days) to go through them one by one and Bing compare, which certainly
>would improve OSM's data here.  (I've done similar tedious visual
>comparisons for thousands of polygons and TIGER review before, it is a
>labor of love!)  However, much or even most of these data would need an
>on-the-ground verification, simply because aerial/satellite data,
>whether fresh or not, have too much tree cover to allow such armchair
>mapping.  And, most of these additional data are very likely in highly
>rural areas which are not only difficult to get to, but are obviously
>on private property and (as is very typical around here on those)
>behind gates or "No Trespassing" signs (which I respect).
>
>So, while I find these a potentially rich source of new and/or better
>additional data, it is with great tedium and difficulty that they might
>be vetted/verified in a proper OSM way (cursory, via Bing, and/or fully
>and correctly, "on the ground").  I'm delighted the exercise to
>translate them into an easily-usable-by-OSM way has taken place, but it
>is with a great deal of caution and indeed trepidation that I approach
>and/or allow any new TIGER dataset "easy entry" into our map.
>
>In short:  eyes very wide open, slow going (if any going at all) ahead.
>If your state is included in the list, and you can zoom into your
>county or city, I'd be curious to hear what others might say after they
>take the half-hour or so I did to look and offer similar impressions of
>these data.
>
>SteveA
>California
>___
>Talk-us mailing list
>Talk-us@openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk-us

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] Mappatura di oggetti "virtuali"

[David Paleino]

Andreas, i waypoint non sono dati variabili che cambiano col meteo :)

Il 26 Ott 2017 10:45 PM, "Andreas Lattmann"  ha
scritto:

> Dai David, non fare così... i motivi sul perché non vengono mappate è
> spiegato sul wiki. Purtroppo ci sono molte, troppe variabili che fanno
> mutare questi dati, anche giornalmente: "Similarly, don’t upload your
> flight path traces, or draw air routes on the map: routes vary because of
> weather, time of day, amount of traffic, serviceability of facilities, and
> the number of ants in the coffee machine. Besides, they’ll probably annoy
> other mappers (the routes, and maybe the ants too)."
> Grazie per il lavoro che hai fatto.
>
> 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 mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Andreas Lattmann]

Dai David, non fare così... i motivi sul perché non vengono mappate è spiegato 
sul wiki. Purtroppo ci sono molte, troppe variabili che fanno mutare questi 
dati, anche giornalmente: "Similarly, don’t upload your flight path traces, or 
draw air routes on the map: routes vary because of weather, time of day, amount 
of traffic, serviceability of facilities, and the number of ants in the coffee 
machine. Besides, they’ll probably annoy other mappers (the routes, and maybe 
the ants too)."
Grazie per il lavoro che hai fatto. 

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] Incontro di co-design a Bologna

[Lorenzo Perone]

Il 24 ott 2017 20:18, "Volker Schmidt"  ha scritto:

Sono ingeressato.
Volker
(Padova)


Ciao Volker,
ci vediamo lì allora.
Ciao.
Lorenzo



2017-10-24 18:54 GMT+02:00 Lorenzo Perone :

> Ciao,
> scusate il cross-posting, mi hanno invitato ad un incontro di co-design
> organizzato dal comune di Bologna sul tema "bici" intitolato Mapathon
> #rastrelliereBiciBo
> Qui http://dati.comune.bologna.it/node/3097 potete trovare altre info.
> C'è qualcuno interessato a partecipare?
> Ciao.
> Lorenzo
>
> ___
> 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
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[Kevin Kenny]

On Thu, Oct 26, 2017 at 2:00 PM, OSM Volunteer stevea
 wrote:
> Thank you, Tod.  Yes, I MIGHT find a VERY SELECT SUBSET of these data 
> SOMEWHAT useful, as minor amounts of them seem to be accurate and 
> more-up-to-date enough to introduce into OSM.  But certainly not using any 
> sort of automated method.  Essentially, every single datum would need to be 
> human-reviewed, possibly corrected, likely conflated, and for a great many of 
> them, on-the-ground verified.  I'd say "garbage" seems too strong, but "very 
> noisy with a highly limited potential to add some minor value to our map, 
> coupled with great effort to vet, improve and enter the data" seems about 
> right.

This.

An up-to-date TIGER is useful for
(1) identifying errors that the Census Bureau caught in the old TIGER,
and getting somewhat better data for the 40% or so of census tracts
that had stale data in the old TIGER because of some IT glitches at
the Census Bureau.
(2) (Maybe) Getting names for new features that are not in the map
yet, and building a 'things to map' list.

At least in the rural areas around me, TIGER, even TIGER 2017, has a
vaguely hallucinatory quality. It has much better data quality in
town, but where it is nearly correct all seems to be areas that are
pretty well mapped already.

All politics aside, where I have direct familiarity with TIGER, it's a
mess. It's a valuable data source when doing other mapping, a
semi-valuable data source when identifying things that may be missing
from the map, and would add considerable negative value if imported
without the process Steve describes.

All this is without any argument about whether imports are good or bad
for the community. It's unquestionably bad to import data that are
less reliable than what we already have.

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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[David Paleino]

Mi ero perso la "on-the-ground-rule".

Resto dell'idea fossero buoni dati, ma potete pure revertare.

Mi cospargo il capo di cenere e torno alla mia vita.

Ciao,
David

Il 26 Ott 2017 9:42 PM, "David Paleino"  ha scritto:

> Secondo quale logica, allora, in passato ho mappato i gasdotti
> sotterranei? Oppure le partita IVA dei negozi?
>
> O ancora, perché mappiamo i lampioni? Gli alberi? Sono davvero utili
> nell'orienteering?
>
> I dati sono dati, se nel rendering non vuoi mostrare gli aeroway=waypoint
> -- che ben venga! -- ma nel database è opportuno che ci sia tutto.
>
> IMVHO,
> David
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nominatim ed abbreviazioni

[Martin Koppenhoefer]

sent from a phone

> On 26. Oct 2017, at 20:34, Davide Sandona'  wrote:
> 
> (al momento sembra che si occupi del progetto solamente l'utente Lonvia),


si, da anni che Sarah Hoffmann contribuisce quasi da sola: 
https://github.com/openstreetmap/Nominatim/commits/master

ho fatto un ticket un po’ di tempo fa e lei ha spiegato cosa vorrebbe fare, e 
cosa si potrebbe fare se qualcuno lo facesse:
https://github.com/openstreetmap/Nominatim/issues/679

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

Re: [OSM-talk-fr] Rapprochement Bano

[Romain MEHUT]

Le 26 octobre 2017 à 11:16, marc marc  a écrit :

>
> Pour les numéros de bâtiments il y a 5 méthodes :
>

Partant de ce principe, c'est déjà mal parti pour avoir un consensus. Comme
Christian l'a à nouveau rappelé, adresse et bâtiment sont deux notions
différentes.

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

Re: [OSM-talk-fr] Rapprochement Bano

[Romain MEHUT]

Le 26 octobre 2017 à 10:40, Nicolas Moyroud  a écrit :

>
> Je fais en général attention à bien marquer local_survey comme source de
> ceux que j'ai vérifié sur place.
>

Juste la valeur "local_survey" n'est pas documentée dans le wiki. Il s'agit
de "survey" tout simplement.

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

Re: [Talk-ca] Carleton University Mapathon

[James]

On the weekend, people might be more available(work and school might
prevent people)

On Oct 26, 2017 3:52 PM, "Tracey P. Lauriault"  wrote:

> Once you have a date let me know and I can check in on space.  THe ateium
> is grand, food is a monopoly situation, but if during the weekend we can
> work around stuff.
>
>
> On Thursday, October 26, 2017, James  wrote:
>
>> Setting a time would also be in order, but I imagine this has to be
>> figured out based on availability of rooms
>>
>> On Thu, Oct 26, 2017 at 11:44 AM, Kent Jacobs 
>> wrote:
>>
>>> Thank you all for the responses!
>>>
>>>
>>>
>>> I would like to have this during OSM Geoweek, but that week is
>>> approaching quickly. It would make sense to first designate a time and
>>> space to hold the Mapathon. I was thinking November 16th or 17th. This
>>> is after Nov. 14th event at the Royal Canadian Geographic Society where
>>> I believe Statistics Canada will be giving a presentation on their OSM
>>> project (https://twitter.com/CarletonDGES/status/920993927934574592).
>>>
>>>
>>>
>>> I am very familiar with the Carleton campus, so Loeb building could be
>>> an option since it is the location of the Geography department. Tracey, I
>>> hear that Richcraft Hall is the nicest building on campus though.  If
>>> anybody else is familiar with Carleton’s campus I’m open to location ideas.
>>>
>>>
>>>
>>> Kent
>>>
>>>
>>>
>>> *From:* Tracey P. Lauriault [mailto:tlaur...@gmail.com]
>>> *Sent:* October 26, 2017 9:01 AM
>>> *To:* John Marshall 
>>> *Cc:* James ; Kent Jacobs ;
>>> Talk-CA OpenStreetMap 
>>> *Subject:* Re: [Talk-ca] Carleton University Mapathon
>>>
>>>
>>>
>>> I am glad I provided the *How NOT to do* template ;)
>>>
>>> Let me know when it is on and if I am free I will join!
>>>
>>>
>>>
>>> On Thu, Oct 26, 2017 at 6:38 AM, John Marshall  wrote:
>>>
>>> I'm also available.
>>>
>>>
>>>
>>> John
>>>
>>>
>>>
>>> On Oct 26, 2017 06:17, "James"  wrote:
>>>
>>> Hey Kent, I'd be glad to help out :)
>>>
>>>
>>>
>>> On Oct 26, 2017 12:51 AM, "Kent Jacobs"  wrote:
>>>
>>> Hello all!
>>>
>>>
>>>
>>> I am a Masters of Science student in the Geography department at
>>> Carleton University studying Quality Assessment of OSM data for my thesis.
>>> I am also currently employed at Employment and Social Development Canada as
>>> a Geomatics Technician where I have been promoting the use of OSM data
>>> within the department.
>>>
>>>
>>>
>>> I discussed the idea of a possible mapathon at Carleton University with
>>> Statistics Canada, the Carleton Geography department and Mapbox. I am
>>> reaching out (similar to Tim’s post above) to find additional OSM mappers
>>> to assist us with the mapathon. I am fairly experienced with OSM myself but
>>> I have never led a mapathon event. I am aware of COMS2200 issues with
>>> contributions and do not want a repeat of this.  I believe focusing
>>> on the OSM Canada Task Manager and rural/remote regions will help avoid
>>> poor contributions.
>>>
>>>
>>>
>>> Any help is much appreciated!
>>>
>>>
>>>
>>> Regards,
>>>
>>> Kent
>>>
>>>
>>>
>>>
>>> ___
>>> 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-ca mailing list
>>> Talk-ca@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-ca
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> *Tracey P. Lauriault*
>>>
>>> Assistant Professor
>>>
>>> Critical Media Studies and Big Data
>>>
>>> Communication Studies
>>>
>>> School of Journalism and Communication
>>>
>>> Suite 4110, River Building
>>>
>>> Carleton University
>>>
>>> 1125 Colonel By Drive 
>>> 
>>>
>>> Ottawa (ON) K1S 5B6 
>>> 
>>>
>>> 1-613-520-2600 x7443 <(613)%20520-2600>
>>> tracey.lauria...@carleton.ca
>>> @TraceyLauriault
>>> Skype: Tracey.P.Lauriault
>>>
>>> https://carleton.ca/sjc/people-archives/lauriault-tracey/
>>>
>>
>>
>>
>> --
>> 外に遊びに行こう！
>>
>
>
> --
> *Tracey P. Lauriault*
>
> Assistant Professor
> Critical Media Studies and Big Data
> Communication Studies
> School of Journalism and Communication
> Suite 4110, River Building
> Carleton University1125 Colonel By Drive 
> Ottawa
>  (ON) K1S 5B6 
> 

Re: [Talk-ca] Carleton University Mapathon

[Tracey P. Lauriault]

Once you have a date let me know and I can check in on space.  THe ateium
is grand, food is a monopoly situation, but if during the weekend we can
work around stuff.


On Thursday, October 26, 2017, James  wrote:

> Setting a time would also be in order, but I imagine this has to be
> figured out based on availability of rooms
>
> On Thu, Oct 26, 2017 at 11:44 AM, Kent Jacobs  > wrote:
>
>> Thank you all for the responses!
>>
>>
>>
>> I would like to have this during OSM Geoweek, but that week is
>> approaching quickly. It would make sense to first designate a time and
>> space to hold the Mapathon. I was thinking November 16th or 17th. This
>> is after Nov. 14th event at the Royal Canadian Geographic Society where
>> I believe Statistics Canada will be giving a presentation on their OSM
>> project (https://twitter.com/CarletonDGES/status/920993927934574592).
>>
>>
>>
>> I am very familiar with the Carleton campus, so Loeb building could be an
>> option since it is the location of the Geography department. Tracey, I hear
>> that Richcraft Hall is the nicest building on campus though.  If
>> anybody else is familiar with Carleton’s campus I’m open to location ideas.
>>
>>
>>
>> Kent
>>
>>
>>
>> *From:* Tracey P. Lauriault [mailto:tlaur...@gmail.com
>> ]
>> *Sent:* October 26, 2017 9:01 AM
>> *To:* John Marshall > >
>> *Cc:* James > >; Kent Jacobs <
>> kent.jac...@gmail.com
>> >; Talk-CA
>> OpenStreetMap > >
>> *Subject:* Re: [Talk-ca] Carleton University Mapathon
>>
>>
>>
>> I am glad I provided the *How NOT to do* template ;)
>>
>> Let me know when it is on and if I am free I will join!
>>
>>
>>
>> On Thu, Oct 26, 2017 at 6:38 AM, John Marshall > > wrote:
>>
>> I'm also available.
>>
>>
>>
>> John
>>
>>
>>
>> On Oct 26, 2017 06:17, "James" > > wrote:
>>
>> Hey Kent, I'd be glad to help out :)
>>
>>
>>
>> On Oct 26, 2017 12:51 AM, "Kent Jacobs" > > wrote:
>>
>> Hello all!
>>
>>
>>
>> I am a Masters of Science student in the Geography department at Carleton
>> University studying Quality Assessment of OSM data for my thesis. I am also
>> currently employed at Employment and Social Development Canada as a
>> Geomatics Technician where I have been promoting the use of OSM data within
>> the department.
>>
>>
>>
>> I discussed the idea of a possible mapathon at Carleton University with
>> Statistics Canada, the Carleton Geography department and Mapbox. I am
>> reaching out (similar to Tim’s post above) to find additional OSM mappers
>> to assist us with the mapathon. I am fairly experienced with OSM myself but
>> I have never led a mapathon event. I am aware of COMS2200 issues with
>> contributions and do not want a repeat of this.  I believe focusing on
>> the OSM Canada Task Manager and rural/remote regions will help avoid poor
>> contributions.
>>
>>
>>
>> Any help is much appreciated!
>>
>>
>>
>> Regards,
>>
>> Kent
>>
>>
>>
>>
>> ___
>> 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-ca mailing list
>> Talk-ca@openstreetmap.org
>> 
>> https://lists.openstreetmap.org/listinfo/talk-ca
>>
>>
>>
>>
>>
>> --
>>
>> *Tracey P. Lauriault*
>>
>> Assistant Professor
>>
>> Critical Media Studies and Big Data
>>
>> Communication Studies
>>
>> School of Journalism and Communication
>>
>> Suite 4110, River Building
>>
>> Carleton University
>>
>> 1125 Colonel By Drive 
>> 
>>
>> Ottawa (ON) K1S 5B6 
>> 
>>
>> 1-613-520-2600 x7443 <(613)%20520-2600>
>> tracey.lauria...@carleton.ca
>> 
>> @TraceyLauriault
>> Skype: Tracey.P.Lauriault
>>
>> https://carleton.ca/sjc/people-archives/lauriault-tracey/
>>
>
>
>
> --
> 外に遊びに行こう！
>


-- 
*Tracey P. Lauriault*

Re: [Talk-it] Mappatura di oggetti "virtuali"

[David Paleino]

Secondo quale logica, allora, in passato ho mappato i gasdotti sotterranei?
Oppure le partita IVA dei negozi?

O ancora, perché mappiamo i lampioni? Gli alberi? Sono davvero utili
nell'orienteering?

I dati sono dati, se nel rendering non vuoi mostrare gli aeroway=waypoint
-- che ben venga! -- ma nel database è opportuno che ci sia tutto.

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

Re: [Talk-it] Mappatura di oggetti "virtuali"

[Cascafico Giovanni]

Un waypoint mappabile può essere qualsiasi oggetto fisico usato come
riferimento per la navigazione, al quale potresti aggiungere
aeroway=waypoint.
IMHO i waypoint che hai mappato dovrebbero invece essere tolti, come i nodi
senza tag o way.

Il 26/ott/2017 20:51, "David Paleino"  ha scritto:

> Buonasera a tutti,
>
> (ben ritrovati!)
>
> Vi segnalo http://www.openstreetmap.org/changeset/9603572 . Dal mio
> passato di mappatore non vedo problemi in quel mio changeset; è cambiato
> qualcosa nell'approccio ai dati inseribili?
>
> Ora, siccome non ho né il tempo, né la voglia di controbattere ancora a
> Lola Fox, sto scrivendo qui per accertarmi di non aver preso un abbaglio 6
> anni fa (urca, SEI*).
>
> Ciao,
> David
>
> * lavoro, nuova città, nuova compagna, molto meno tempo. Ma riconosco
> ancora alcuni nomi negli archivi della lista 
>
> ___
> 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-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[Greg Morgan]

On Thu, Oct 26, 2017 at 11:00 AM, OSM Volunteer stevea <
stevea...@softworkers.com> wrote:

> Thank you, Tod.  Yes, I MIGHT find a VERY SELECT SUBSET of these data
> SOMEWHAT useful, as minor amounts of them seem to be accurate and
> more-up-to-date enough to introduce into OSM.  But certainly not using any
> sort of automated method.  Essentially, every single datum would need to be
> human-reviewed, possibly corrected, likely conflated, and for a great many
> of them, on-the-ground verified.  I'd say "garbage" seems too strong, but
> "very noisy with a highly limited potential to add some minor value to our
> map, coupled with great effort to vet, improve and enter the data" seems
> about right.
>
> SteveA
> California
>
>
Yep! While not good for an import the data is useful for comparison.  I see
where I could pick up some road names and new subdivisions from Badita's
data. A more useful comparison would be an update to Alex Barth's "Better
Than OSM" tiles.  Does anyone on the list know of a friend of a friend at
MapBox?  Would you please ask them to update Alex's work?
https://api.tiles.mapbox.com/v4/lxbarth.647bc246/page.html?access_token=pk.eyJ1IjoibHhiYXJ0aCIsImEiOiJFVXdYcUlvIn0.bbaHTEWlnAwGgyVwJngMdQ#12/33.7449/-112.1031

Regards,
Greg
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-it] Mappatura di oggetti "virtuali"

[David Paleino]

Buonasera a tutti,

(ben ritrovati!)

Vi segnalo http://www.openstreetmap.org/changeset/9603572 . Dal mio passato
di mappatore non vedo problemi in quel mio changeset; è cambiato qualcosa
nell'approccio ai dati inseribili?

Ora, siccome non ho né il tempo, né la voglia di controbattere ancora a
Lola Fox, sto scrivendo qui per accertarmi di non aver preso un abbaglio 6
anni fa (urca, SEI*).

Ciao,
David

* lavoro, nuova città, nuova compagna, molto meno tempo. Ma riconosco
ancora alcuni nomi negli archivi della lista 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Nominatim ed abbreviazioni

[Davide Sandona']

tempo fa notai anch'io questa cosa. Secondo me, essendo il team che si
occupa di Nominatim numericamente esiguo (al momento sembra che si occupi
del progetto solamente l'utente Lonvia), è assai difficile implementare
tutte le cose che vengono aggiunte in quella pagina wiki e soprattutto
testarle in modo accurato. Dopotutto, un utente che non parla una
determinata lingua difficilmente riuscirebbe a testare le modifiche in modo
corretto.
Ritengo che se ci fosse uno sviluppatore italiano nel team, il processo di
integrazione delle abbreviazioni italiane potrebbe subire un'accelerata.
Tempo fa valutai la possibilità di dedicare un po' del mio tempo a questo
progetto, tuttavia i requisiti hardware per preparare una piattaforma di
test, anche solo limitata al territorio italiano, erano per me troppo
onerosi.

Davide.

Il giorno 26 ottobre 2017 16:35, Cascafico Giovanni 
ha scritto:

> Sono incappato nella pagina delle abbreviazioni [1] ed ho bisogno di
> chiarimenti, visto che l'argomento potrebbe risolvere alxune delle annose
> questioni degli addr.
>
> Perché in italiano la colonna "implemented" é vuota? Come seguire lo stato
> di questa implementazione? Perché le citate nuove colonne "Prefix/Suffix"
> non esistono?
>
> [1] https://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations
>
> ___
> 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: [OSM-talk-fr] fin d'une route secondaire ou tertiaire vers un hameau

[marc marc]

Le 12. 10. 17 à 22:43, Stéphane Péneau a écrit :
 > De mon point de vue, ce ne sont pas des _link.

comment les taguerais-tu ?
en sachant que même sans link, osmose rapporte une anomalie si une 
tertiaire s'arrête sans connexion vers une route de classe semblable
ou supérieur.

> Le 12/10/2017 à 22:49, David Crochet a écrit : >> un rond point doit être 
> catégorisé parla catégorie la plus 
importante des routes y accédant ou y partantexact selon moi, mais le 
problème se pose aussi sans rond point.
ceci dit, la correction du rond-point permettrait d'éviter la fin
de la route tertiaire vu que le rond-point se boucle sur lui-même.

Le 13. 10. 17 à 07:05, Stéphane Péneau a écrit :
 > si on considère qu'une
 > highway=trunk est une route pour automobile, ce qui entraine une
 > interdiction de circulation pour certains modes de transport, alors le
 > giratoire ne doit pas aussi être en trunk.

Je n'ai jamais vu de trunk qui finissent sur un rond point.
tout ceux que je connaisse finissent avant le rond point vu qu'un trunk 
ne peux pas avoir de carrefour et a une borne centrale que je n'ai 
jamais vu présente jusqu'au rond point

donc en simplifiant. d'un côté une route tertaire, de l'autre une route 
unclassified. comment relie-t-on la fin de l'un à l'autre ?
connexion direct et connexion avec un _link intermédiaire sont toutes 
les 2 erronée selon osmose
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[OSM Volunteer stevea]

Thank you, Tod.  Yes, I MIGHT find a VERY SELECT SUBSET of these data SOMEWHAT 
useful, as minor amounts of them seem to be accurate and more-up-to-date enough 
to introduce into OSM.  But certainly not using any sort of automated method.  
Essentially, every single datum would need to be human-reviewed, possibly 
corrected, likely conflated, and for a great many of them, on-the-ground 
verified.  I'd say "garbage" seems too strong, but "very noisy with a highly 
limited potential to add some minor value to our map, coupled with great effort 
to vet, improve and enter the data" seems about right.

SteveA
California


> On Oct 26, 2017, at 10:50 AM, Tod Fitch  wrote:
> In the area I now live in California, my first impression looking at this is 
> that the data is garbage. It looks to me that blindly importing would 
> re-introduce TIGER errors that have been successfully removed. Looking at a 
> tiny area in Arizona where my family still has a house, it is not much better.
> 
> My opinion is that a direct import of this data should not be done at all.
> 
> That said, when helping clean up the chdr reversion mess in Arizona I noticed 
> a number of new subdivisions in the Phoenix metro area where this data set 
> could be useful. But it would need to be done very selectively. For example, 
> there are new roads shown that are not evident in the aerial imagery 
> available to us for OSM. I would not add those unless a ground survey 
> indicated they actually exist. And there are lots that I would characterize 
> as tracks or service roads that have the traditional TIGER residential value.
> 
> Is a null length value even valid? Looking at the raw OSM files I see 
> ‘k="name" v=""’ in a number of places.
> 
> Tod


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

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[Greg Morgan]

On Thu, Oct 26, 2017 at 2:40 AM, Badita Florin 
wrote:
...

> Did not had time to look at each individual state, but i will share the
> insight for Arizona :
> Feel free to look at the other states.
> And please, if you want me to run this on any public dataset, just tell
> me, I will help you create a translation file, and we can compare any SHP
> with OSM, and get the results.
>
>
Uploaded on the google drive folder Arizona, the result size is 267 MB XML
>
> https://drive.google.com/drive/folders/0B7aOUf0DFRnLU3hUWFNu
> S05JS2c?usp=sharing
>
> There seems to be some new neighborhoods that were constructed/ are being
> constructed added to this TIGER 2017 release.
>

Badita,

Bless your little heart!  Finally, there are some real analysis without
saying imports are bad and they kill the community.  The problem that you
have found is that metro Phoenix is building again--going gang
busters. Phoenix alone just surpassed Philadelphia as the 5th largest city
in the US. Some of the examples you provided look like the subdivisions
that went bankrupt during the subprime rate recession.  Developers are
working these subdivisions again.  You can see a glimpse of the roof tiles
on this subdivision that collapsed during the subprime rate debacle but is
actively being built right now.
https://www.mapillary.com/map/im/oEdJEx6gjEBgOjtRtkjkHQ

It is not just roads where the growth and change is happening.  Iconic
buildings--as far as Phoenix goes--are being plowed under for apartment
buildings.
July 2016
https://www.mapillary.com/map/im/WDRNcgF6KECHwfsj-qeNBA
October 2017
https://www.mapillary.com/map/im/zZXUcxZJAT2UxrlQCyIvsQ
http://www.azcentral.com/story/news/local/phoenix/2016/08/03/new-central-avenue-macayos-open-phoenix-early-2017/88008706/

I would only bore you to death with more examples of both.

Regards,
Greg
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] corrections Osmose et rues sans nom

[marc marc]

Dans ces cas là, il faut ouvrir les tickets pour les apps
sinon le problème va se reproduire

J'ai ouvert un ticket osmose
https://github.com/osm-fr/osmose-backend/issues/239

et un pour StreetComplete
https://github.com/westnordost/StreetComplete/issues/663

Le 19. 10. 17 à 22:42, Jérôme Seigneuret a écrit :
> Bonjour, pour info c'est réglé. Par contre une alerte osmose sur des 
> termes incohérents comme ça peut être utile. J'en avait déjà parlé et il 
> me semble que c'est déjà pris en charge pour parti (conditionnel donc à 
> vérifier).
> 
> J'ai fait cette propos dans le changeset.
> 
> Jérôme
> 
> Le 19 octobre 2017 à 21:28,  > a écrit :
> 
> Bonjour,
> 
> modifications automatiques, aidées ou manuelles, on se pose souvent
> la question.
> 
> J'étais parti d'une recherche de Sans Nom (un ancien nom de
> Marseille, la Ville Sans Nom) et suis tombé sur nombre de Sans Nom.
> 
> S'il peut y avoir des rues ,villes etc.. nommées "Sans Nom" il
> s'agit souvent de la volonté du cartographe de dire que la rue par
> exemple n'a pas de nom, ce qui se décrit avec noname=yes et
> l'absence de tags name*.
> 
> Je suis tombé sur des corrections Osmose où des personnes ont
> "corrigé" des "sans nom" en "Sans Nom".
> 
> C'est un peu le risque des corrections automatiques : on peut en
> faire qui abiment plus qu'elles ne corrigent.
> 
> Car une rue "sans nom" est assez évidemment une rue noname=yes, pour
> une rue Sans Nom c'est déjà moins évident.
> 
> Regardez comment une simple question peut améliorer la carte :
> 
> https://www.openstreetmap.org/changeset/38086717#map=19/43.15773/-0.39276
> 
> 
> 
> À l'opposé comment StreetComplete peut dégrader la carte en ajoutant
> de l'information pertinente... mal :
> 
> https://www.openstreetmap.org/changeset/49440578#map=18/47.28462/2.57830
> 
> 
> À vos claviers !
> 
> Fred, peut-on proposer de corriger les sans nom non en Sans Nom mais
> en noname=yes ? Ou laisser le choix ?
> 
> Jean-Yvon
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-fr
> 
> 
> 
> 
> 
> -- 
> Cordialement,
> Jérôme Seigneuret
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[Tod Fitch]

In the area I now live in California, my first impression looking at this is 
that the data is garbage. It looks to me that blindly importing would 
re-introduce TIGER errors that have been successfully removed. Looking at a 
tiny area in Arizona where my family still has a house, it is not much better.

My opinion is that a direct import of this data should not be done at all.

That said, when helping clean up the chdr reversion mess in Arizona I noticed a 
number of new subdivisions in the Phoenix metro area where this data set could 
be useful. But it would need to be done very selectively. For example, there 
are new roads shown that are not evident in the aerial imagery available to us 
for OSM. I would not add those unless a ground survey indicated they actually 
exist. And there are lots that I would characterize as tracks or service roads 
that have the traditional TIGER residential value.

Is a null length value even valid? Looking at the raw OSM files I see ‘k="name" 
v=""’ in a number of places.

Tod

> On Oct 26, 2017, at 10:00 AM, OSM Volunteer stevea 
>  wrote:
> 
> I don't know where all of this is going, and wanted to see for myself, so I 
> downloaded the California file (the largest one of all) and zoomed in on 
> where I live and am most familiar with, Santa Cruz County.  Thank you for 
> providing the ten states worth of translated data for us to take a look.
> 
> What I found was, um, "interesting."  In urban areas, there were indeed a few 
> highway=service, service=alley ways which Bing confirms are either there, 
> mostly there, or "almost there," as in "slightly offset by a meter or three." 
>  However, many of these were also clearly service=driveway instead of alley, 
> a subtle distinction, but a crucial one, in my opinion (driveway implies 
> access=private).  In more rural areas (and by no means is this a 
> hard-and-fast delineation), there were many similar entries, but tree cover 
> (2/3 of my county) made these impossible to distinguish via Bing.  Also, many 
> had a name= tag with an empty value.  I'd rather that simply be no name tag 
> at all, so that should be an easy improvement to make in any 
> future/additional translations.
> 
> There are literally thousands of these in my little county (2nd smallest 
> geographically in the state) and it would take many hours (days) to go 
> through them one by one and Bing compare, which certainly would improve OSM's 
> data here.  (I've done similar tedious visual comparisons for thousands of 
> polygons and TIGER review before, it is a labor of love!)  However, much or 
> even most of these data would need an on-the-ground verification, simply 
> because aerial/satellite data, whether fresh or not, have too much tree cover 
> to allow such armchair mapping.  And, most of these additional data are very 
> likely in highly rural areas which are not only difficult to get to, but are 
> obviously on private property and (as is very typical around here on those) 
> behind gates or "No Trespassing" signs (which I respect).
> 
> So, while I find these a potentially rich source of new and/or better 
> additional data, it is with great tedium and difficulty that they might be 
> vetted/verified in a proper OSM way (cursory, via Bing, and/or fully and 
> correctly, "on the ground").  I'm delighted the exercise to translate them 
> into an easily-usable-by-OSM way has taken place, but it is with a great deal 
> of caution and indeed trepidation that I approach and/or allow any new TIGER 
> dataset "easy entry" into our map.
> 
> In short:  eyes very wide open, slow going (if any going at all) ahead.  If 
> your state is included in the list, and you can zoom into your county or 
> city, I'd be curious to hear what others might say after they take the 
> half-hour or so I did to look and offer similar impressions of these data.
> 
> SteveA
> California
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us


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

Re: [Talk-cz] Fotky v mapě

[Jiří Komárek]

Ahoj,


za mne vyfotím, nahraju na Wikimedia Commons a na daný objekt přidám 
tag: image=File:soubo-na-commons.jpg , případně 
wikimedia_commons=Category:kategorie-objektu-v-commons . Je to i tak 
doporučováno na https://wiki.openstreetmap.org/wiki/Key:image



Rozcestníky nahrávám na osm.cz a nijak nelinkuji.


Sekvence (tj. cesta autem, pěšky či na kole) patří na Mapillary či 
OpenStreetView (osobně nelinkuji, svého času se to snad i 
nedoporučovalo, ale jak vidím, tak již více než dva roky existuje tag 
mapillary=*).



Pro mne je spíš otázka, zda-li přidávat kategorie na Commons či 
jednotlivé obrázky u objektů, které mají tag wikidata (a jsou 
prolinkované s tím daným obrázkem či kategorií). Čistě teoreticky je to 
zbytečné, protože tato informace je duplicitní, automaticky se 
neaktualizuje v případě, že je u objektu na Wikidatech vybrán nový, 
lepší obrázek a vlastně by šla doplnit rotobicky. Jediný problém pro 
tvůrce koncových map je, že tuto informaci už nemá rovnou k dispozici a 
musí dělat další mezikrok (a roboticky v současnosti nikdy tag image=* z 
Wikidat nepřidává).



Jirka Komárek

On 26.10.2017 18:46, Vladimír Slávik wrote:

Ahoj,
koukal jsem na wiki a našel: 
http://wiki.openstreetmap.org/wiki/Photo_linking Pokud pominu že je ta 
stránka celý jeden den stará a popisuje nesprávné použití některých 
tagů... Jaké metody používáte pro fotky? Nahráváte do Mapillary, 
OpenStreetView, Wikimedia Commons, ...? Jak je odkazujete z mapy?


Já osobně nahrávám na Commons a dávám odkaz jako image="File:...". 
Přiznám se že motivací je že to jediné je to co funguje na osm.cz.


Vláďa


___
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: [OSM-talk-fr] Rapprochement Bano

[gergero]

Bonjour,

(Excusez-moi, si cette question n’apparait pas au bonne endroit - c'est 
mon 1èr message sur cette liste.)


J'ai une question par rapport aux données suivantes :

> (Message de Christian Quest Mer 25 Oct 13:55:58 UTC 2017 :)

> "Pour les points en violet, ce sont des adresses issues des fichiers du
> cadastre désormais en opendata. C'est un peu expérimental, mais ça peut
> être utile."

Comment retrouver les données/fichiers à l'origine de ces adresses 
(points en violet) ?





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

Re: [Talk-us] Comparing Tiger 2017 dataset with OSM in a automatedway.

[OSM Volunteer stevea]

I don't know where all of this is going, and wanted to see for myself, so I 
downloaded the California file (the largest one of all) and zoomed in on where 
I live and am most familiar with, Santa Cruz County.  Thank you for providing 
the ten states worth of translated data for us to take a look.

What I found was, um, "interesting."  In urban areas, there were indeed a few 
highway=service, service=alley ways which Bing confirms are either there, 
mostly there, or "almost there," as in "slightly offset by a meter or three."  
However, many of these were also clearly service=driveway instead of alley, a 
subtle distinction, but a crucial one, in my opinion (driveway implies 
access=private).  In more rural areas (and by no means is this a hard-and-fast 
delineation), there were many similar entries, but tree cover (2/3 of my 
county) made these impossible to distinguish via Bing.  Also, many had a name= 
tag with an empty value.  I'd rather that simply be no name tag at all, so that 
should be an easy improvement to make in any future/additional translations.

There are literally thousands of these in my little county (2nd smallest 
geographically in the state) and it would take many hours (days) to go through 
them one by one and Bing compare, which certainly would improve OSM's data 
here.  (I've done similar tedious visual comparisons for thousands of polygons 
and TIGER review before, it is a labor of love!)  However, much or even most of 
these data would need an on-the-ground verification, simply because 
aerial/satellite data, whether fresh or not, have too much tree cover to allow 
such armchair mapping.  And, most of these additional data are very likely in 
highly rural areas which are not only difficult to get to, but are obviously on 
private property and (as is very typical around here on those) behind gates or 
"No Trespassing" signs (which I respect).

So, while I find these a potentially rich source of new and/or better 
additional data, it is with great tedium and difficulty that they might be 
vetted/verified in a proper OSM way (cursory, via Bing, and/or fully and 
correctly, "on the ground").  I'm delighted the exercise to translate them into 
an easily-usable-by-OSM way has taken place, but it is with a great deal of 
caution and indeed trepidation that I approach and/or allow any new TIGER 
dataset "easy entry" into our map.

In short:  eyes very wide open, slow going (if any going at all) ahead.  If 
your state is included in the list, and you can zoom into your county or city, 
I'd be curious to hear what others might say after they take the half-hour or 
so I did to look and offer similar impressions of these data.

SteveA
California
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-cz] Fotky v mapě

[Vladimír Slávik]

Ahoj,
koukal jsem na wiki a našel: http://wiki.openstreetmap.org/wiki/Photo_
linking Pokud pominu že je ta stránka celý jeden den stará a popisuje
nesprávné použití některých tagů... Jaké metody používáte pro fotky?
Nahráváte do Mapillary, OpenStreetView, Wikimedia Commons, ...? Jak je
odkazujete z mapy?

Já osobně nahrávám na Commons a dávám odkaz jako image="File:...". Přiznám
se že motivací je že to jediné je to co funguje na osm.cz.

Vláďa___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-ca] Carleton University Mapathon

[James]

Setting a time would also be in order, but I imagine this has to be figured
out based on availability of rooms

On Thu, Oct 26, 2017 at 11:44 AM, Kent Jacobs  wrote:

> Thank you all for the responses!
>
>
>
> I would like to have this during OSM Geoweek, but that week is approaching
> quickly. It would make sense to first designate a time and space to hold
> the Mapathon. I was thinking November 16th or 17th. This is after Nov. 14
> th event at the Royal Canadian Geographic Society where I believe
> Statistics Canada will be giving a presentation on their OSM project (
> https://twitter.com/CarletonDGES/status/920993927934574592).
>
>
>
> I am very familiar with the Carleton campus, so Loeb building could be an
> option since it is the location of the Geography department. Tracey, I hear
> that Richcraft Hall is the nicest building on campus though.  If
> anybody else is familiar with Carleton’s campus I’m open to location ideas.
>
>
>
> Kent
>
>
>
> *From:* Tracey P. Lauriault [mailto:tlaur...@gmail.com]
> *Sent:* October 26, 2017 9:01 AM
> *To:* John Marshall 
> *Cc:* James ; Kent Jacobs ;
> Talk-CA OpenStreetMap 
> *Subject:* Re: [Talk-ca] Carleton University Mapathon
>
>
>
> I am glad I provided the *How NOT to do* template ;)
>
> Let me know when it is on and if I am free I will join!
>
>
>
> On Thu, Oct 26, 2017 at 6:38 AM, John Marshall  wrote:
>
> I'm also available.
>
>
>
> John
>
>
>
> On Oct 26, 2017 06:17, "James"  wrote:
>
> Hey Kent, I'd be glad to help out :)
>
>
>
> On Oct 26, 2017 12:51 AM, "Kent Jacobs"  wrote:
>
> Hello all!
>
>
>
> I am a Masters of Science student in the Geography department at Carleton
> University studying Quality Assessment of OSM data for my thesis. I am also
> currently employed at Employment and Social Development Canada as a
> Geomatics Technician where I have been promoting the use of OSM data within
> the department.
>
>
>
> I discussed the idea of a possible mapathon at Carleton University with
> Statistics Canada, the Carleton Geography department and Mapbox. I am
> reaching out (similar to Tim’s post above) to find additional OSM mappers
> to assist us with the mapathon. I am fairly experienced with OSM myself but
> I have never led a mapathon event. I am aware of COMS2200 issues with
> contributions and do not want a repeat of this.  I believe focusing on
> the OSM Canada Task Manager and rural/remote regions will help avoid poor
> contributions.
>
>
>
> Any help is much appreciated!
>
>
>
> Regards,
>
> Kent
>
>
>
>
> ___
> 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-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
>
>
> --
>
> *Tracey P. Lauriault*
>
> Assistant Professor
>
> Critical Media Studies and Big Data
>
> Communication Studies
>
> School of Journalism and Communication
>
> Suite 4110, River Building
>
> Carleton University
>
> 1125 Colonel By Drive 
> 
>
> Ottawa (ON) K1S 5B6 
> 
>
> 1-613-520-2600 x7443 <(613)%20520-2600>
> tracey.lauria...@carleton.ca
> @TraceyLauriault
> Skype: Tracey.P.Lauriault
>
> https://carleton.ca/sjc/people-archives/lauriault-tracey/
>



-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Carleton University Mapathon

[Kent Jacobs]

Thank you all for the responses!

 

I would like to have this during OSM Geoweek, but that week is approaching 
quickly. It would make sense to first designate a time and space to hold the 
Mapathon. I was thinking November 16th or 17th. This is after Nov. 14th event 
at the Royal Canadian Geographic Society where I believe Statistics Canada will 
be giving a presentation on their OSM project 
(https://twitter.com/CarletonDGES/status/920993927934574592).

 

I am very familiar with the Carleton campus, so Loeb building could be an 
option since it is the location of the Geography department. Tracey, I hear 
that Richcraft Hall is the nicest building on campus though.  If anybody else 
is familiar with Carleton’s campus I’m open to location ideas.

 

Kent

 

From: Tracey P. Lauriault [mailto:tlaur...@gmail.com] 
Sent: October 26, 2017 9:01 AM
To: John Marshall 
Cc: James ; Kent Jacobs ; Talk-CA 
OpenStreetMap 
Subject: Re: [Talk-ca] Carleton University Mapathon

 

I am glad I provided the How NOT to do template ;)

Let me know when it is on and if I am free I will join!

 

On Thu, Oct 26, 2017 at 6:38 AM, John Marshall  > wrote:

I'm also available. 

 

John

 

On Oct 26, 2017 06:17, "James"  > wrote:

Hey Kent, I'd be glad to help out :)

 

On Oct 26, 2017 12:51 AM, "Kent Jacobs"  > wrote:

Hello all!

 

I am a Masters of Science student in the Geography department at Carleton 
University studying Quality Assessment of OSM data for my thesis. I am also 
currently employed at Employment and Social Development Canada as a Geomatics 
Technician where I have been promoting the use of OSM data within the 
department. 

 

I discussed the idea of a possible mapathon at Carleton University with 
Statistics Canada, the Carleton Geography department and Mapbox. I am reaching 
out (similar to Tim’s post above) to find additional OSM mappers to assist us 
with the mapathon. I am fairly experienced with OSM myself but I have never led 
a mapathon event. I am aware of COMS2200 issues with contributions and do not 
want a repeat of this.  I believe focusing on the OSM Canada Task Manager and 
rural/remote regions will help avoid poor contributions.

 

Any help is much appreciated!

 

Regards,

Kent

 


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





 

-- 

Tracey P. Lauriault

Assistant Professor 
Critical Media Studies and Big Data
Communication Studies
School of Journalism and Communication
Suite 4110, River Building
Carleton University
1125 Colonel By Drive
Ottawa (ON) K1S 5B6

1-613-520-2600 x7443
tracey.lauria...@carleton.ca  
@TraceyLauriault
Skype: Tracey.P.Lauriault 

https://carleton.ca/sjc/people-archives/lauriault-tracey/

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

Re: [Talk-ko] Romanisation: a solution

[Max]

Agree, data consumers should read the tag case insensitive, just in 
case, but for tagging we should follow one recommendation and that 
should be -Latn


On 2017년 10월 26일 23:47, Lukas Sommer wrote:

Makes sense!

(I’m not sure about lowercase. I would rather opt for ko-Latn because
also also sr-Latn uses titlecase.)
Lukas Sommer


2017-10-26 3:06 GMT+00:00 Maarten van den Hoven :

Dear OSM editors,


This email proposes a solution to the Korean and Japanese romanisation
tagging issue. Since this topic concerns both Korea and Japan it is sent to
their respective mailing lists.

The tag for romanised korean is currently "name:ko_rm". However, this is not
the international standard. "ko_rm" was most likely chosen a long time ago
because people at the time were unformiliar with the global standard as seen
here (https://wiki.openstreetmap.org/wiki/Talk:Korea_Naming_Convention). The
global standard as defined by the Internet Engineering Task Force here
(https://tools.ietf.org/html/bcp47) and backed by W3C, Unicode, ECMA is
"ko-Latn" instead of "ko_rm". Adopting a global standard solves confusion
over the use of the tag
(http://wiki.openstreetmap.org/wiki/Multilingual_names#Korea).

This talk has been going on for the past years as seen by the above links
and this one ->
http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.ko/204
However, I was unable to find arguments in defense of the "ko_rm" tag.

Therefore, I suggest an edit of the OSM database (following the official
procedure as defined here
https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct) of
changing all "name:ko_rm" tags to "name:ko-Latn", like Serbia did in the
past as well (http://wiki.openstreetmap.org/wiki/Multilingual_names#Serbia).

Before this change is pushed it is of course important to see if anyone has
objections or other reasons why the "ko_rm" tag was chosen over the
"ko-Latn" tag.

We encourage editors in Korea to join the OSM Korea Telegram chat group here
https://telegram.me/osmKorea.

Kind regards.

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



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




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

Re: [Talk-ko] Romanisation: a solution

[Lukas Sommer]

Makes sense!

(I’m not sure about lowercase. I would rather opt for ko-Latn because
also also sr-Latn uses titlecase.)
Lukas Sommer


2017-10-26 3:06 GMT+00:00 Maarten van den Hoven :
> Dear OSM editors,
>
>
> This email proposes a solution to the Korean and Japanese romanisation
> tagging issue. Since this topic concerns both Korea and Japan it is sent to
> their respective mailing lists.
>
> The tag for romanised korean is currently "name:ko_rm". However, this is not
> the international standard. "ko_rm" was most likely chosen a long time ago
> because people at the time were unformiliar with the global standard as seen
> here (https://wiki.openstreetmap.org/wiki/Talk:Korea_Naming_Convention). The
> global standard as defined by the Internet Engineering Task Force here
> (https://tools.ietf.org/html/bcp47) and backed by W3C, Unicode, ECMA is
> "ko-Latn" instead of "ko_rm". Adopting a global standard solves confusion
> over the use of the tag
> (http://wiki.openstreetmap.org/wiki/Multilingual_names#Korea).
>
> This talk has been going on for the past years as seen by the above links
> and this one ->
> http://thread.gmane.org/gmane.comp.gis.openstreetmap.region.ko/204
> However, I was unable to find arguments in defense of the "ko_rm" tag.
>
> Therefore, I suggest an edit of the OSM database (following the official
> procedure as defined here
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct) of
> changing all "name:ko_rm" tags to "name:ko-Latn", like Serbia did in the
> past as well (http://wiki.openstreetmap.org/wiki/Multilingual_names#Serbia).
>
> Before this change is pushed it is of course important to see if anyone has
> objections or other reasons why the "ko_rm" tag was chosen over the
> "ko-Latn" tag.
>
> We encourage editors in Korea to join the OSM Korea Telegram chat group here
> https://telegram.me/osmKorea.
>
> Kind regards.
>
> ___
> Talk-ko mailing list
> Talk-ko@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ko
>

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

[Talk-GB] Adding unmapped postcodes using FHRS data

[Gregrs]

Hi all,

Using Robert Whittaker's excellent postcode stats (available in an 
interactive form here: http://robert.mathmos.net/osm/postcodes/stats/), 
I've created a list of the FHRS establishments that have a postcode 
which currently hasn't been assigned to any objects in OpenStreetMap. As 
part of the addresses Quarterly Project, this should provide an easy way 
to increase our postcode coverage and improve POI address data at the 
same time.


You can download a list for each postal area as a CSV file (which you 
can open with Microsoft Excel or OpenOffice Calc, for example) here:


http://gregrs.dev.openstreetmap.org/fhrs-unmapped-postcodes/

If this proves useful I will try to update it fairly regularly.

Best wishes,
Greg

--
Twitter: @gregrs_uk
http://gregrs.dev.openstreetmap.org
PGP key ID: 64907C8A
Fingerprint: EBD1 077F CCDD 841E A505 3FAA D2E8 592E 6490 7C8A



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

Re: [OSM-talk-fr] Rapprochement Bano

[Vincent de Château-Thierry]

Bonjour,

> De: "Philippe Verdy" 
> 
> En bref, BANO est un "aggrégateur" de données, dont les sources sont
> OSM, la BAN, et d'autres bases ouvertes en OpenData des
> collectivités locales ou de certaines entreprises. 

Non on ne peut pas dire que la BAN alimente BANO. Mais BANO, comme la BAN, va 
puiser dans le Cadastre. Le Cadastre (source DGFip) ainsi que le fichier 
FANTOIR sont des sources majeures pour BANO.

> BANO a donc sa vie propre, c'est le meilleur de tous les mondes
> actuels concernant la France (donc meilleur qu'OSM ou la BAN
> utilisés seuls).

Il y a 2 facettes dans BANO...
* Initialement l'idée était bien d'agréger plusieurs sources de données pour 
constituer le meilleur référentiel d'adresses sur la France, à disposition du 
plus grand nombre. L'idée reste, évidemment, mais depuis le paysage a changé : 
l'initiative BAN a enfin émergé, titillée par BANO après des années de sommeil. 
Pour autant, comme l'a rappelé Christian, le contenu issu de BANO est bien 
disponible, et rafraîchi chaque nuit. La BAN n'a pas encore atteint une 
envergure et un rythme de mise à jour qui videraient le contenu BANO de son 
intérêt.
* La seconde facette est finalement la plus importante je pense, vue du côté 
OSM : le coup de projecteur sur la thématique Adresses impulsé par BANO a 
permis l'émergence de quelques outils d'aide à la contribution OSM : par 
exemple le rendu cartographique et la page de comparaison Fantoir par commune. 
On pensait initialement focaliser notre énergie sur les adresses elles-mêmes 
(les numéros) et comme Christian l'a redit, c'est essentiellement sur les noms 
de voies que l'accent a été mis. C'est là que la balance entre temps passé et 
valeur ajoutée aura été la plus équilibrée, au final profitable pour OSM. 

On a parlé dans ce fil d'import d'adresses. Si la finalité est de disposer de 
toutes les adresses connues de BANO dans une application consommant par 
ailleurs le contenu OSM, un import brut n'a pas de sens. Autant utiliser OSM 
sans les adresses d'une part, et ajouter les adresses BANO d'autre part. La 
vraie valeur ajoutée n'est pas dans l'import, voué à l'échec en terme de 
maintenance compte tenu du volume (autour de 20 millions d'adresses) et du 
nombre de contributeurs capables d'y consacrer du temps. Parlons plutôt 
d'intégration, à savoir un processus manuel, long, requérant souvent un passage 
sur le terrain car les adresses sont tout sauf une matière simple : exceptions, 
cas tordus, contradictions... reparlons-en quand OSM disposera en France d'un 
contributeur par (communauté de) commune(s), là oui ;)

> (...) Si d'autres
> collectivités publiques se joignent à la BAN, on pourra les exclure
> en tant que source pour BANO puisque ce sera fait dans BAN (et donc
> économiser plein de signalements inutiles liés tous aux différences
> existant encore entre les sources). La BAN en revanche ne rapproche
> pas encore les éléments extraits du cadastre (mais BANO le fait).

Non, il ne s'agit pas de déshabiller BANO au fur et à mesure de la constitution 
de la BAN. Il faut considérer que BANO a sa vie propre, et reste une 
alternative à la BAN, comme dit plus haut.

vincent

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

[Talk-it] Nominatim ed abbreviazioni

[Cascafico Giovanni]

Sono incappato nella pagina delle abbreviazioni [1] ed ho bisogno di
chiarimenti, visto che l'argomento potrebbe risolvere alxune delle annose
questioni degli addr.

Perché in italiano la colonna "implemented" é vuota? Come seguire lo stato
di questa implementazione? Perché le citate nuove colonne "Prefix/Suffix"
non esistono?

[1] https://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] OSM Standard Layer

[SK53]

I have, I think, reverted the offending changesets (which unfortunately
required removing all the users work).

I have messaged the project manager both via the HOT TM and OSM messages,
and messaged DWG as well.

Now to get back to adding stuff from my surveys in Northern Ireland (which
is noticeably better mapped than when I was there 2 years ago)!

Jerry

On 26 October 2017 at 13:48, Paul Berry  wrote:

> Thanks, Phil.
>
> I've commented on the changeset: http://www.openstreetmap.org/changeset/
> 5322
>
> Regards,
> *Paul*
>
> On 26 October 2017 at 13:30, Philip Barnes  wrote:
>
>> I see it too, also this strange large building http://osm.org/5322
>>
>>
>> Missing maps rubbish...
>>
>> Phil (trigpoint)
>>
>> On 26 October 2017 13:12:02 BST, Paul Berry 
>> wrote:
>>>
>>> Has there been a change to the colours on the Standard Layer or has
>>> someone inadvertently turned the UK into heath/farmland in the last 24
>>> hours?
>>>
>>> Visible at zoom level 13 only, it seems.
>>>
>>> Regards,
>>> *Paul*
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-de] Deutsche Namens-Tags in Polen

[Martin Koppenhoefer]

Am 26. Oktober 2017 um 14:56 schrieb Richard :

> abgesehen von der poltisch-moralischen Dimension ist es Unfug irgendwelche
> Namen einzutragen die
> * dem Großteil der Nutzer und Einwohner nicht geläufig sind
> * sich auf keiner Ortstafel uä finden.
>
>


nach dieser Argumentation dürfte man überhaupt keine anderen Namen als die
lokalen eintragen, weil die Einwohner kennen normalerweise vor allem ihre
eigene Sprache, der Großteil der Nutzer wird immer unterschiedliche
Sprachen sprechen und Ortstafeln geben normalerweise auch nur die
offiziellen Namen an.





> Mit so einer Karte findet keiner den Weg!



Es geht ja nicht nur darum, den Weg vor Ort zu finden. Und es ist auch
nicht gesagt, dass nur weil ein Name in der eigenen Sprache in OSM
eingetragen ist, man als Anwender dann keine anderen Sprachen (wie z.B. die
vor Ort geläufigen) mehr angezeigt bekommt.

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

Re: [OSM-talk-fr] Rapprochement Bano

[Philippe Verdy]

Le 26 octobre 2017 à 11:56, Christian Quest  a
écrit :

> Vu la diversité de modélisation des adresses dans OSM (pas qu'en France),
> c'est là aussi que BANO est utile car ça remet tout ça sous une unique
> forme simple et un réutilisateur ayant besoin d'adresses devrait plutôt
> regarder de ce côté (pour la France) que de se prendre la tête avec la
> donnée OSM brute car il faut prendre en compte ces cas, mais aussi la
> hiérarchie administrative, les relations boundary=administrative, les codes
> postaux, etc...
>

En bref, BANO est un "aggrégateur" de données, dont les sources sont OSM,
la BAN, et d'autres bases ouvertes en OpenData des collectivités locales ou
de certaines entreprises. Il tente ensuite des rapprochements entre ces
sources, et dresse une carte statistique destiné à comparer les sources,
mais cette carte n'est pas un outil d'import en tant que tel, juste un état
des lieux du rapprochement et des progrès restant à faire dans chacune des
sources utilisées par BANO et des différences significatives trouvées.

Pour le reste c'est à chaque source de trouver en elle-même un chemin
d'accord permettant un rapprochement satisfaisant (le critère de
rapprochement peut évoluer encore avec des seuils de différence abaissés,
aussi bien pour la géolocalisation que la topoynymie). Le travail reste à
faire pour OSM afin de le mettre progressivement en accord avec les autres
sources de la BANO.

BANO a donc sa vie propre, c'est le meilleur de tous les mondes  actuels
concernant la France (donc meilleur qu'OSM ou la BAN utilisés seuls).

La BAN est un autre projet séparé de rapprochement entre certains acteurs
de missions de service public. Lui aussi fait des rapprochements mais pas
avec OSM ni avec toutes les bases OpenData. Je ne pense pas que ce soit la
mission de BANO de refaire lui-même le rapprochement déjà fait et géré par
la BAN gouvernementale, donc BANO n'a pas besoin d'utiliser les sources
comme La Poste puisque cela fait déjà partie du rapprochement dans la BAN.
Si d'autres collectivités publiques se joignent à la BAN, on pourra les
exclure en tant que source pour BANO puisque ce sera fait dans BAN (et donc
économiser plein de signalements inutiles liés tous aux différences
existant encore entre les sources). La BAN en revanche ne rapproche pas
encore les éléments extraits du cadastre (mais BANO le fait).

Ceci dit, BANO produit aussi des données à destination des acteurs de la
BAN publique et notamment les données présentes dans OSM mais pas encore
(ou plus) dans la BAN ou ayant de grosses différences de position ou de
nom. Pour cela il s'appuie sur un outil de signalement, commune par
commune, pour le moment au niveau des voies et lieux-dits (mais pas encore
pour les adresses)
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Deutsche Namens-Tags in Polen

[Tom Pfeifer]

On 26.10.2017 14:56, Richard wrote:

Vielleicht mal als name:1939-1944 


Nein, als old_name:-, jetzt auch ordentlich dokumentiert.

https://wiki.openstreetmap.org/wiki/DE:Key:old_name

tom

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

Re: [OSM-talk] Topology rules

[Richard]

On Wed, Oct 25, 2017 at 12:50:40PM +0300, Tomas Straupis wrote:
> Hello
> 
>   For a long time I wanted to hear opinion on the topic of topology rules.
> 
>   By "topology rules" here I mean just simple rules such as:
>   * polygon X should not overlap polygon Y
>   * polygon X should always be above polygon Y
>   * point X should be not further from line Y than D
>   etc.

you are thinking too abstract and trying to do too many things
at a time. 


>   * it would be easier for cartographers or the like. They would not
> have to guess which polygons should be above which ones in drawing
> order, for example when creating garmin maps it is not always possible
> to control the order of layers, so we have a question which goes
> first: forest or water? 

quite clearly described here: 
  http://wiki.openstreetmap.org/wiki/Key:layer#Data_consumers

Water and forest is allowed to overlap. OSM landcover model is insufficient
and mildly broken. Fixing it is not so easy.

Richard


pgpAtcSqTx1_j.pgp
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Topology rules

[Joseph Reeves]

A problem i find is with landuse=forest. Formally, those are zones that are
used for growing trees. But practically in OSM, that tag is used for any
land that is covered with trees. So formally, landuse=forest shouldn't
overlap with other zones, but practically, until a new tag
(landcover=trees) is rendered, this rule isn't going to be followed.


Getting off topic, I think you want natural=wood :

http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwood

On 26 October 2017 at 13:37, Janko Mihelić  wrote:

> I like the idea of formalizing OSM topology!
>
> An example: power lines should share nodes with nothing except power
> towers, portals and buildings (substation buildings).
>
> A problem i find is with landuse=forest. Formally, those are zones that
> are used for growing trees. But practically in OSM, that tag is used for
> any land that is covered with trees. So formally, landuse=forest shouldn't
> overlap with other zones, but practically, until a new tag
> (landcover=trees) is rendered, this rule isn't going to be followed.
>
> Janko
>
> sri, 25. lis 2017. u 18:41 Martin Koppenhoefer 
> napisao je:
>
>>
>>
>> sent from a phone
>>
>> > On 25. Oct 2017, at 17:36, Gaurav Thapa  wrote:
>> >
>> > In Nepal we have been trying to make sure that each constructed
>> building has its own footprint and is not connected to a neighbouring
>> structure via a shared wall. We do this as in reality this is the case as
>> each building structure though built next to each other has its own
>> footprint (independent foundation).
>>
>>
>> yes, you can find both situations: a single dividing wall used by both
>> neighboring buildings (in Europe this occurs mostly with medieval
>> buildings), or each building has its own walls (and foundations), but
>> without a significant space between them (e.g. 2 cm of insulating material).
>>
>> I would treat both situations the same and use shared nodes, but maybe
>> wouldn’t object if someone purposefully mapped the latter as 2
>> almost-touching buildings, although the osm building ways usually describe
>> the footprint of the completed building (i.e. with facades, cladding etc.)
>> and not the raw load bearing structure.
>>
>> cheers,
>> Martin
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-ca] Carleton University Mapathon

[Tracey P. Lauriault]

I am glad I provided the *How NOT to do* template ;)
Let me know when it is on and if I am free I will join!

On Thu, Oct 26, 2017 at 6:38 AM, John Marshall  wrote:

> I'm also available.
>
> John
>
> On Oct 26, 2017 06:17, "James"  wrote:
>
>> Hey Kent, I'd be glad to help out :)
>>
>> On Oct 26, 2017 12:51 AM, "Kent Jacobs"  wrote:
>>
>>> Hello all!
>>>
>>>
>>>
>>> I am a Masters of Science student in the Geography department at
>>> Carleton University studying Quality Assessment of OSM data for my thesis.
>>> I am also currently employed at Employment and Social Development Canada as
>>> a Geomatics Technician where I have been promoting the use of OSM data
>>> within the department.
>>>
>>>
>>>
>>> I discussed the idea of a possible mapathon at Carleton University with
>>> Statistics Canada, the Carleton Geography department and Mapbox. I am
>>> reaching out (similar to Tim’s post above) to find additional OSM mappers
>>> to assist us with the mapathon. I am fairly experienced with OSM myself but
>>> I have never led a mapathon event. I am aware of COMS2200 issues with
>>> contributions and do not want a repeat of this.  I believe focusing
>>> on the OSM Canada Task Manager and rural/remote regions will help avoid
>>> poor contributions.
>>>
>>>
>>>
>>> Any help is much appreciated!
>>>
>>>
>>>
>>> Regards,
>>>
>>> Kent
>>>
>>>
>>>
>>> ___
>>> 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-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>


-- 
*Tracey P. Lauriault*

Assistant Professor
Critical Media Studies and Big Data
Communication Studies
School of Journalism and Communication
Suite 4110, River Building
Carleton University
1125 Colonel By Drive
Ottawa (ON) K1S 5B6

1-613-520-2600 x7443
tracey.lauria...@carleton.ca
@TraceyLauriault
Skype: Tracey.P.Lauriault
https://carleton.ca/sjc/people-archives/lauriault-tracey/
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-de] Deutsche Namens-Tags in Polen

[Richard]

On Wed, Oct 25, 2017 at 03:19:04PM +0200, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
> > On 25. Oct 2017, at 13:53, SteMo  wrote:
> > 
> > 2. In Polen findet man, mit wenigen Ausnahmen auf historischen
> > Baudenkmälern oder in Geschichtsbüchern _keine_ Verwendung dieser
> > Bezeichnungen aus dem Dritten Reich.
> 
> 
> Namen, die nur im Dritten Reich verwendet wurden, sollte man natürlich nicht 
> in name:de eintragen, aber es gibt auch weit über diesen Zeitrahmen hinaus 
> viele deutsche Namen, die unter, zumindest nach heutigem Maßstab, 
> fragwürdigen bzw. “unmoralischen” Umständen in die Welt kamen, s.z.B. 
> https://de.m.wikipedia.org/wiki/Germanisierung in Mittelalter und Neuzeit 
> (vor 3.Reich). Englische, französische und spanische Namen sind z.B. im 
> Kontext der Kolonialisierung auch betroffen (das relativiert nicht den 
> Nationalsozialismus, sondern den deutschen Imperialismus des 19. Jh). Ob die 
> Polen vor Ort deutsche Namen verwenden oder nicht sollte uns nicht daran 
> hindern sie in name:de zu tun (wie gesagt, sofern es keine Namen aus der 
> Kriegszeit sind), evtl. auch old_name:de. 

abgesehen von der poltisch-moralischen Dimension ist es Unfug irgendwelche 
Namen einzutragen die
* dem Großteil der Nutzer und Einwohner nicht geläufig sind
* sich auf keiner Ortstafel uä finden.

Mit so einer Karte findet keiner den Weg! Wie blöd stehe ich in Verona 
da wenn ich einen Italiener nach dem Bus nach Reif am Gart Frage?

Vielleicht mal als name:1939-1944 aber von prominenten Ausnahmen abgesehen
gehört das wohl eher in die OHM?

Richard


pgp8Eb9XIgH94.pgp
Description: PGP signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-GB] OSM Standard Layer

[Paul Berry]

Thanks, Phil.

I've commented on the changeset:
http://www.openstreetmap.org/changeset/5322

Regards,
*Paul*

On 26 October 2017 at 13:30, Philip Barnes  wrote:

> I see it too, also this strange large building http://osm.org/5322
>
>
> Missing maps rubbish...
>
> Phil (trigpoint)
>
> On 26 October 2017 13:12:02 BST, Paul Berry  wrote:
>>
>> Has there been a change to the colours on the Standard Layer or has
>> someone inadvertently turned the UK into heath/farmland in the last 24
>> hours?
>>
>> Visible at zoom level 13 only, it seems.
>>
>> Regards,
>> *Paul*
>>
>
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>
> ___
> 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-ca] Severed Dick

[James]

I've added a note to those trails saying that it's been discussed twice now
and linked this email chain with the mail archive:

Name as been discussed twice. Although vulgar, seems to be accurate.
https://lists.openstreetmap.org/pipermail/talk-ca/2017-October/008145.html

On Thu, Oct 26, 2017 at 8:29 AM, Julia C  wrote:

> I grew up in this municipality, but not near that area and I am not a
> mountain biker. I am not surprised by those names though... ugh they are
> horrible.
>
> Julia
>
> On Wed, Oct 25, 2017 at 3:35 PM, Denis Carriere 
> wrote:
>
>> Unfortunately does names seem legit for that type of mountain bike
>> trails, these are not the first mountain bike trails names I've seen with
>> those types of names.
>>
>> Seems like source of these edits come from a reputable editor.
>>
>> *User: *BC Trail Guides
>> 
>> http://osmlab.github.io/osm-deep-history/#/way/402020482
>> http://osmlab.github.io/osm-deep-history/#/way/402020492
>>
>> This doesn't look like this is a form form of vandalism, that's just BC
>> Canada for you ;)
>>
>> *~~*
>> *@DenisCarriere*
>> *GIS Software & Systems Specialist*
>>
>> On Wed, Oct 25, 2017 at 11:03 AM, Frederik Ramm 
>> wrote:
>>
>>> Hi,
>>>
>>>noticed a few funny trail names in this region near Vancouver:
>>>
>>> https://www.openstreetmap.org/#map=16/49.3365/-122.9791
>>>
>>> Quote possible they really *are* called "Severed Dick", "Shorn Scrotum",
>>> and "Cunt Buster", in which case they're of course totally legit to have
>>> on the map, however I've come across some made-up names like that in the
>>> past too. Maybe someone can check.
>>>
>>> Bye
>>> Frederik
>>>
>>> --
>>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>>
>>> ___
>>> 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-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: [OSM-talk] Topology rules

[Janko Mihelić]

I like the idea of formalizing OSM topology!

An example: power lines should share nodes with nothing except power
towers, portals and buildings (substation buildings).

A problem i find is with landuse=forest. Formally, those are zones that are
used for growing trees. But practically in OSM, that tag is used for any
land that is covered with trees. So formally, landuse=forest shouldn't
overlap with other zones, but practically, until a new tag
(landcover=trees) is rendered, this rule isn't going to be followed.

Janko

sri, 25. lis 2017. u 18:41 Martin Koppenhoefer 
napisao je:

>
>
> sent from a phone
>
> > On 25. Oct 2017, at 17:36, Gaurav Thapa  wrote:
> >
> > In Nepal we have been trying to make sure that each constructed building
> has its own footprint and is not connected to a neighbouring structure via
> a shared wall. We do this as in reality this is the case as each building
> structure though built next to each other has its own footprint
> (independent foundation).
>
>
> yes, you can find both situations: a single dividing wall used by both
> neighboring buildings (in Europe this occurs mostly with medieval
> buildings), or each building has its own walls (and foundations), but
> without a significant space between them (e.g. 2 cm of insulating material).
>
> I would treat both situations the same and use shared nodes, but maybe
> wouldn’t object if someone purposefully mapped the latter as 2
> almost-touching buildings, although the osm building ways usually describe
> the footprint of the completed building (i.e. with facades, cladding etc.)
> and not the raw load bearing structure.
>
> cheers,
> Martin
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-it] R: Re: Alberi Monumentali Provincia di Pistoia

[frali...@alice.it]

potresti inserire per ulteriori informazioni l'indirizzo della pro locolocale o 
dell'ufficio provinciale che ha editato l'elenco 




  Messaggio originale
 
Da: cascaf...@gmail.com
 
Data: 26-ott-2017 13.48
 
A: "openstreetmap list - italiano"
 
Ogg: Re: [Talk-it] Alberi Monumentali Provincia di Pistoia
 

 
Be'... sono 105 :-( faccio finta di non saperlo :-)
 

 
Una cosa a proposito di privacy: nel dataset appaiono i link per ogni
 
albero alla relativa scheda (pubblicata dalla Provincia di Pistoia)
 
dove ci sono ulteriori dettagli, tra i quali accesso o meno al punto
 
ed in questo caso nome, cognome e telefono del proprietario dell'area.
 
Posso inserire i tag operator e phone?
 

 
Il 25 ottobre 2017 14:43, Alessandro Palmas
 
 ha scritto:
 
> Il 25/10/2017 14:38, Cascafico Giovanni ha scritto:
 
>>
 
>> Ho aggiunto sulla umap [1] il layer "Alberi monumentali - corretto"
 
>> applicando un offset di x=-20 y=+73. A campione una dozzina di punti
 
>> sembrano corretti. Sono un centinaio di punti: devo fare tutto
 
>> l'ambaradan per l'import?
 
>>
 
>> [1] 
 http://umap.openstreetmap.fr/it/map/open-data-pistoia_174967
 
>
 
>
 
> Meno di 100 oggetti è considerata parte non sostanziale del DB, forse si
 
> potrebbe evitare.
 
>
 
> Alessandro
 
>
 
>
 
> ___
 
> 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
 

 



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

Re: [Talk-GB] OSM Standard Layer

[Philip Barnes]

I see it too, also this strange large building http://osm.org/5322


Missing maps rubbish...

Phil (trigpoint) 

On 26 October 2017 13:12:02 BST, Paul Berry  wrote:
>Has there been a change to the colours on the Standard Layer or has
>someone
>inadvertently turned the UK into heath/farmland in the last 24 hours?
>
>Visible at zoom level 13 only, it seems.
>
>Regards,
>*Paul*

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-ca] Severed Dick

[Julia C]

I grew up in this municipality, but not near that area and I am not a
mountain biker. I am not surprised by those names though... ugh they are
horrible.

Julia

On Wed, Oct 25, 2017 at 3:35 PM, Denis Carriere 
wrote:

> Unfortunately does names seem legit for that type of mountain bike trails,
> these are not the first mountain bike trails names I've seen with those
> types of names.
>
> Seems like source of these edits come from a reputable editor.
>
> *User: *BC Trail Guides
> 
> http://osmlab.github.io/osm-deep-history/#/way/402020482
> http://osmlab.github.io/osm-deep-history/#/way/402020492
>
> This doesn't look like this is a form form of vandalism, that's just BC
> Canada for you ;)
>
> *~~*
> *@DenisCarriere*
> *GIS Software & Systems Specialist*
>
> On Wed, Oct 25, 2017 at 11:03 AM, Frederik Ramm 
> wrote:
>
>> Hi,
>>
>>noticed a few funny trail names in this region near Vancouver:
>>
>> https://www.openstreetmap.org/#map=16/49.3365/-122.9791
>>
>> Quote possible they really *are* called "Severed Dick", "Shorn Scrotum",
>> and "Cunt Buster", in which case they're of course totally legit to have
>> on the map, however I've come across some made-up names like that in the
>> past too. Maybe someone can check.
>>
>> Bye
>> Frederik
>>
>> --
>> Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"
>>
>> ___
>> 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-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-GB] OSM Standard Layer

[Paul Berry]

Has there been a change to the colours on the Standard Layer or has someone
inadvertently turned the UK into heath/farmland in the last 24 hours?

Visible at zoom level 13 only, it seems.

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

Re: [Talk-it] Alberi Monumentali Provincia di Pistoia

[Cascafico Giovanni]

Be'... sono 105 :-( faccio finta di non saperlo :-)

Una cosa a proposito di privacy: nel dataset appaiono i link per ogni
albero alla relativa scheda (pubblicata dalla Provincia di Pistoia)
dove ci sono ulteriori dettagli, tra i quali accesso o meno al punto
ed in questo caso nome, cognome e telefono del proprietario dell'area.
Posso inserire i tag operator e phone?

Il 25 ottobre 2017 14:43, Alessandro Palmas
 ha scritto:
> Il 25/10/2017 14:38, Cascafico Giovanni ha scritto:
>>
>> Ho aggiunto sulla umap [1] il layer "Alberi monumentali - corretto"
>> applicando un offset di x=-20 y=+73. A campione una dozzina di punti
>> sembrano corretti. Sono un centinaio di punti: devo fare tutto
>> l'ambaradan per l'import?
>>
>> [1] http://umap.openstreetmap.fr/it/map/open-data-pistoia_174967
>
>
> Meno di 100 oggetti è considerata parte non sostanziale del DB, forse si
> potrebbe evitare.
>
> Alessandro
>
>
> ___
> 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-ca] Carleton University Mapathon

[John Marshall]

I'm also available.

John

On Oct 26, 2017 06:17, "James"  wrote:

> Hey Kent, I'd be glad to help out :)
>
> On Oct 26, 2017 12:51 AM, "Kent Jacobs"  wrote:
>
>> Hello all!
>>
>>
>>
>> I am a Masters of Science student in the Geography department at Carleton
>> University studying Quality Assessment of OSM data for my thesis. I am also
>> currently employed at Employment and Social Development Canada as a
>> Geomatics Technician where I have been promoting the use of OSM data within
>> the department.
>>
>>
>>
>> I discussed the idea of a possible mapathon at Carleton University with
>> Statistics Canada, the Carleton Geography department and Mapbox. I am
>> reaching out (similar to Tim’s post above) to find additional OSM mappers
>> to assist us with the mapathon. I am fairly experienced with OSM myself but
>> I have never led a mapathon event. I am aware of COMS2200 issues with
>> contributions and do not want a repeat of this.  I believe focusing on
>> the OSM Canada Task Manager and rural/remote regions will help avoid poor
>> contributions.
>>
>>
>>
>> Any help is much appreciated!
>>
>>
>>
>> Regards,
>>
>> Kent
>>
>>
>>
>> ___
>> 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-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Carleton University Mapathon

[James]

Hey Kent, I'd be glad to help out :)

On Oct 26, 2017 12:51 AM, "Kent Jacobs"  wrote:

> Hello all!
>
>
>
> I am a Masters of Science student in the Geography department at Carleton
> University studying Quality Assessment of OSM data for my thesis. I am also
> currently employed at Employment and Social Development Canada as a
> Geomatics Technician where I have been promoting the use of OSM data within
> the department.
>
>
>
> I discussed the idea of a possible mapathon at Carleton University with
> Statistics Canada, the Carleton Geography department and Mapbox. I am
> reaching out (similar to Tim’s post above) to find additional OSM mappers
> to assist us with the mapathon. I am fairly experienced with OSM myself but
> I have never led a mapathon event. I am aware of COMS2200 issues with
> contributions and do not want a repeat of this.  I believe focusing on
> the OSM Canada Task Manager and rural/remote regions will help avoid poor
> contributions.
>
>
>
> Any help is much appreciated!
>
>
>
> Regards,
>
> Kent
>
>
>
> ___
> 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] Rilevazione IGN francese

[Alfredo Gattai]

Bello, certo che si potesse usare tutti un Trimble
professionalecomunque non disperiamo, considerando che ormai Galileo e'
operativo, che i chip cominciano ad essere a disposizione e che Samsung
(con l'universita' di Austiin) ha un progetto attivo di miniaturizzazione
del processore che corregge al volo il segnale dell'antenna, nel giro di un
paio d'anni, forse meno, protremmo avere precisioni de metro o addirittura
submetriche a portata di tutti o quasi.

Alfredo

2017-10-26 10:40 GMT+02:00 Andrea Musuruane :

> Ciao a tutti,
> ieri sera stavo guardando "Des racines & des ailes" su TV5Monde e, a
> un certo punto, hanno fatto vedere come IGN (http://www.ign.fr/) fa le
> sue rilevazioni, iniziando dal Colle del Piccolo San Bernardo.
>
> L'ho trovato interessante. Il video è disponibile qui:
> http://www.tv5mondeplus.com/toutes-les-videos/
> documentaire/des-racines-des-ailes-drda-a-travers-le-pays-
> de-savoie-09-12-2015
>
> Il segmento è a partire da 1:12:30. Il video è disponibile fino al 31
> ottobre 2017.
>
> Purtroppo online non ci sono sottotitoli (sul SAT erano disponibili varie
> lingue tra cui l'inglese).
>
> 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: [OSM-talk-fr] Rapprochement Bano

[Christian Quest]

Le 26 octobre 2017 à 11:16, marc marc  a écrit :

> Bonjour,
>
> Christian quand tu dis que Bano agrège différentes sources d'adresse
> opendata dont osm, comment a l'inverse les outils utilisent bano ?
>

ça, c'est à chaque outil qu'il faut poser la question...


> est-ce que nominatim ou un app utilise bano ?
>

A ma connaissance Nominatim n'utilise pas BANO.

D'autres apps l'utilisent peut être, on n'a pas de moyen simple de le
savoir, tout comme l'usage de données OSM par des applis d'une façon
générale.



> ou cela reste une superbe base composite mais utilisée uniquement
> pour l'édition manuelle d'som ?
>
>
Pas que vu le nombre important et régulier de téléchargements des données
sur bano.openstreetmap.fr
J'ai du mal à imaginer que ces fichiers soient régulièrement téléchargés
pour ne pas être utilisés.
On les retrouve même sur des plateformes régionales, exemple:
https://geobretagne.fr/geonetwork/apps/georchestra/?uuid=9ffb161b-d8d8-4ec4-bde5-a03104300df8

Je peux au moins te dire ce que moi j'en fais:
- j'ai une instance du géocodeur addok qui permet d'interroger BANO:
bano.addok.xyz
- je l'utilise chaque mois pour compléter le géocodage de la base SIRENE,
car BANO contient les infos sur les lieux-dits alors que la BAN est très
incomplète de ce côté.
- j'ai mis en place un "meta-géocodeur" le week-end dernier qui permet en
une requête d'interroger BANO, BAN et les POI d'OSM: all.addok.xyz


Le 26. 10. 17 à 10:40, Nicolas Moyroud a écrit :
> > Mais ce n'était pas sur la question des sources de données que portait
> > la remarque de mon message précédent, plutôt sur la façon de modéliser
> > les adresses dans OSM en France : ajout du numéro comme tag du bâtiment,
> > sur un noeud isolé, ou sur un noeud attaché au contour du bâtiment.
> > Une recommandation qui permette de clarifier et d'homogénéiser les
> > pratiques serait la bienvenue !
>
> Malheureusement, il n'y a aucune harmonisation a ce sujet.
> Même la page qui renseigne LES différentes méthodes utilisées
> n'est pas suivie partout. En résumé :
> Pour les numéros de bâtiments il y a 5 méthodes :
> - mettre le tag sur le bâtiment
> avantage : est géré par "tous" les outils
> désavantage : ne convient pas en cas de numéro multiple sur un bâtiment,
> ou d'un numéro pour plusieurs bâtiment (une école par exemple)
> - mettre le tag sur l'entrée du bâtiment
> avantage : permet de gérer les bâtiments multi-numéro
> désavantage : non supporté par les apps genre maps.me ce
> qui conduit à créer des doublons et pire à des incohérences.
> - mettre le tag sur un chemin fermé représentant +- la parcelle
> ou sur un multipolygone
> avantage : permet de gérer le cas d'un numéro multi-bâtiments
> désavantage : peu supporté niveau apps
> - mettre le tag sur un nœud hors du bâtiment, parfois situé à l'endroit
> de la boite aux lettre, à la connexion du chemin privé avec la voie
> publique, à l'endroit de la plaque avec le numéro ou l'endroit d’où
> elle est visible.
> avantage : j'en ai pas trouvé :) hormis la simplicité à la création
> (pas besoin de réfléchir dans lequel des cas précédent on se trouve)
> désavantage : oblige les outils à faire de la devinette pour trouver
> la bâtiment concerné. devinette qui a donc un taux d'erreur.
> Vu qu'il n'y a aucun lien entre le nœud isolé et le bâtiment,
> cela conduit comme dans le cas précédent a des doublons
>
> pour les rues, il y a 2 méthodes :
> - mettre addr:street sur l'objet qui possède addr:housenumber
> avantage : supporté par toutes les apps
> désavantage : donnée dupliquée
> - créer une associatedStreet qui lie les numéros d'une rue avec la rue
> avantage : maintenance que je trouve plus cohérente (le marque les
> numéros avec une changeset source=survey, je fais l'associatedStreet
> avec source=bano ou source=extrapolation)
> - désavantage : support limité dans les apps
>
> pour addr:city addr:postcode addr:country, 2 méthodes :
> - les gérer par des zones boundary (mais faudrait améliorer leur
> prise en compte par les apps)
> - les ajouter sur l'objet qui possède addr:housenumber (avantage :
> géré par tous les outils, désavantage : données dupliquées)
>
> Le détail est là
> http://wiki.openstreetmap.org/wiki/FR:Adresses
> https://wiki.openstreetmap.org/wiki/Key:addr
>
> Mais ceci dit, autant je suis d'accord qu'il serrait utile de commencer
> l'import des numéros de bâtiments pour les cas simple (par exemple
> lorsque bano renseigne un numéro unique sur un bâtiment) vu qu'en
> l'absence de cet import, on "consomme" du temps humain pour le faire,
> autant je suis aussi d'accord qu'il est plus utile de commencer par
> renseigner toutes les rues d'une commune avant de traiter les numéros.
>


Vu la diversité de modélisation des adresses dans OSM (pas qu'en France),
c'est là aussi que BANO est utile car ça remet tout ça sous une unique
forme simple et un réutilisateur ayant besoin d'adresses devrait plutôt
regarder de ce côté (pour la France) que de se prendre la tête avec 

Re: [Talk-de] Garmin gmapsupp.img funktioniert nicht mehr mit qlandkartegt / qmapshack

[Moritz]

Hallo Andreas,

kannst du mir die img files zukommen lassen, dann kann ich mal bei mir 
mit qmapshack schauen (1.9.1) ob's tut.

Habe qmapshack zuletzt im Sommer mit Openmtb Karten genutzt.

Alternativ könntest du dir img-Files von extract.bbbike.org runterladen.

Ich habe es gerade mit dieser Karte[1] und qmapshack probiert (falls sie 
nicht mehr verfügbar ist, dann hier[2] neu bauen).


Dann würdest du erstmal sehen, obs an dir oder den Karten liegt.


Was kann ich tun, um eine Tour zu planen und eine GPX-Ausgabe
zu bekommen (es müssen nun nicht notwendig diese Programme sein,
aber die Web-Routenplaner, die dann auf eine APP aufsetzen
nützen mir nichts).


Ich nutze inzwischen recht häufig brouter-web [3]. Da fällt dann ein GPX 
raus, was sich einfach auf den Garmin übertragen lässt.


Grüße
Moritz

[1]: 
https://download.bbbike.org/osm/extract/planet_13.076,52.391_13.769,52.684.osm.garmin-osm.zip
[2]: 
https://extract.bbbike.org/?sw_lng=13.076_lat=52.391_lng=13.769_lat=52.684=garmin-osm.zip=berlin

[3]: http://brouter.de/brouter-web/


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

Re: [OSM-talk-fr] Rapprochement Bano

[marc marc]

Bonjour,

Christian quand tu dis que Bano agrège différentes sources d'adresse 
opendata dont osm, comment a l'inverse les outils utilisent bano ?
est-ce que nominatim ou un app utilise bano ?
ou cela reste une superbe base composite mais utilisée uniquement
pour l'édition manuelle d'som ?

Le 26. 10. 17 à 10:40, Nicolas Moyroud a écrit :
> Mais ce n'était pas sur la question des sources de données que portait 
> la remarque de mon message précédent, plutôt sur la façon de modéliser 
> les adresses dans OSM en France : ajout du numéro comme tag du bâtiment, 
> sur un noeud isolé, ou sur un noeud attaché au contour du bâtiment.
> Une recommandation qui permette de clarifier et d'homogénéiser les 
> pratiques serait la bienvenue !

Malheureusement, il n'y a aucune harmonisation a ce sujet.
Même la page qui renseigne LES différentes méthodes utilisées
n'est pas suivie partout. En résumé :
Pour les numéros de bâtiments il y a 5 méthodes :
- mettre le tag sur le bâtiment
avantage : est géré par "tous" les outils
désavantage : ne convient pas en cas de numéro multiple sur un bâtiment, 
ou d'un numéro pour plusieurs bâtiment (une école par exemple)
- mettre le tag sur l'entrée du bâtiment
avantage : permet de gérer les bâtiments multi-numéro
désavantage : non supporté par les apps genre maps.me ce
qui conduit à créer des doublons et pire à des incohérences.
- mettre le tag sur un chemin fermé représentant +- la parcelle
ou sur un multipolygone
avantage : permet de gérer le cas d'un numéro multi-bâtiments
désavantage : peu supporté niveau apps
- mettre le tag sur un nœud hors du bâtiment, parfois situé à l'endroit 
de la boite aux lettre, à la connexion du chemin privé avec la voie 
publique, à l'endroit de la plaque avec le numéro ou l'endroit d’où
elle est visible.
avantage : j'en ai pas trouvé :) hormis la simplicité à la création
(pas besoin de réfléchir dans lequel des cas précédent on se trouve)
désavantage : oblige les outils à faire de la devinette pour trouver
la bâtiment concerné. devinette qui a donc un taux d'erreur.
Vu qu'il n'y a aucun lien entre le nœud isolé et le bâtiment,
cela conduit comme dans le cas précédent a des doublons

pour les rues, il y a 2 méthodes :
- mettre addr:street sur l'objet qui possède addr:housenumber
avantage : supporté par toutes les apps
désavantage : donnée dupliquée
- créer une associatedStreet qui lie les numéros d'une rue avec la rue
avantage : maintenance que je trouve plus cohérente (le marque les 
numéros avec une changeset source=survey, je fais l'associatedStreet 
avec source=bano ou source=extrapolation)
- désavantage : support limité dans les apps

pour addr:city addr:postcode addr:country, 2 méthodes :
- les gérer par des zones boundary (mais faudrait améliorer leur
prise en compte par les apps)
- les ajouter sur l'objet qui possède addr:housenumber (avantage :
géré par tous les outils, désavantage : données dupliquées)

Le détail est là
http://wiki.openstreetmap.org/wiki/FR:Adresses
https://wiki.openstreetmap.org/wiki/Key:addr

Mais ceci dit, autant je suis d'accord qu'il serrait utile de commencer 
l'import des numéros de bâtiments pour les cas simple (par exemple 
lorsque bano renseigne un numéro unique sur un bâtiment) vu qu'en 
l'absence de cet import, on "consomme" du temps humain pour le faire,
autant je suis aussi d'accord qu'il est plus utile de commencer par 
renseigner toutes les rues d'une commune avant de traiter les numéros.

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

Re: [OSM-talk-fr] Rapprochement Bano

[Christian Quest]

Les applis qui ont besoin d'adresses peuvent utiliser celles d'OSM et
compléter avec d'autres sources (BANO en est une).
Je rappelle aussi que BANO contient aussi les adresses présentes dans OSM
(mise à jour chaque nuit), ce qui simplifie la vie de ceux qui ont besoin
d'adresses qui n'ont du coup pas à refaire cette agrégation de sources.
BANO leur mâche le travail en agrégeant les adresses OSM, celles en
opendata et celles extraites du cadastre et en remettant tout ça au propre.

Quand on a démarré BANO, on s'est posé ces questions, et les tests
d'intégration d'adresses que j'ai fait à l'époque ont montré qu'il nous
faudrait au moins 10/15 ans pour tout intégrer dans OSM avec un minimum de
contrôle humain. Il suffit de voir qu'on n'a pas terminé les bâtiments,
alors que c'est plus simple à intégrer et qu'on a démarré en 2009 (et je ne
parle pas de la mise à jour).

Donc on a surtout poussé dès le départ à "dégommer du rouge", c'est à dire
avant tout à compléter les noms de rues manquantes dans OSM, car en plus ça
demande de l'intelligence humaine sans bien sûr empêcher ceux qui veulent
intégrer des adresses de la faire.
Donc si dans votre coin ajouter les adresses vous branche, n'hésitez pas...
mais pensez à dégommer le rouge si possible avant !

Le pire que j'ai vu, c'est l'import d'adresses, sans amélioration ou
contrôle... et sans avoir complété les noms des rues sur les highway voire
même sans highway du tout ! C'est typiquement ce qu'on a voulu éviter (et
qu'on a bien évité sauf très rares cas).

On va aussi pouvoir bien mieux exploiter les données du cadastre dans un
avenir très proche, vu qu'on a accès depuis quelques semaines aux données
EDIGEO brutes. Donc je patienterai un peu pour voir ce qu'on peu faire de
mieux que ce qui a été fait jusque maintenant avec les extractions faites
uniquement à partir de fichiers PDF sur cadastre.gouv.fr

Bien sûr, chacun est libre de contribuer comme il a envie, ce sont ici
juste des recommandations pour que le temps que nous passons tous à
contribuer soit le plus utile.
Globalement pour le projet OSM, pouvoir annoncer qu'un type de donnée est
"complet" comme on a pu le faire en 2012 quand on a terminé le découpage
communal est très positif.
En fléchant le "dégommage de rouge" comme prioritaire sur l'intégration des
adresses elles-même, on devrait pouvoir annoncer dans quelques mois que les
noms de rues sont "complets", alors que si on s'était dispersé sur les
adresses , je pense qu'on aurait mis quelques années de plus pour les noms
de rues ;)


Le 26 octobre 2017 à 09:51, Nicolas Moyroud  a écrit :

> Bonjour,
>
>> Mais quel est le plan pour les numéros ?
>> Parce que même si ils sont dans la BANO, ça ne m'aide pas lorsque je
>> cherche une adresse and Osmand, Maps.me ou autres.
>>
> 100% d'accord avec ça. L'argument "oui mais c'est déjà dans BANO" n'est
> pas à mon avis pas valable sur une liste qui concerne le projet OSM. En
> raisonnant comme ça on peut presque arrêter de contribuer à OSM en France,
> il y a déjà plein de données géographiques disponibles en OpenData un peu
> partout...
>
>> Et vu le temps que prend l'intégration des rues, une intégration
>> manuelle des numéros va prendre des décennies vu qu'il doit y avoir au
>> moins 10 fois plus de numéros.
>>
>> Mais sera-t-il possible de faire un import automatique ? Est-ce prévu ?
>>
>> Comment ça va se passer avec les adresses déjà présentes dans OSM ?
>>
> Il serait plus que temps de se demander comment on procède et quelles
> recommandations on propose pour l'intégration des numéros d'adresses dans
> OSM, plutôt que de reporter sans arrêt le problème à plus tard. Parce que
> là vu les chiffres indiqués par Donat on a presque fini le rapprochement
> des rues, donc il va falloir s'occuper avec autre chose dans pas longtemps
> ! ;-)
>
> Nicolas
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>



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

[Talk-it] Rilevazione IGN francese

[Andrea Musuruane]

Ciao a tutti,
ieri sera stavo guardando "Des racines & des ailes" su TV5Monde e, a un
certo punto, hanno fatto vedere come IGN (http://www.ign.fr/) fa le sue
rilevazioni, iniziando dal Colle del Piccolo San Bernardo.

L'ho trovato interessante. Il video è disponibile qui:
http://www.tv5mondeplus.com/toutes-les-videos/documentaire/des-racines-des-ailes-drda-a-travers-le-pays-de-savoie-09-12-2015

Il segmento è a partire da 1:12:30. Il video è disponibile fino al 31
ottobre 2017.

Purtroppo online non ci sono sottotitoli (sul SAT erano disponibili varie
lingue tra cui l'inglese).

Ciao,

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

Re: [OSM-talk-fr] Rapprochement Bano

[Nicolas Moyroud]

Par chez moi, je n'ajoute des numéros que si j'ai au préalable fait un 
repérage sur le terrain (photos, etc..) S'il me manque certains 
numéros, et que ceux que j'ai vérifiés correspondent bien avec 
Bano/Cadastre, alors je complète avec ces sources.
Merci pour ces précisons. En ce qui me concerne j'ai plus tendance à 
faire confiance directement aux données BANO/Cadastre en intégration 
directe, avec des vérifications terrain quand c'est possible. Je fais en 
général attention à bien marquer local_survey comme source de ceux que 
j'ai vérifié sur place.
Mais ce n'était pas sur la question des sources de données que portait 
la remarque de mon message précédent, plutôt sur la façon de modéliser 
les adresses dans OSM en France : ajout du numéro comme tag du bâtiment, 
sur un noeud isolé, ou sur un noeud attaché au contour du bâtiment.
Une recommandation qui permette de clarifier et d'homogénéiser les 
pratiques serait la bienvenue !


Nicolas

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

Re: [OSM-talk-fr] Rapprochement Bano

[Stéphane Péneau]

Le 26/10/2017 à 09:51, Nicolas Moyroud a écrit :
Il serait plus que temps de se demander comment on procède et quelles 
recommandations on propose pour l'intégration des numéros d'adresses 
dans OSM
Par chez moi, je n'ajoute des numéros que si j'ai au préalable fait un 
repérage sur le terrain (photos, etc..) S'il me manque certains numéros, 
et que ceux que j'ai vérifiés correspondent bien avec Bano/Cadastre, 
alors je complète avec ces sources.


Stéphane

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

Re: [OSM-talk-fr] Rapprochement Bano

[Nicolas Moyroud]

Bonjour,

Mais quel est le plan pour les numéros ?
Parce que même si ils sont dans la BANO, ça ne m'aide pas lorsque je
cherche une adresse and Osmand, Maps.me ou autres.
100% d'accord avec ça. L'argument "oui mais c'est déjà dans BANO" n'est 
pas à mon avis pas valable sur une liste qui concerne le projet OSM. En 
raisonnant comme ça on peut presque arrêter de contribuer à OSM en 
France, il y a déjà plein de données géographiques disponibles en 
OpenData un peu partout...

Et vu le temps que prend l'intégration des rues, une intégration
manuelle des numéros va prendre des décennies vu qu'il doit y avoir au
moins 10 fois plus de numéros.

Mais sera-t-il possible de faire un import automatique ? Est-ce prévu ?

Comment ça va se passer avec les adresses déjà présentes dans OSM ?
Il serait plus que temps de se demander comment on procède et quelles 
recommandations on propose pour l'intégration des numéros d'adresses 
dans OSM, plutôt que de reporter sans arrêt le problème à plus tard. 
Parce que là vu les chiffres indiqués par Donat on a presque fini le 
rapprochement des rues, donc il va falloir s'occuper avec autre chose 
dans pas longtemps ! ;-)


Nicolas

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

Re: [Talk-de] Deutsche Namens-Tags in Polen

[Martin Koppenhoefer]

sent from a phone

On 26. Oct 2017, at 08:11, Frederik Ramm  wrote:

>> Ausländer haben in fremden Ländern keine Namen zu mappen!
> 
> Wie viele der ca. 40 verschiedenen Namen für München sind wohl von dort
> lebenden Personen eingetragen ;)
> 
> https://www.openstreetmap.org/node/1700534808
> 
> Ist durchaus eine Diskussion, die man führen sollte - insbesondere, wo
> wir immer sagen, es gilt die "on the Ground"-Regel. Kurioserweise ist es
> vermutlich sehr schwierig für jemanden in München, "on the ground" zu
> verifizieren, ob die Stadt auch wirklich in alter weißrussischer
> Rechtschreibung "Мюнхэн" heisst. Das kann man vermutlich besser
> herausfinden, wenn man in Minsk ist...


der Begriff „Ausländer“ bezieht sich ja meist nicht nur auf den Wohnsitz 
sondern auch auf die Staatsbürgerschaft und teilweise sogar auf die Abstammung. 
In München leben so gesehen viele Ausländer, die da durchaus in einer ähnlichen 
Situation wie die Inländer sind, was die Ortskenntnis und Befähigung zum Mappen 
angeht.

Abgesehen von solchen Wortklaubereien kommen die meisten Sprachen der Namen 
vermutlich aus Wikipedia, da ist es egal wo der Mapper seinen Wohnsitz hat ;-)

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

Re: [OSM-talk-fr] Rapprochement Bano

[Francois Gouget]

On Wed, 25 Oct 2017, Christian Quest wrote:
[...]
> Pour les numéros, si on a envie de les intégrer on peut le faire, mais 
> ça prend beaucoup de temps et il semble bien plus utile dans un premier 
> temps d'avoir déjà toutes les rues nommées. Pour ceux qui de toute façon 
> ont besoin d'utiliser une base d'adresses, les données de BANO sont là ;)

Mais quel est le plan pour les numéros ?
Parce que même si ils sont dans la BANO, ça ne m'aide pas lorsque je 
cherche une adresse and Osmand, Maps.me ou autres.

Et vu le temps que prend l'intégration des rues, une intégration 
manuelle des numéros va prendre des décennies vu qu'il doit y avoir au 
moins 10 fois plus de numéros.

Mais sera-t-il possible de faire un import automatique ? Est-ce prévu ?

Comment ça va se passer avec les adresses déjà présentes dans OSM ? 

Est-ce que les adresses déjà présentes posent problème pour un import 
automatique des numéros ?

Pourrait-on commencer l'import automatique des numéros pour les villes 
où toutes les rues ont été rapprochées ?

Faudrait-il recommander à ceux qui travaillent sur l'intégration des 
rues d'ajouter une adresse à chaque intersection ? Cela permettrait aux 
utilisateurs d'OSM de savoir à peu près à quel endroit se trouve leur 
destination, ou au moins de résoudre ce problème typique lorsqu'on 
arrive à une intersection en voiture : pour trouver le 42, dois-je 
tourner à droite ou à gauche ?


-- 
Francois Gouget   http://fgouget.free.fr/
  Any sufficiently advanced Operating System is indistinguishable from Linux___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-de] Deutsche Namens-Tags in Polen

[Frederik Ramm]

Hi,

On 25.10.2017 18:44, Markus wrote:
> Ausländer haben in fremden Ländern keine Namen zu mappen!

Wie viele der ca. 40 verschiedenen Namen für München sind wohl von dort
lebenden Personen eingetragen ;)

https://www.openstreetmap.org/node/1700534808

Ist durchaus eine Diskussion, die man führen sollte - insbesondere, wo
wir immer sagen, es gilt die "on the Ground"-Regel. Kurioserweise ist es
vermutlich sehr schwierig für jemanden in München, "on the ground" zu
verifizieren, ob die Stadt auch wirklich in alter weißrussischer
Rechtschreibung "Мюнхэн" heisst. Das kann man vermutlich besser
herausfinden, wenn man in Minsk ist...

Bye
Frederik

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

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