Re: [OSM-talk] Missing day replicate

[Jochen Topf]

Hi!

this might or might not be related to the hourly change file with the
number 56107 being "strange": Osmosis can not read the file 107.osc.gz,
it reports a UTF-8 error. But if I gunzip the file, Osmosis can read the
file fine. So this points to an error in Osmosis' handling gzip'ed
files. Unfortunately Osmosis is no longer maintained.

Generally errors like this should probably be reported on
https://trac.openstreetmap.org/ or the dev mailing list or #osm-dev IRC
channel would be a good place.

Jochen

On Sat, Feb 09, 2019 at 11:49:45AM +1100, Andrew Davidson wrote:
> Date: Sat, 9 Feb 2019 11:49:45 +1100
> From: Andrew Davidson 
> To: talk@openstreetmap.org
> Subject: Re: [OSM-talk] Missing day replicate
> 
> Hasn't worked for three days now:
> 
> https://munin.openstreetmap.org/problems.html#critical
> 
> also the Planet dump is also not working. I'm not sure how we're supposed to
> report these, there used to be a status page on the wikki but that appears
> to no longer be the appropriate place.
> 
> On 8/2/19 8:22 am, Andre Hinrichs wrote:
> > Hi list,
> > 
> > I am missing the day replicate for today (2019-02-07)...
> > 
> > Hour and minute replicate seems to work ok.
> > 
> > Please check the process...
> > 
> > 
> > Greetings
> > 
> > Andre
> > 
> > 
> > 
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> > 
> https://munin.openstreetmap.org/problems.html#critical
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

-- 
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

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

Re: [OSM-talk-fr] Sensibiliser à OpenStreetMap - Dépliant OSM France

[Jean-Christophe Becquet]

Le 07/02/2019 17:03, Eric a écrit :
> FieldPapers fait référence à un outil en ligne qui permettait d'imprimer
> un fond de carte d'une zone pour ensuite servir de support à un relevé
> terrain. Cette fonction n'existe peut être plus...
> https://wiki.openstreetmap.org/wiki/Field_Papers

Bonjour,

Field Papers existe toujours* et il me semble qu'au départ, c'est le nom
du logiciel donc un nom propre. Du coup, je me dis c'est un peu comme si
on essayait de traduire OpenStreetMap non ?

* http://fieldpapers.org

Cela n’empêche pas dans l'explication de parler d'une feuille de route
imprimée ou d'un support papier pour faire des relevés sur le terrain.

Bon week-end

JCB
-- 
Conférence « Communs numériques - Cartes sensibles » 26 février à Digne
https://twitter.com/mairiedigne/status/1092322448769458177

==APITUX : le choix du logiciel libre==

APITUX - Jean-Christophe Becquet
2 chemin du Tivoli - 04000 Digne-les-Bains
06 25 86 07 92 - j...@apitux.com - http://www.apitux.com
SIRET : 452 887 441 00031 - APE : 6202A

===


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

Re: [talk-au] Turn lanes review

[Andrew Harvey]

I'm not sure I follow your example, but...

The rule of thumb is to only split the way when there is a physical
barrier preventing moving from one lane to the other.

As for Key:lanes, according to
https://wiki.openstreetmap.org/wiki/Key:lanes it's only for marked
lanes, but Microsoft has been adding many Key:lanes even when
unmarked, though there's a bit of discussion about this
https://wiki.openstreetmap.org/wiki/Talk:Key:lanes.

On Fri, 8 Feb 2019 at 08:41, Graeme Fitzpatrick  wrote:
>
> So what is considered "best practice" when it comes to lanes - physical or 
> theoretical markings?
>
> Situation: you have a two-lane, one-way, primary road with an exit coming up.
>
> Your road is marked as highway=primary, one_way=yes, lanes=2
>
> Should you map in an actual, physical lane splitting off to the left along 
> the curve of the exit ramp, marked as =primary_link, lanes=1; or change the 
> =primary to lanes=3, turn:lanes=slight_left|none|none?
>
> I'll openly admit that I add extra physical lanes because I think it "looks" 
> better that way & makes more sense to follow a "real" road on the map, rather 
> than just be told "turn slightly left".
>
> Thanks
>
> Graeme

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

[OSM-talk] How are you dealing with projects not following Organized Editing Guidelines?

[Erwin Olario]

Have you had any challenges getting local projects and initiatives to
follow the minimum requirements set forth in the Organized Editing
Guidelines (OEG)?

For many projects, especially those who've been conducting of organized
editing in the past, they don't seem to be aware, or worse, are ignoring
these guidelines.

Sometimes, we only get to find out about projects after the fact, when we
notice a huge surge in edits for example, or encounter issues related to
new contributors adding edits.

In our community in the Philippines, we've always encouraged these project
organizers (especially if we know people involve in them) to document their
efforts  on the Wiki in the past, and the OEG definitely expanded what we
should expect from them. Compliance, however, is another matter.

/Erwin
-- 

/Erwin Olario

e: er...@ngnuity.xyz | v/m: https://t.me/GOwin | s: https://mstdn.io/@GOwin
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Missing day replicate

[Andrew Davidson]

Hasn't worked for three days now:

https://munin.openstreetmap.org/problems.html#critical

also the Planet dump is also not working. I'm not sure how we're 
supposed to report these, there used to be a status page on the wikki 
but that appears to no longer be the appropriate place.


On 8/2/19 8:22 am, Andre Hinrichs wrote:

Hi list,

I am missing the day replicate for today (2019-02-07)...

Hour and minute replicate seems to work ok.

Please check the process...


Greetings

Andre



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


https://munin.openstreetmap.org/problems.html#critical

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

Re: [OSM-talk-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Florimond Berthoux]

Eh eh, j'ai trouvé un bon exemple de l'utilité du cycleway:left=opposite
https://www.openstreetmap.org/way/560073590

Certains considèrent cycleway:left=opposite invalide d'autre tout à fait
valide.
Tu viens vite en besogne, ce n'est qu'une polémique, rien de décidé.
Il n'y a rien à corriger à ce sujet ;)

D'autre part, une requête Overpass sur Paris
> (https://overpass-turbo.eu/s/FVI) retourne 103 chemins avec
> cycleway:left=opposite, qui si j'y bien suivi la discussion précédente
> est considéré comme invalide aujourd'hui. Ne devrait-on pas corriger ces
> valeurs et éventuellement rajouter une analyse qualité dessus ?
>


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

Re: [Talk-br] RES: Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

>...não vejo o mínimo sentido acochambrar as coisas...
Alguém falou em acochambrar algo?
O discutido deste tópico, como no título, é para ver se uma necessidade 
apontada é real ou não.
Sendo argumentado que ela é mesmo real, já foi concordado aqui que ela é uma 
"necessidade necessária".

> A verdade é uma só, os aplicativos de roteirização são “cobrados” pelos seus 
> usuários pelas imprecisões que apresentem, então quem os implementa quer tudo 
> perfeito saindo do mapa, mas por a mão na massa para fazer ou arcar com os 
> custos são outros quinhentos.

Sim, lembro com isso de aproveitar para divulgar o projeto abaixo em andamento, 
pedindo igualmente se puder divulgar, e/ou colaborar. Se já colaborou, obrigado.
https://apoie.me/osmbrasilcuritiba


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: Reinaldo Neves 
Enviado: sexta-feira, 8 de fevereiro de 2019 17:43
Para: 'OpenStreetMap no Brasil'
Assunto: [Talk-br] RES: Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

A verdade é uma só, os aplicativos de roteirização são “cobrados” pelos seus 
usuários pelas imprecisões que apresentem, então quem os implementa quer tudo 
perfeito saindo do mapa, mas por a mão na massa para fazer ou arcar com os 
custos são outros quinhentos.

Alias é justamente para sair dos custos de licença de Google e here que alguns 
utilizam OSM.

Quanto ao uso apenas de número e posição geográfica para gerar uma rota, por 
mais que funcione na maioria dos casos pode gerar vultas enormes em casos de 
áreas com logradouros tendo mão e contramão ou que cruzem linha férrea, 
viadutos, etc...

Por último, endereço por definição é um conjunto de dados (nome de rua, número 
de casa, prédio ou terreno etc.) que tornam possível a localização de um imóvel 
e/ou designam o próprio imóvel, sendo assim não vejo o mínimo sentido 
acochambrar as coisas para importar dados parciais apenas porque são úteis para 
um ou outro.

___

Reinaldo Neves
Equação Informática
☎: (11) 3221-3722
✉: rne...@equacao.com.br
http://br.linkedin.com/in/rrneves
https://medium.com/Reinaldo_Neves

De: Sérgio V. [mailto:svo...@hotmail.com]
Enviada em: sexta-feira, 8 de fevereiro de 2019 15:17
Para: Fernando Trebien; OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber



- - - - - - - - - - - - - - - -
Sérgio - http://www.openstreetmap.org/user/smaprs


De: Fernando Trebien 
Enviado: sexta-feira, 8 de fevereiro de 2019 14:47
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

On Fri, Feb 8, 2019 at 11:49 AM Sérgio V.  wrote:
>
> De: Nelson A. de Oliveira 
> Enviado: sexta-feira, 8 de fevereiro de 2019 10:38
>
> >É o que também indicam...
>
> Hum...São definições contraditórias:
> -uma diz que "um programa pode" assumir o nome da rua mais próxima;
> -outra que "deve" estar em "associatedStreet relation".

Poder pode, mas nem sempre dá certo. Com frequência falha nas esquinas
por causa da distância entre o ponto e as ruas. Como constam nas
referências do Nelson, as aplicações esperam que esta seja a exceção e
não a regra.

> Afinal, qual diz o que efetivamente é necessário?
>
> Aí nestes casos surge a dúvida evidente: quem definiu assim, diferente? E por 
> quê?
> Me parece que a definição parte mais de quem tem interesse no benefício do 
> uso do resultado do trabalho todo feito,
> do que de quem tem que realizar o trabalho.

Nesse momento nós estamos limitados pela capacidade das nossas
ferramentas. Dependemos do ecossistema feito fora do Brasil.

> Até agora, do que entendo, é o aplicativo, este sim, que vai se beneficiar 
> "sem esforço" nesta parte,
> ganhar dados a mais de graça, como "mágica", para fazer a navegação de modo 
> mais "fácil" e "rápido"...
> ...e ainda ganhar dinheiro com isso.

A licença dos dados do OSM permite que qualquer consumidor ganhe
dinheiro com o nosso trabalho, contanto que atribua ao OSM o crédito
pelos dados.

// Sim, isso eu sei. Não é isso que tá questionado ali. Pode ganhar dinheiro.
O questionamento todo é que, "além" de ganhar dinheiro coo o uso dos dados,
ganha recebendo um trabalho "extra" mastigado que o aplicativo mesmo pode fazer.


--
Fernando Trebien

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


---
Este e-mail foi verificado quanto a vírus pelo AVG.
http://www.avg.com


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

Re: [Talk-ca] Bike infrastructure in OSM

[James]

I know the bike enthusiasts have been using this tagging guide:
https://github.com/BikeOttawa/OSM-Bike-Ottawa-Tagging-Guide

On Fri., Feb. 8, 2019, 5:06 p.m. Harald Kliems,  wrote:

> I just learned that US-based bike advocacy organization People for Bikes
> is going to expand their "Bicycle Network Analysis" (BNA) to the following
> Canadian cities: Toronto, Calgary, Winnipeg, Vancouver, Ottawa, Halifax,
> Saskatoon, Edmonton, Montreal, Hamilton, Mississauga, Brampton.
>
> What is the BNA? It uses data about the a number of characteristics of
> roads and paths (e.g. number of lanes, speed limit, existence of bike
> lanes) to calculate a "traffic level of stress." For more detail, you can
> watch this presentation at SOTM-US:
> https://www.youtube.com/watch?v=YgyynQDPQnQ
>
> The first round of BNA analysis happened last year in a large number of US
> cities: https://bna.peopleforbikes.org/#/
>
> Of course, the analysis can only be as good as the underlying data, and so
> I'd encourage everyone to improve the tagging of bike-relevant
> infrastructure in those cities. There is a tagging guide available here:
> https://docs.google.com/document/d/1HuAXQUnCEcv9aLZyIDHkLTJ5ZSKfB-U4MlJSmN-1BLk/edit
>
> Apparently the data pull will be on February 16. So not a lot of time.
>
> I think it's a great project, and we have used it for our bike advocacy
> work in Madison (Wisconsin). And of course having great data about bike
> infrastructure in OSM is desirable outside of the project as well.
>
> Cheers,
>  Harald (hobbesvsboyle)
>
> --
> GPG Key-ID: 0x34cb93972f186565
> ___
> 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-fr] Moulinette pour ajouter "oneway:bicycle=no" ?

[Phyks]

Bonsoir,

Désolé, je suis un peu perdu dans le fil…

>> Le cas S1 est un exemple, ce qui prévaut ce sont les définitions des tags
>> et des attributs.
>> S'il faut documenter toutes les combinaisons de tags/attributs on n'a pas
>> finit.
>>
> 
> Ben justement le wiki le permet et c'est le meilleur moyen pour que les
> données soient cohérentes.

Quelqu'un voit-il une raison pour ne pas éditer le wiki en vue
d'harmoniser sur la version anglaise qui utilise les cycleway:left/right
chaque fois que c'est utilisable (c'est à dire la plupart des cas, mais
*pas* opposite) ?


D'autre part, une requête Overpass sur Paris
(https://overpass-turbo.eu/s/FVI) retourne 103 chemins avec
cycleway:left=opposite, qui si j'y bien suivi la discussion précédente
est considéré comme invalide aujourd'hui. Ne devrait-on pas corriger ces
valeurs et éventuellement rajouter une analyse qualité dessus ?

Bonne soirée,
-- 
Phyks

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

[Talk-ca] Bike infrastructure in OSM

[Harald Kliems]

I just learned that US-based bike advocacy organization People for Bikes is
going to expand their "Bicycle Network Analysis" (BNA) to the following
Canadian cities: Toronto, Calgary, Winnipeg, Vancouver, Ottawa, Halifax,
Saskatoon, Edmonton, Montreal, Hamilton, Mississauga, Brampton.

What is the BNA? It uses data about the a number of characteristics of
roads and paths (e.g. number of lanes, speed limit, existence of bike
lanes) to calculate a "traffic level of stress." For more detail, you can
watch this presentation at SOTM-US:
https://www.youtube.com/watch?v=YgyynQDPQnQ

The first round of BNA analysis happened last year in a large number of US
cities: https://bna.peopleforbikes.org/#/

Of course, the analysis can only be as good as the underlying data, and so
I'd encourage everyone to improve the tagging of bike-relevant
infrastructure in those cities. There is a tagging guide available here:
https://docs.google.com/document/d/1HuAXQUnCEcv9aLZyIDHkLTJ5ZSKfB-U4MlJSmN-1BLk/edit

Apparently the data pull will be on February 16. So not a lot of time.

I think it's a great project, and we have used it for our bike advocacy
work in Madison (Wisconsin). And of course having great data about bike
infrastructure in OSM is desirable outside of the project as well.

Cheers,
 Harald (hobbesvsboyle)

-- 
GPG Key-ID: 0x34cb93972f186565
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] Doublons landuse=residential et place=town

[Phyks]

Bonsoir,
Le 04/02/2019 à 14:18, osm.sanspourr...@spamgourmet.com a écrit :
> L'autre question est : est-ce qu'un name sur landuse=residential a un
> sens quand ce nom est celui de la commune (sauf à avoir une commune
> purement dortoir sans autre activité) ?

Pour moi c'est en effet le problème. Que le landuse soit imprécis, ce
n'est pas très grave et le travail itératif d'OSM fait qu'on peut le
corriger ultérieurement, mais le problème ici semble être que le
landuse=residential se situe sur le même objet que le
boundary=administrative.

Une correction pourrait être de créer un deuxième objet, identique au
boundary=administrative pour porte le tag landuse=residential seul.
Serait-ce une correction acceptable ?


J'ai essayé d'extraire les boundary=administrative + landuse=residential
avec Overpass, mais la requête demande trop de RAM visiblement. J'ai une
(petite) base PostGIS avec Auvergne + Ile de France, et j'ai trouvé pour
l'instant les 30 entrées suivantes qui sont concernées :

 Quartier Châtillon   | residential
 Paris 16e Arrondissement | residential
 Juvisy-sur-Orge  | residential
 Malakoff | residential
 Montrouge| residential
 Cachan   | residential
 Arcueil  | residential
 Gentilly | residential
 Le Kremlin-Bicêtre   | residential
 Paris 15e Arrondissement | residential
 Paris 14e Arrondissement | residential
 Paris 7e Arrondissement  | residential
 Paris 13e Arrondissement | residential
 Paris 6e Arrondissement  | residential
 Paris 1er Arrondissement | residential
 Paris 5e Arrondissement  | residential
 Paris 4e Arrondissement  | residential
 Paris 3e Arrondissement  | residential
 Ivry-sur-Seine   | residential
 Paris 11e Arrondissement | residential
 Paris 20e Arrondissement | residential
 Paris 12e Arrondissement | residential
 Paris 17e Arrondissement | residential
 Paris 8e Arrondissement  | residential
 Clichy   | residential
 Paris 9e Arrondissement  | residential
 Paris 2e Arrondissement  | residential
 Paris 10e Arrondissement | residential
 Paris 18e Arrondissement | residential
 Paris 19e Arrondissement | residential


Bonne soirée,
-- 
Phyks

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

[Talk-at] AGIT 2019

[scubbx]

Hallo, Leute!

Auch dieses Jahr wird es einen OSM / OsGeo / FOSSGIS Bereich mit eigenem
Vortragsprogramm auf der AGIT in Salzburg vom 03.07.2019 bis 05.07.2019
geben! https://www.agit.at/

Die AGIT ist die größte Konferenz und Fachmesse zum Thema angewandte
GeoInformation. Sie teilt sich in den Vortragsbereich (teure Tickets,
Konferenzprogramm) und die EXPO (vergleichsweise günstige Tickets,
Messe, ein Vortragsraum mit hauptsächlich Produktpräsentationen).

Der OsGeo Park ist ein kleiner Bereich auf der EXPO, auf dem der
FOSSGIS, und somit auch OpenStreetMap die Möglichkeit haben, die
OpenSource Szene und Produkte vorzustellen. Ich bin begeisterter
Besucher der AGIT und halte das Ausstellen dort für sehr sinnvoll.

Zusätzlich dazu gibt es wieder für einen Nachmittag die Möglichkeit,
explizit Vorträge zu OsGeo zu halten, die Einreichfrist dafür hängt
nicht mit jener der AGIT zusammen. Bei Interesse bitte an mich wenden!
Die Organisation erfolgt über das FOSSGIS-Wiki:
https://www.fossgis.de/wiki/AGIT_2019

Es wäre toll, wenn sich ein paar Leute finden würden, die bei der
Standbetreuung mithelfen könnten (geht auch Tageweise). Auch wenn sich
der ein oder andere Vortrag ausgehen würde, wäre das spitze. Leider ist
meine derzeitige Information, dass man sich für die Vorträge mit dem
ermäßigten (!) Tarif von 220€ anmelden muss - bei reinen
Community-basierten Vorträgen kann da der FOSSGIS Verrein möglicherweise
etwas zuschießen (?) . Aber das muss noch geklärt werden.
Für die Standbetreuung muss ich noch in Erfahrung bringen, ob wir
Freikarten erhalten - ansonsten denke ich, dass dort der FOSSGIS oder
der OSM-AT Verein einspringen könnten.

Überlegt es euch, es macht echt Spaß dort! Damit man sich ein besseres
Bild machen kann, verlinke ich euch hier die Berichte von der AGIT 2018:

Vortag: https://www.openstreetmap.at/2018/07/agit-2018-vorbereitung/
Tag 1: https://www.openstreetmap.at/2018/07/agit-2018-tag-1/
Tag 2: https://www.openstreetmap.at/2018/07/agit-2018-tag-2/
Tag 3: https://www.openstreetmap.at/2018/07/agit-2018-tag-3/

Beste Grüße,
Markus
(ScubbX)


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

[Talk-br] RES: Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Reinaldo Neves]

A verdade é uma só, os aplicativos de roteirização são “cobrados” pelos seus 
usuários pelas imprecisões que apresentem, então quem os implementa quer tudo 
perfeito saindo do mapa, mas por a mão na massa para fazer ou arcar com os 
custos são outros quinhentos.

Alias é justamente para sair dos custos de licença de Google e here que alguns 
utilizam OSM.

Quanto ao uso apenas de número e posição geográfica para gerar uma rota, por 
mais que funcione na maioria dos casos pode gerar vultas enormes em casos de 
áreas com logradouros tendo mão e contramão ou que cruzem linha férrea, 
viadutos, etc...

Por último, endereço por definição é um conjunto de dados (nome de rua, número 
de casa, prédio ou terreno etc.) que tornam possível a localização de um imóvel 
e/ou designam o próprio imóvel, sendo assim não vejo o mínimo sentido 
acochambrar as coisas para importar dados parciais apenas porque são úteis para 
um ou outro.

___

Reinaldo Neves
Equação Informática
☎: (11) 3221-3722
✉: rne...@equacao.com.br
http://br.linkedin.com/in/rrneves
https://medium.com/Reinaldo_Neves

De: Sérgio V. [mailto:svo...@hotmail.com] 
Enviada em: sexta-feira, 8 de fevereiro de 2019 15:17
Para: Fernando Trebien; OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber



- - - - - - - - - - - - - - - -
Sérgio - http://www.openstreetmap.org/user/smaprs


De: Fernando Trebien 
Enviado: sexta-feira, 8 de fevereiro de 2019 14:47
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber 
 
On Fri, Feb 8, 2019 at 11:49 AM Sérgio V.  wrote:
>
> De: Nelson A. de Oliveira 
> Enviado: sexta-feira, 8 de fevereiro de 2019 10:38
>
> >É o que também indicam...
>
> Hum...São definições contraditórias:
> -uma diz que "um programa pode" assumir o nome da rua mais próxima;
> -outra que "deve" estar em "associatedStreet relation".

Poder pode, mas nem sempre dá certo. Com frequência falha nas esquinas
por causa da distância entre o ponto e as ruas. Como constam nas
referências do Nelson, as aplicações esperam que esta seja a exceção e
não a regra.

> Afinal, qual diz o que efetivamente é necessário?
>
> Aí nestes casos surge a dúvida evidente: quem definiu assim, diferente? E por 
> quê?
> Me parece que a definição parte mais de quem tem interesse no benefício do 
> uso do resultado do trabalho todo feito,
> do que de quem tem que realizar o trabalho.

Nesse momento nós estamos limitados pela capacidade das nossas
ferramentas. Dependemos do ecossistema feito fora do Brasil.

> Até agora, do que entendo, é o aplicativo, este sim, que vai se beneficiar 
> "sem esforço" nesta parte,
> ganhar dados a mais de graça, como "mágica", para fazer a navegação de modo 
> mais "fácil" e "rápido"...
> ...e ainda ganhar dinheiro com isso.

A licença dos dados do OSM permite que qualquer consumidor ganhe
dinheiro com o nosso trabalho, contanto que atribua ao OSM o crédito
pelos dados.

// Sim, isso eu sei. Não é isso que tá questionado ali. Pode ganhar dinheiro.
O questionamento todo é que, "além" de ganhar dinheiro coo o uso dos dados,
ganha recebendo um trabalho "extra" mastigado que o aplicativo mesmo pode fazer.


-- 
Fernando Trebien

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


---
Este e-mail foi verificado quanto a vírus pelo AVG.
http://www.avg.com


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

Re: [OSM-talk-fr] Accès réservé au transport de fonds

[osm . sanspourriel]

Le 08/02/2019 à 19:35, marc marc - marc_marc_...@hotmail.com a écrit :


access=delivery me paraît convenir.

c'est pour les livraisons au sens large (y compris la camionnette du
magasin du coin ou la livraison fr pizza


Et à une banque on livre de l'argent, ça correspond bien au wiki "Par 
exemple, l'attribut access=delivery appliqué à une voie de service 
(highway =service 
) indique 
que cette voie ne peut être utilisée que pour les livraisons, quel que 
soit le mode de transport (voiture, camionnette, camion, vélo, etc)."


On voit rarement des transports de fond autrement qu'en véhicule dédié. 
Ou alors avec des valises, mais ça on le le cartographie pas.


Et elle nous en pique aussi, mais ça on ne le cartographie pas non plus.

Jean-Yvon

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

Re: [OSM-talk-fr] Accès réservé au transport de fonds

[Gwenaël Jouvin via Talk-fr]

À cet endroit il n’y a pas de panneau mais le marquage au sol, tracé sur 
l’ancien modèle des places de livraison (cadre jaune avec une croix de St-André 
jaune) porte le mot « sécurité ».
La proximité d’un établissement bancaire ne laisse guère de doute sur l’usage.

J’avais au départ la même idée, du style delivery=yes mais avec quelque chose 
de plus précis que la livraison générale. Rien vu sur taginfo non plus…


Le 08/02/2019 à 19:35, marc marc a écrit :
> Le 08.02.19 à 17:59, Jean-Claude Repetto a écrit :
>> Le 08/02/2019 à 17:43, Gwenaël Jouvin via Talk-fr a écrit :
>>> réservé aux véhicules de transport de fonds
> 
> qu'est-ce qui est écrit exactement sur le panneau ?
> je penche pour un access=no + access:=yes
> 
>> access=delivery me paraît convenir.
> 
> c'est pour les livraisons au sens large (y compris la camionnette du 
> magasin du coin ou la livraison fr pizza
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

Re: [OSM-talk-fr] Relations de cédez-le-passage cycliste incomplètes

[Gwenaël Jouvin via Talk-fr]

Pour moi c’est invalide car on ne connaît pas les mouvements autorisés, qui se 
déduisent des membres from et to, les rues d’origine et d’arrivée.

Ceci dit je comprends bien le raccourci pris ici puisque ces relations sont 
vraiment pénibles à cartographier, je m’étais « amusé » à Antony, à cet endroit 
où tous les mouvements sont autorisés…
http://overpass-turbo.eu/s/FVB


Gwenaël

P.S. : peut-être que dans cette rue, le contributeur veut encore 20 000 F pour 
créer les relations…



Le 08/02/2019 à 18:51, Phyks a écrit :
> Bonjour,
> 
> Le wiki mentionne qu'une relation de cédez-le-passage cycliste (aux
> feux) devrait être une relation de type restriction, avec un membre
> from, un membre to et un membre via
> (https://wiki.openstreetmap.org/wiki/FR:Bicycle#Panonceaux_de_C.C3.A9dez-le-passage_cycliste_au_feu).
> 
> Pourtant, de nombreuses telles relations sont incomplètes avec
> uniquement un membre "via". Cela ne me semble pas très utilisable. C'est
> le cas par exemple de https://www.openstreetmap.org/relation/7507011.
> 
> Y a-t-il un sens particulier dans ce cas-ci, absent du wiki ? On
> pourrait comprendre qu'il s'agit de tous les mouvements de "tourne à
> droite" possibles, mais cela me paraît hasardeux vu qu'on voit désormais
> apparaître des panneaux "cédez le passage" pour des mouvements "va tout
> droit ou à droite", voir pour tous les mouvements possibles.
> 
> Si ces relations sont invalides, je pourrais regarder pour essayer
> d'ajouter une règle à Osmose (je ne crois pas qu'il y en ait).
> 
> Merci !
> Bonne soirée,
> 

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

Re: [OSM-talk-fr] Accès réservé au transport de fonds

[marc marc]

Le 08.02.19 à 17:59, Jean-Claude Repetto a écrit :
> Le 08/02/2019 à 17:43, Gwenaël Jouvin via Talk-fr a écrit :
>> réservé aux véhicules de transport de fonds

qu'est-ce qui est écrit exactement sur le panneau ?
je penche pour un access=no + access:=yes

> access=delivery me paraît convenir.

c'est pour les livraisons au sens large (y compris la camionnette du 
magasin du coin ou la livraison fr pizza
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Relations de cédez-le-passage cycliste incomplètes

[Axelos]

Bonsoir,

Le 08/02/2019 à 18:51, Phyks a écrit :
> Le wiki mentionne qu'une relation de cédez-le-passage cycliste (aux
> feux) devrait être une relation de type restriction, avec un membre
> from, un membre to et un membre via
> (https://wiki.openstreetmap.org/wiki/FR:Bicycle#Panonceaux_de_C.C3.A9dez-le-passage_cycliste_au_feu).
> 
> Pourtant, de nombreuses telles relations sont incomplètes avec
> uniquement un membre "via". Cela ne me semble pas très utilisable. C'est
> le cas par exemple de https://www.openstreetmap.org/relation/7507011.

De fait, une relation avec un seul membre est inutile, ajouter les
attributs directement sur le membre revient au même.

> Y a-t-il un sens particulier dans ce cas-ci, absent du wiki ? On
> pourrait comprendre qu'il s'agit de tous les mouvements de "tourne à
> droite" possibles, mais cela me paraît hasardeux vu qu'on voit désormais
> apparaître des panneaux "cédez le passage" pour des mouvements "va tout
> droit ou à droite", voir pour tous les mouvements possibles.

C'est une piste à suivre, qui effectivement permettrait d'éviter de
créer quatre relations !

Axel.

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Peter Krauss]

Oi Nelson, se formos pelo caminho do OpenAddresses, seria preciso de uma
tag de acurácia ou confiabilidade, ou um simples boolean indicando que
street foi inferida.
... Sem essa informação fica realmente um monte de dado "no limbo", em
utilidade,
Ver discussão   https://github.com/openaddresses/openaddresses/issues/4238



On Fri, Feb 8, 2019 at 1:06 PM Nelson A. de Oliveira 
wrote:

> Pegando um outro projeto https://openaddresses.io/
>
> Nele existe obrigatoriedade de número e nome de rua (senão não se
> forma um endereço)
>
> https://github.com/openaddresses/openaddresses/blob/master/CONTRIBUTING.md#attribute-tags
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] IBGE convidando para dia 20/2 para uma conversa

[Thierry Jean]

Caros,

Estou mantendo contato com o IBGE depois das minhas visitas lá, e recebi hoje 
este email. Estarei na minha terra até o dia 27/2. Espero que Arlindo, ou outra 
pessoa do RJ poderá ir a esta reunião.


Em atenção à divulgação do Censo Agropecuário de 2017, o Instituto Brasileiro 
de Geografia e Estatística – IBGE, dentro de seu plano de trabalho, tornará 
públicas as informações referentes aos trajetos percorridos pelos recenseadores 
ao longo da operação e que estarão disponíveis em um novo produto a ser lançado 
no decorrer desse semestre.

Entende-se por trajetos, os caminhos percorridos pelos recenseadores desde o 
limite da sua área de trabalho (setor censitário) até os estabelecimentos 
agropecuários, utilizando vias públicas, estradas, caminhos rurais, acessos em 
áreas particulares, entre outros. Esses trajetos foram obtidos a partir da 
captura de coordenadas em campo por dispositivos móveis com GPS e passaram por 
um processamento posterior em escritório, finalizado com a produção de arquivos 
digitais compostos por linhas em formato vetorial.

Nesse sentido, convidamos as instituições e empresas interessadas em apoiar o 
IBGE na divulgação deste produto, principalmente aquelas que atuam na área de 
geolocalização, a participar de uma reunião no dia 20 de fevereiro de 2019, às 
14 horas.

Essa reunião visa apresentar esse produto às instituições e empresas 
interessadas, sendo que há a possibilidade de uma disponibilização antecipada 
para incorporação nos bancos de dados e sites das interessadas em troca de 
apoio à sua divulgação. Por ocasião da reunião, serão fornecidas mais 
informações sobre as possibilidades de cooperação.

As instituições e empresas interessadas em participar desta reunião devem 
confirmar presença através do 
e-mailmbu...@ibge.gov.br.

Local da reunião:  IBGE - Centro de Documentação e Disseminação de Informações

 Rua General Canabarro, 706 - Maracanã, Rio 
de Janeiro – RJ

==
Maria do Carmo Dias Bueno
Coordenação de Projetos Especiais
Centro de Documentação e Disseminação de Informações - CDDI
Instituto Brasileiro de Geografia e Estatística - IBGE
Rua General Canabarro, 706 sala 227
20271-205 Maracanã - Rio de Janeiro - RJ
Tel: (+55 21) 2142-4702
Email: maria.bu...@ibge.gov.br

Thierry Jean
M. +55 11 99607 1319


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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

E ao que me parece, mesmo errando, são erros muito pequenos.

Não erra do outro lado da cidade ou do bairro. Erra o lado da esquina apenas.
Se for só lado de esquina, desce do carro e bate na porta. Se não for esta, 
bate na do lado.

Precisa-se que o aplicativo mostre a porta certa na esquina, na rua do lado 
certo?
Mesmo que tenha isto devidamente escrito em "addr:housenumber + addr:street",
com os erros de 10 a 20m de GPS (mais ainda em centros, cânion urbano),
não vai ter a precisão desejada, pode errar a indicação de todo modo.

Quais outros erros pode haver?

Um trabalho gigantesco esperado, de complementar 200.000 endereços,
(mais o que houver mundo afora),
- por um "possível" erro que pode acontecer só em esquinas (10%);
- e que, ainda que corrigido, "não" vai fazer diferença, pois o sinal de GPS 
erra mais.

É isso mesmo?

Custo x benefício:
Beneficia a quem?
Custa pra quem?

- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: Sérgio V. 
Enviado: sexta-feira, 8 de fevereiro de 2019 15:39
Para: santamariense; OpenStreetMap no Brasil
Assunto: RE: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

Aliá, como que um aplicativo roteia o endereço?

Não é o usuário escrevendo na busca?:
Rua = Rua X
Nº= 10

Como vai errar a rua, se já escreveu ela

Ok, pode ter outro Nº10 na rua Y ao lado, bem na esquina com a Rua X.
Então são "dois Nº= 10", um em cada lado da esquina X com Y.

Ainda assim o roteamento vai chegar na mesma esquina.
Mesmo que erre em qual lado da esquina estiver.
Não é?

Mas se quiser mais precisão, acertar
"qual dos dois Nº= 10 é o da Rua X"?

Ora, aquele que estiver próximo de um número qualquer na sequência da rua X:

---  (RUA Y)
15   |
--   |
10   |
---   - - - - - - - - - - - - - -  (RUA X)
(ESQ.) | 10 | 40 |
  ^ ^







- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: santamariense 
Enviado: sexta-feira, 8 de fevereiro de 2019 14:31
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

> As ruas da prefeitura tão no conjunto separado, EIXOS, da SMURB, que também 
> não interessa porque não é igual ao OSM.
> O que vale são os nomes que tão no OSM.

O ideal é que o nome dos logradouros bata 100% com o nome dos
logradouros nos housenumbers, mas isso não interfere em nada o
funcionamento de aplicativos. Ao meu ver poderia ser importado com os
nomes conforme estão na base da prefeitura se fosse o caso.

> Para o OSM, então, ok, terão que ser adicionados estes campos, quando 
> faltantes, a milhares de objetos.

Provavelmente quase todo housenumber que chegou ao OSM sem addr:street
ou relação veio por meio de importações. Naturalmente, "qualquer"
mapeador que for adicionar um endereço no mapa já vai assim fazer com
com o nome da rua junto.

89% dos addr:housenumber tem addr:street -
https://taginfo.openstreetmap.org/keys/addr%3Ahousenumber#combinations

Podemos dar uma sondada, em um primeiro momento, para ver se achamos
uma solução >automatizada< de com o ponto e seu ângulo, e a com uma
geometria de ruas extraídas do OSM conseguir obter o nome das ruas.

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

[OSM-talk-fr] Relations de cédez-le-passage cycliste incomplètes

[Phyks]

Bonjour,

Le wiki mentionne qu'une relation de cédez-le-passage cycliste (aux
feux) devrait être une relation de type restriction, avec un membre
from, un membre to et un membre via
(https://wiki.openstreetmap.org/wiki/FR:Bicycle#Panonceaux_de_C.C3.A9dez-le-passage_cycliste_au_feu).

Pourtant, de nombreuses telles relations sont incomplètes avec
uniquement un membre "via". Cela ne me semble pas très utilisable. C'est
le cas par exemple de https://www.openstreetmap.org/relation/7507011.

Y a-t-il un sens particulier dans ce cas-ci, absent du wiki ? On
pourrait comprendre qu'il s'agit de tous les mouvements de "tourne à
droite" possibles, mais cela me paraît hasardeux vu qu'on voit désormais
apparaître des panneaux "cédez le passage" pour des mouvements "va tout
droit ou à droite", voir pour tous les mouvements possibles.

Si ces relations sont invalides, je pourrais regarder pour essayer
d'ajouter une règle à Osmose (je ne crois pas qu'il y en ait).

Merci !
Bonne soirée,
-- 
Phyks

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

Aliá, como que um aplicativo roteia o endereço?

Não é o usuário escrevendo na busca?:
Rua = Rua X
Nº= 10

Como vai errar a rua, se já escreveu ela

Ok, pode ter outro Nº10 na rua Y ao lado, bem na esquina com a Rua X.
Então são "dois Nº= 10", um em cada lado da esquina X com Y.

Ainda assim o roteamento vai chegar na mesma esquina.
Mesmo que erre em qual lado da esquina estiver.
Não é?

Mas se quiser mais precisão, acertar
"qual dos dois Nº= 10 é o da Rua X"?

Ora, aquele que estiver próximo de um número qualquer na sequência da rua X:

---  (RUA Y)
15   |
--   |
10   |
---   - - - - - - - - - - - - - -  (RUA X)
(ESQ.) | 10 | 40 |
  ^ ^







- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: santamariense 
Enviado: sexta-feira, 8 de fevereiro de 2019 14:31
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

> As ruas da prefeitura tão no conjunto separado, EIXOS, da SMURB, que também 
> não interessa porque não é igual ao OSM.
> O que vale são os nomes que tão no OSM.

O ideal é que o nome dos logradouros bata 100% com o nome dos
logradouros nos housenumbers, mas isso não interfere em nada o
funcionamento de aplicativos. Ao meu ver poderia ser importado com os
nomes conforme estão na base da prefeitura se fosse o caso.

> Para o OSM, então, ok, terão que ser adicionados estes campos, quando 
> faltantes, a milhares de objetos.

Provavelmente quase todo housenumber que chegou ao OSM sem addr:street
ou relação veio por meio de importações. Naturalmente, "qualquer"
mapeador que for adicionar um endereço no mapa já vai assim fazer com
com o nome da rua junto.

89% dos addr:housenumber tem addr:street -
https://taginfo.openstreetmap.org/keys/addr%3Ahousenumber#combinations

Podemos dar uma sondada, em um primeiro momento, para ver se achamos
uma solução >automatizada< de com o ponto e seu ângulo, e a com uma
geometria de ruas extraídas do OSM conseguir obter o nome das ruas.

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

Re: [talk-cz] Administrativní hranice

[xkomc...@centrum.cz]

první co mne napadlo je neuzavřený polygon, který tímto chtěl render 
uzavřít. Ale proklikal jsem všechny relace, ve kterých jsou navazující 
hranice a vše vypadá v pořádku.


On 08. 02. 19 16:06, Jan Macura wrote:
P. S. Zkusil jsem přeházet pořadí členů v relaci, uvidíme, jestli to 
bude ono...


H.

On Fri, 8 Feb 2019 at 15:59, Jan Macura > wrote:


Ahoj,

netuší někdo, proč se renderuje ta pofidérní rovná čára mezi
obcemi Pelechy a Pasečnice:
https://openstreetmap.cz/#map=15/49.3864/12.9031=dX ? V
datech nakreslená není, boundary relace obou obcí vypadají ok,
nikdo na nich v poslední době nic neměnil. Nerozumím tomu...

Díky
 H.


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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: Fernando Trebien 
Enviado: sexta-feira, 8 de fevereiro de 2019 14:47
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

On Fri, Feb 8, 2019 at 11:49 AM Sérgio V.  wrote:
>
> De: Nelson A. de Oliveira 
> Enviado: sexta-feira, 8 de fevereiro de 2019 10:38
>
> >É o que também indicam...
>
> Hum...São definições contraditórias:
> -uma diz que "um programa pode" assumir o nome da rua mais próxima;
> -outra que "deve" estar em "associatedStreet relation".

Poder pode, mas nem sempre dá certo. Com frequência falha nas esquinas
por causa da distância entre o ponto e as ruas. Como constam nas
referências do Nelson, as aplicações esperam que esta seja a exceção e
não a regra.

> Afinal, qual diz o que efetivamente é necessário?
>
> Aí nestes casos surge a dúvida evidente: quem definiu assim, diferente? E por 
> quê?
> Me parece que a definição parte mais de quem tem interesse no benefício do 
> uso do resultado do trabalho todo feito,
> do que de quem tem que realizar o trabalho.

Nesse momento nós estamos limitados pela capacidade das nossas
ferramentas. Dependemos do ecossistema feito fora do Brasil.

> Até agora, do que entendo, é o aplicativo, este sim, que vai se beneficiar 
> "sem esforço" nesta parte,
> ganhar dados a mais de graça, como "mágica", para fazer a navegação de modo 
> mais "fácil" e "rápido"...
> ...e ainda ganhar dinheiro com isso.

A licença dos dados do OSM permite que qualquer consumidor ganhe
dinheiro com o nosso trabalho, contanto que atribua ao OSM o crédito
pelos dados.

// Sim, isso eu sei. Não é isso que tá questionado ali. Pode ganhar dinheiro.
O questionamento todo é que, "além" de ganhar dinheiro coo o uso dos dados,
ganha recebendo um trabalho "extra" mastigado que o aplicativo mesmo pode fazer.


--
Fernando Trebien

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: santamariense 
Enviado: sexta-feira, 8 de fevereiro de 2019 14:31
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

>> As ruas da prefeitura tão no conjunto separado, EIXOS, da SMURB, que também 
>> não interessa porque não é igual ao OSM.
>> O que vale são os nomes que tão no OSM.

>O ideal é que o nome dos logradouros bata 100% com o nome dos
>logradouros nos housenumbers, mas isso não interfere em nada o
>funcionamento de aplicativos. Ao meu ver poderia ser importado com os
>nomes conforme estão na base da prefeitura se fosse o caso.

Neste caso não ajuda nada os nomes de rua da PMPA nos vetores linha do 
EIXOS_TMPOA.SHP.
O trabalho é mais simples (se isso for simples) com os próprios vetores do OSM,
pois são os do OSM os de interesse, já tá tudo correto, são os mais 
compatíveis, alinhados, e nomes adequados.

>> Para o OSM, então, ok, terão que ser adicionados estes campos, quando 
>> faltantes, a milhares de objetos.

>Provavelmente quase todo housenumber que chegou ao OSM sem addr:street
>ou relação veio por meio de importações. Naturalmente, "qualquer"
>mapeador que for adicionar um endereço no mapa já vai assim fazer com
>com o nome da rua junto.

Eu poucas vezes adicionava addr:street. Só addr:housenumber.
Não sabia da obrigação. Ainda mais que a rua já tá escrita no vetor que tá ao 
lado do mesmo endereço. Sempre achava redundante, preciosismo. Sempre achei que 
era ilógico duplicar a mesma informação que já consta na rua nomeada. (não sei 
se o Google faça isso, duplicar as informações... e se o faz deve ser 
automatizado)
E sempre achei que os endereço eram encontrados  simplesmente por:
nome no "vetor da rua" +  número no "outro objeto" (polígono de prédio; 
ponto...) próximo à rua
Isso resolveria uns 90% dos casos.
Os casos de esquina, ambíguos, devem ser uns 10%.

Ainda assim, mesmo que erre a rua,
"qual das duas ruas da esquina que contém o número tal"
o que pode errar é só a rua, não o ponto.
Ainda assim, o roteamento chega lá. Não é verdade?
Não consigo entender onde tá o problema para roteamento.

>89% dos addr:housenumber tem addr:street -
>https://taginfo.openstreetmap.org/keys/addr%3Ahousenumber#combinations

>Podemos dar uma sondada, em um primeiro momento, para ver se achamos
>uma solução >automatizada< de com o ponto e seu ângulo, e a com uma
>geometria de ruas extraídas do OSM conseguir obter o nome das ruas.

Ainda assim não penso só no caso de PoA.
Penso pra todas as importações que possam ser assim.

Supõe um tempo disponível enorme, que não é algo viável em sistema 
"colaborativo".

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

Re: [OSM-talk-fr] Accès réservé au transport de fonds

[Jean-Claude Repetto]

Le 08/02/2019 à 17:43, Gwenaël Jouvin via Talk-fr a écrit :

Bonjour,

J’aimerais indiquer qu’un emplacement de stationnement est réservé aux 
véhicules de transport de fonds, peinturlurées « sécurité » comme on en croise 
près des banques, mais je ne vois pas cette catégorie (cash transport ?) sur la 
page access :
https://wiki.openstreetmap.org/wiki/Key:access

Des idées ? Merci.



Bonjour,

access=delivery me paraît convenir.

Jean-Claude

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Fernando Trebien]

On Fri, Feb 8, 2019 at 11:49 AM Sérgio V.  wrote:
>
> De: Nelson A. de Oliveira 
> Enviado: sexta-feira, 8 de fevereiro de 2019 10:38
>
> >É o que também indicam...
>
> Hum...São definições contraditórias:
> -uma diz que "um programa pode" assumir o nome da rua mais próxima;
> -outra que "deve" estar em "associatedStreet relation".

Poder pode, mas nem sempre dá certo. Com frequência falha nas esquinas
por causa da distância entre o ponto e as ruas. Como constam nas
referências do Nelson, as aplicações esperam que esta seja a exceção e
não a regra.

> Afinal, qual diz o que efetivamente é necessário?
>
> Aí nestes casos surge a dúvida evidente: quem definiu assim, diferente? E por 
> quê?
> Me parece que a definição parte mais de quem tem interesse no benefício do 
> uso do resultado do trabalho todo feito,
> do que de quem tem que realizar o trabalho.

Nesse momento nós estamos limitados pela capacidade das nossas
ferramentas. Dependemos do ecossistema feito fora do Brasil.

> Até agora, do que entendo, é o aplicativo, este sim, que vai se beneficiar 
> "sem esforço" nesta parte,
> ganhar dados a mais de graça, como "mágica", para fazer a navegação de modo 
> mais "fácil" e "rápido"...
> ...e ainda ganhar dinheiro com isso.

A licença dos dados do OSM permite que qualquer consumidor ganhe
dinheiro com o nosso trabalho, contanto que atribua ao OSM o crédito
pelos dados.

-- 
Fernando Trebien

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

[OSM-talk-fr] Accès réservé au transport de fonds

[Gwenaël Jouvin via Talk-fr]

Bonjour,

J’aimerais indiquer qu’un emplacement de stationnement est réservé aux 
véhicules de transport de fonds, peinturlurées « sécurité » comme on en croise 
près des banques, mais je ne vois pas cette catégorie (cash transport ?) sur la 
page access :
https://wiki.openstreetmap.org/wiki/Key:access

Des idées ? Merci.

Gwenaël

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[santamariense]

> As ruas da prefeitura tão no conjunto separado, EIXOS, da SMURB, que também 
> não interessa porque não é igual ao OSM.
> O que vale são os nomes que tão no OSM.

O ideal é que o nome dos logradouros bata 100% com o nome dos
logradouros nos housenumbers, mas isso não interfere em nada o
funcionamento de aplicativos. Ao meu ver poderia ser importado com os
nomes conforme estão na base da prefeitura se fosse o caso.

> Para o OSM, então, ok, terão que ser adicionados estes campos, quando 
> faltantes, a milhares de objetos.

Provavelmente quase todo housenumber que chegou ao OSM sem addr:street
ou relação veio por meio de importações. Naturalmente, "qualquer"
mapeador que for adicionar um endereço no mapa já vai assim fazer com
com o nome da rua junto.

89% dos addr:housenumber tem addr:street -
https://taginfo.openstreetmap.org/keys/addr%3Ahousenumber#combinations

Podemos dar uma sondada, em um primeiro momento, para ver se achamos
uma solução >automatizada< de com o ponto e seu ângulo, e a com uma
geometria de ruas extraídas do OSM conseguir obter o nome das ruas.

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

Re: [Talk-GB] Possible Unattributed Map on Labrokes Website

[Tim Waters]

I think it's Blipstar  - a UK company who provide store locator tools

Looking at their example map
https://blipstar.com/blipstarplus/examples it seems to be the default
to hide the attribution (via CSS media query) on narrower window
widths

Tim

On Fri, 8 Feb 2019 at 13:31, Robert Whittaker (OSM lists)
 wrote:
>
> On Fri, 8 Feb 2019 at 09:43, Steve Pointer  wrote:
> > >Not sure if this is the right place to ask but is there anyone who can 
> > >look at https://thegrid.ladbrokes.com/en/shoplocator to see if they are 
> > >using OpenStreetmap data without proper attribution?
> >
> > In Firefox if you right click on the map -> This Frame -> Show only this 
> > frame
> >
> >  then the map has OSM tag at the bottom.
>
> Nice spot. The frame is showing
> https://viewer.blipstar.com/map?uid=2470030=10=true=nearest=auto==true=NW1
> . If you vary the width of the browser window it seems that the
> attribution at the bottom disappears if it's narrower than some
> critical value. Also, the attribution that is shown isn't technically
> compliant -- see https://www.openstreetmap.org/copyright . It appears
> the map etc is being provided as a service by http://www.blipstar.com/
> using a Mapbox map. I suspect it's one of those two that we really
> need to convince to do better with the attribution. Did I remember
> reading somewhere else that it was a known issue / bone of contention
> that Mapbox were providing a service with unattributed or incorrectly
> attributed maps to their clients?
>
> Robert.
>
> --
> Robert Whittaker
> https://osm.mathmos.net/
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

Ok. Se dados completos no OSM é aquela definição, então é.
O que não deixa de ser arbitrária: ela tem que ser assim devido à situação; 
porque não se tem capacidade de resolver de outro modo.
Neste material da prefeitura não tem addr:street direto. Possivelmente em 
muitas outras ao redor do mundo também não.
Tem número e coordenadas, e se viram com isto.
As ruas da prefeitura tão no conjunto separado, EIXOS, da SMURB, que também não 
interessa porque não é igual ao OSM.
O que vale são os nomes que tão no OSM.
Para o OSM, então, ok, terão que ser adicionados estes campos, quando 
faltantes, a milhares de objetos.
Possivelmente em diversas importações. Isto irá se repetir sempre.
Mesmo automatizadamente, exigirá muito tempo.
Precisará ter gente e tempo suficiente pra executar todo este exigido. Sempre.

- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: Nelson A. de Oliveira 
Enviado: sexta-feira, 8 de fevereiro de 2019 12:51
Para: OSM talk-br
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

On Fri, Feb 8, 2019 at 12:18 PM Sérgio V.  wrote:
> Quer dizer, o "deve" serve pra nós só?
> Tou vendo que a coisa toda tá como nós tendo o dever de preparar tudo 
> mastigado pra aplicativos.

O objetivo é ter os dados completos no OSM, independente de outros
implementarem ou não características desejáveis.

Pode ver pelo ponto de vista de um usuário qualquer, que quer pegar os
endereços do OSM: "ué, só tem número? o que eu faço com isso?"

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

Re: [talk-cz] Administrativní hranice

[Jan Macura]

P. S. Zkusil jsem přeházet pořadí členů v relaci, uvidíme, jestli to bude
ono...

H.

On Fri, 8 Feb 2019 at 15:59, Jan Macura  wrote:

> Ahoj,
>
> netuší někdo, proč se renderuje ta pofidérní rovná čára mezi obcemi
> Pelechy a Pasečnice:
> https://openstreetmap.cz/#map=15/49.3864/12.9031=dX ? V datech
> nakreslená není, boundary relace obou obcí vypadají ok, nikdo na nich v
> poslední době nic neměnil. Nerozumím tomu...
>
> Díky
>  H.
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Nelson A. de Oliveira]

Pegando um outro projeto https://openaddresses.io/

Nele existe obrigatoriedade de número e nome de rua (senão não se
forma um endereço)
https://github.com/openaddresses/openaddresses/blob/master/CONTRIBUTING.md#attribute-tags

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

[talk-cz] Administrativní hranice

[Jan Macura]

Ahoj,

netuší někdo, proč se renderuje ta pofidérní rovná čára mezi obcemi Pelechy
a Pasečnice: https://openstreetmap.cz/#map=15/49.3864/12.9031=dX ? V
datech nakreslená není, boundary relace obou obcí vypadají ok, nikdo na
nich v poslední době nic neměnil. Nerozumím tomu...

Díky
 H.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Nelson A. de Oliveira]

On Fri, Feb 8, 2019 at 12:18 PM Sérgio V.  wrote:
> Quer dizer, o "deve" serve pra nós só?
> Tou vendo que a coisa toda tá como nós tendo o dever de preparar tudo 
> mastigado pra aplicativos.

O objetivo é ter os dados completos no OSM, independente de outros
implementarem ou não características desejáveis.

Pode ver pelo ponto de vista de um usuário qualquer, que quer pegar os
endereços do OSM: "ué, só tem número? o que eu faço com isso?"

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

[talk-cz] SVG z openstreetmap.org obsahuje obyčejný bitmapový obrázek

[jiri.drbalek]

Problém vyřešen:

https://github.com/gravitystorm/openstreetmap-carto/issues/3653#issuecomment
-461818817





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

Re: [Talk-es] Toponimia en Cataluña

[David Marín Carreño]

Gracias, Lanxana, por tu mensaje y por el trabajo al redactar la página en
la wiki..

Estoy de acuerdo en todo lo que comentas.

El meollo (y lo que creo que puede darse a debate) es determinar si un
nombre de pueblo /se utiliza/ o no, ya que el uso puede ser distinto
dependiendo de si se realiza desde un punto de vista local o lejano.

Procedo a poner sugerencias desde mi particular punto de vista del centro
de Castilla.
--
David Marín Carreño 



El vie., 8 feb. 2019 a las 15:00, Lanxana . () escribió:

> Buenos días,
>
> He ido leyendo todos los mensajes escritos hasta ahora y con la mayoría
> estoy de acuerdo, aunque algunos los he encontrado totalmente fuera de
> lugar, pero no voy a ahondar más en la herida.
>
> De las opciones planteadas por Joan en su primer mensaje, me decanto por
> la 2, que aunque sea más trabajosa, reflejará mejor la situación actual de
> la toponimia.
>
> En algún mensaje leí que la toponimia histórica, o los nombres que haya
> tenido un elemento a lo largo de la historia no tienen cabida en OSM. En
> esto discrepo totalmente, creo que el etiquetado es suficiente flexible
> como para recoger estos cambios, y que disponer de estos datos engrandece
> el proyecto, facilitando hacer búsquedas en el mapa actual a partir de
> valores históricos… es decir, si estoy consultando un documento que hace
> referencia a un pueblo, y resulta que cambió de nombre y no sé su nombre
> actual, disponer del histórico me permitirá relacionar ese nombre antiguo
> con el nuevo. Lo mismo con las calles que cambiaron de nombre a lo largo
> del siglo XX.
>
> Por variar de caso, pongamos por ejemplo Banyoles, que en catalán se
> pronuncia parecido a  /bañolas/ y así se transcribió y se usó en textos
> oficiales durante un tiempo. Pues bien, si le pides a un navegador que te
> lleve a /bañolas/ no lo encuentra, hay que decirle /banioles/ para que lo
> haga… ¿etiquetamos para el navegador? ¿Etiquetamos para que el
> castellanoparlante pronuncie bien el nombre del pueblo? ¿Cómo sabemos si
> cuando pronuncia /bañolas/ se refiere a “Bañolas” o a “Banyoles” con
> pronunciación catalana?
>
> Otro ejemplo, una anécdota de un compañero de trabajo… llegó a Girona hará
> unos 20 años para estudiar y buscaba piso de alquiler. En la inmobiliaria
> le citaron en el cruce de las calles de “la Cruz” y “Mediodía”. Con buena
> agudeza dedujo que la “calle de la Cruz” podía ser la que en las placas
> ponía “Carrer de la Creu”, pero con “Mediodía” se estuvo casi medio día
> buscando, hasta que una señora que lo veía pasar calle arriba, calle abajo,
> le preguntó qué buscaba y le pudo indicar que esa “calle Mediodía” podía
> ser la traducción de “Carrer del Migdia”. No tengo el nomenclátor a mano, y
> no sé si alguna vez se llamó así o no, pero claramente si alguien
> etiquetara esta calle con name:es=Calle Mediodía, flaco favor estaría
> haciendo a los usuarios que desconozcan el catalán.
>
> Así que igual que ocurre con las calles, donde parece que está más
> extendido el consenso de que no tiene lógica que el name:es traduzca el
> nombre de la calle (a diferencia de calle por carrer,  kalea, o rúa), opino
> que con los nombres de los pueblos ocurre lo mismo. Una etiqueta name:es
> que recoja una traducción del nombre del pueblo, que se usó en otra época
> pero ya no se utiliza, no haría más que confundir.
>
> En todo caso, con objeto de conocer en qué casos nos encontramos con
> etiquetado name:es distinto al name oficial, listamos y trasladamos a la
> wiki (
> https://wiki.openstreetmap.org/wiki/ES:Toponimia_de_Catalunya_en_espa%C3%B1ol)
> una relación de localidades donde esto ocurre, y empezamos a investigar a
> qué son debidas las diferencias. No hay una solución mágica aplicable a
> todos los casos, en muchos habrá que investigar individualmente si siguen
> en uso o no.
>
>  Saludos!
>
> El jue., 7 feb. 2019 a las 18:26, Rafael Avila Coya ()
> escribió:
>
>> Hola, David:
>>
>> Sí se discutió en Telegram. Y en honor a la verdad, por simplicidad, yo
>> creí pertinente la opción A de dejar el name:es para que lo decidiese la
>> comunidad hispanohablante, a modo de separar una de la otra y no crear
>> mayor controversia. Quizás no caí en la cuenta, por aquel entonces, de
>> la existencia de old_name y otras etiquetas con date. El etiquetado en
>> OSM es muy flexible, y deberíamos aprovecharnos de ello.
>>
>> Saludos,
>>
>> Rafael.
>>
>> O 06/02/19 ás 22:44, David Marín Carreño escribiu:
>> > Gracias, Jaume por los enlaces y los información.
>> >
>> > Estoy tirando de historia en el correo de la lista y lo único que
>> > encuentro relacionado es que en noviembre de 2013 se comentó el caso de
>> > Sant Quirze y se llegó a un consenso sin problemas de ningún tipo,
>> > primando el sentido común.
>> >
>> > Estoy intentando encontrar más hilos respecto a esto, pero no encuentro
>> > ninguno. ¿Quizás se llevó a cabo esta discusión que comentas por
>> Telegram?
>> >
>> > El mié., 6 feb. 2019 20:49, Jaume Figueras i Jové
>> > 

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

>Os programas "podem" calcular, mas acho que nenhum faz isso.
>"Podem" (sugestão) é diferente de "devem" (obrigação).

Quer dizer, o "deve" serve pra nós só?
Tou vendo que a coisa toda tá como nós tendo o dever de preparar tudo mastigado 
pra aplicativos.
Me incluam fora desta.

E já disse: prevejo que não vai ter gente pra atender, sob estas atuais 
condições, para importações de endereços.
Mal se tem pra mapeamento básico.
Só pagando grupos pra fazer (é por isso que já tão acontecendo estes grupos.)


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: Nelson A. de Oliveira 
Enviado: sexta-feira, 8 de fevereiro de 2019 12:03
Para: OSM talk-br
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

On Fri, Feb 8, 2019 at 11:49 AM Sérgio V.  wrote:
> Hum...São definições contraditórias:
> -uma diz que "um programa pode" assumir o nome da rua mais próxima;
> -outra que "deve" estar em "associatedStreet relation".

Os programas "podem" calcular, mas acho que nenhum faz isso.
"Podem" (sugestão) é diferente de "devem" (obrigação).

O endereço pode estar associado com "addr:street" (que praticamente
tudo entende) ou relação street/associatedStreet (quem poucos
entendem).

> Quer dizer: em "muitos outros casos" seria "fácil" para o aplicativo fazer? 
> Deduz-se que sim.

Depende de como você vê isso: é mais fácil ter 100 implementações
fazendo a mesma coisa (calculando endereço) ou fazer isso apenas uma
vez? (nos dados do OSM)
Se existem 100 programas que usam os endereços e 50 não implementam
isso, metade dos usuários dos dados vão ficar sem a informação?
Como que se convence todos os programadores a fazer isso?
A responsabilidade é dos programadores em desenvolver algo que é
apenas desejável ou é do OSM, em ter os dados incompletos?

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

Claro, pode haver mais de 1 "número tal" (ex.Nº10) "perto" da rua, e dar 
ambiguidade.
Como numa esquina onde iniciam 02 ruas. As 02 podem ter 02 "Nº10" perto.

Neste caso, pode-se desempatar com os números próximos daquele primeiro, que 
estiverem na sequência com os demais "perto" da mesma rua.
-Em um caso, o próximo número da sequência vai necessariamente se afastar; o 
que exclui.
-No outro, o próximo número da sequência vai permanecer perto da rua em questão.

-- 20 --
--(15)--http://www.openstreetmap.org/user/smaprs


De: Sérgio V. 
Enviado: sexta-feira, 8 de fevereiro de 2019 11:57
Para: santamariense; OpenStreetMap no Brasil
Assunto: RE: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

>Notou se algum campo destes pontos teria algum código que
referenciasse um logradouro ao invés de diretamente o nome do
logradouro?

Ora:
-Cada "número" tem as suas "coordenadas";
-E no OSM tem as "ruas" já mapeadas, na frente (perto) destas coordenadas.
Isto não basta pra localizar "rua"e "número"?
Consigo pensar numa lógica simples:
1) abre-se o o aplicativo;
2) escreve a procura por: "rua tal", "numero tal";
3) ele localiza a rua;
4) ele procura dentre os nós mais próximos dela (na ordem dos mais próximos), 
aquele que tem o "numero tal".
Feito.
Os aplicativos não fazem isto? Ou querem a coisa mastigada e de graça?


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: santamariense 
Enviado: sexta-feira, 8 de fevereiro de 2019 11:34
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

Notou se algum campo destes pontos teria algum código que
referenciasse um logradouro ao invés de diretamente o nome do
logradouro?

> -Levantada a questão de que: "para um endereço ser localizado no OSM, precisa 
> ter ainda addr:street=*".

Eu diria que seria a melhor situação, a qual não geraria erros. Pontos
sem addr:street são associados ao logradouro mais próximo, ou seja,
nem sempre ao logradouro ao qual está registrado (como você comentou).
Em Paris por exemplo foi importado assim ( ex.:
https://www.openstreetmap.org/node/1916243227 ) com relação
type=associatedStreet. Creio que o nominatim não encontra pela
associatedStreet.

Não entendo muito. Mas não seria possível associar um logradouro
automaticamente pelo "angle" do ponto? No QGIS? Algum código? Talvez a
solução para esta questão esteja nele.

Se ninguém se dispuser a fazer esse trabalho manual, que se importe
assim mesmo. Estando no OSM a comunidade naturalmente pode ir
adicionado os dados faltantes como addr:(street/postalcode)

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Nelson A. de Oliveira]

On Fri, Feb 8, 2019 at 11:49 AM Sérgio V.  wrote:
> Hum...São definições contraditórias:
> -uma diz que "um programa pode" assumir o nome da rua mais próxima;
> -outra que "deve" estar em "associatedStreet relation".

Os programas "podem" calcular, mas acho que nenhum faz isso.
"Podem" (sugestão) é diferente de "devem" (obrigação).

O endereço pode estar associado com "addr:street" (que praticamente
tudo entende) ou relação street/associatedStreet (quem poucos
entendem).

> Quer dizer: em "muitos outros casos" seria "fácil" para o aplicativo fazer? 
> Deduz-se que sim.

Depende de como você vê isso: é mais fácil ter 100 implementações
fazendo a mesma coisa (calculando endereço) ou fazer isso apenas uma
vez? (nos dados do OSM)
Se existem 100 programas que usam os endereços e 50 não implementam
isso, metade dos usuários dos dados vão ficar sem a informação?
Como que se convence todos os programadores a fazer isso?
A responsabilidade é dos programadores em desenvolver algo que é
apenas desejável ou é do OSM, em ter os dados incompletos?

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

Re: [Talk-es] Toponimia en Cataluña

[Lanxana .]

Buenos días,

He ido leyendo todos los mensajes escritos hasta ahora y con la mayoría
estoy de acuerdo, aunque algunos los he encontrado totalmente fuera de
lugar, pero no voy a ahondar más en la herida.

De las opciones planteadas por Joan en su primer mensaje, me decanto por la
2, que aunque sea más trabajosa, reflejará mejor la situación actual de la
toponimia.

En algún mensaje leí que la toponimia histórica, o los nombres que haya
tenido un elemento a lo largo de la historia no tienen cabida en OSM. En
esto discrepo totalmente, creo que el etiquetado es suficiente flexible
como para recoger estos cambios, y que disponer de estos datos engrandece
el proyecto, facilitando hacer búsquedas en el mapa actual a partir de
valores históricos… es decir, si estoy consultando un documento que hace
referencia a un pueblo, y resulta que cambió de nombre y no sé su nombre
actual, disponer del histórico me permitirá relacionar ese nombre antiguo
con el nuevo. Lo mismo con las calles que cambiaron de nombre a lo largo
del siglo XX.

Por variar de caso, pongamos por ejemplo Banyoles, que en catalán se
pronuncia parecido a  /bañolas/ y así se transcribió y se usó en textos
oficiales durante un tiempo. Pues bien, si le pides a un navegador que te
lleve a /bañolas/ no lo encuentra, hay que decirle /banioles/ para que lo
haga… ¿etiquetamos para el navegador? ¿Etiquetamos para que el
castellanoparlante pronuncie bien el nombre del pueblo? ¿Cómo sabemos si
cuando pronuncia /bañolas/ se refiere a “Bañolas” o a “Banyoles” con
pronunciación catalana?

Otro ejemplo, una anécdota de un compañero de trabajo… llegó a Girona hará
unos 20 años para estudiar y buscaba piso de alquiler. En la inmobiliaria
le citaron en el cruce de las calles de “la Cruz” y “Mediodía”. Con buena
agudeza dedujo que la “calle de la Cruz” podía ser la que en las placas
ponía “Carrer de la Creu”, pero con “Mediodía” se estuvo casi medio día
buscando, hasta que una señora que lo veía pasar calle arriba, calle abajo,
le preguntó qué buscaba y le pudo indicar que esa “calle Mediodía” podía
ser la traducción de “Carrer del Migdia”. No tengo el nomenclátor a mano, y
no sé si alguna vez se llamó así o no, pero claramente si alguien
etiquetara esta calle con name:es=Calle Mediodía, flaco favor estaría
haciendo a los usuarios que desconozcan el catalán.

Así que igual que ocurre con las calles, donde parece que está más
extendido el consenso de que no tiene lógica que el name:es traduzca el
nombre de la calle (a diferencia de calle por carrer,  kalea, o rúa), opino
que con los nombres de los pueblos ocurre lo mismo. Una etiqueta name:es
que recoja una traducción del nombre del pueblo, que se usó en otra época
pero ya no se utiliza, no haría más que confundir.

En todo caso, con objeto de conocer en qué casos nos encontramos con
etiquetado name:es distinto al name oficial, listamos y trasladamos a la
wiki (
https://wiki.openstreetmap.org/wiki/ES:Toponimia_de_Catalunya_en_espa%C3%B1ol)
una relación de localidades donde esto ocurre, y empezamos a investigar a
qué son debidas las diferencias. No hay una solución mágica aplicable a
todos los casos, en muchos habrá que investigar individualmente si siguen
en uso o no.

 Saludos!

El jue., 7 feb. 2019 a las 18:26, Rafael Avila Coya ()
escribió:

> Hola, David:
>
> Sí se discutió en Telegram. Y en honor a la verdad, por simplicidad, yo
> creí pertinente la opción A de dejar el name:es para que lo decidiese la
> comunidad hispanohablante, a modo de separar una de la otra y no crear
> mayor controversia. Quizás no caí en la cuenta, por aquel entonces, de
> la existencia de old_name y otras etiquetas con date. El etiquetado en
> OSM es muy flexible, y deberíamos aprovecharnos de ello.
>
> Saludos,
>
> Rafael.
>
> O 06/02/19 ás 22:44, David Marín Carreño escribiu:
> > Gracias, Jaume por los enlaces y los información.
> >
> > Estoy tirando de historia en el correo de la lista y lo único que
> > encuentro relacionado es que en noviembre de 2013 se comentó el caso de
> > Sant Quirze y se llegó a un consenso sin problemas de ningún tipo,
> > primando el sentido común.
> >
> > Estoy intentando encontrar más hilos respecto a esto, pero no encuentro
> > ninguno. ¿Quizás se llevó a cabo esta discusión que comentas por
> Telegram?
> >
> > El mié., 6 feb. 2019 20:49, Jaume Figueras i Jové
> > mailto:jaume.figue...@masafi.cat>> escribió:
> >
> > Es que mucha cosa está en la lista pero creo que no se ha hecho caso,
> >
> > yopaseopor puso 4 enlaces, de la SGC, del BOE donde se refencia los
> > municipos castellanizados, cito BOE directo: "La Generalitat de
> > Catalunya, el 20 de abril de 1931, encomendó por decreto a la Secció
> > Filològica de I’Institut d’Estudis Catalans la revisión del nombre de
> > los municipios de Catalunya en cuanto a la ortografía, y el
> > establecimiento de la forma catalana de los que habían sido
> > castellanizados. En 1939, los nombres de esta lista fueron nuevamente
> >

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

>Notou se algum campo destes pontos teria algum código que
referenciasse um logradouro ao invés de diretamente o nome do
logradouro?

Ora:
-Cada "número" tem as suas "coordenadas";
-E no OSM tem as "ruas" já mapeadas, na frente (perto) destas coordenadas.
Isto não basta pra localizar "rua"e "número"?
Consigo pensar numa lógica simples:
1) abre-se o o aplicativo;
2) escreve a procura por: "rua tal", "numero tal";
3) ele localiza a rua;
4) ele procura dentre os nós mais próximos dela (na ordem dos mais próximos), 
aquele que tem o "numero tal".
Feito.
Os aplicativos não fazem isto? Ou querem a coisa mastigada e de graça?


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs


De: santamariense 
Enviado: sexta-feira, 8 de fevereiro de 2019 11:34
Para: talk-br@openstreetmap.org
Assunto: Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em 
importação de addr:housenumber

Notou se algum campo destes pontos teria algum código que
referenciasse um logradouro ao invés de diretamente o nome do
logradouro?

> -Levantada a questão de que: "para um endereço ser localizado no OSM, precisa 
> ter ainda addr:street=*".

Eu diria que seria a melhor situação, a qual não geraria erros. Pontos
sem addr:street são associados ao logradouro mais próximo, ou seja,
nem sempre ao logradouro ao qual está registrado (como você comentou).
Em Paris por exemplo foi importado assim ( ex.:
https://www.openstreetmap.org/node/1916243227 ) com relação
type=associatedStreet. Creio que o nominatim não encontra pela
associatedStreet.

Não entendo muito. Mas não seria possível associar um logradouro
automaticamente pelo "angle" do ponto? No QGIS? Algum código? Talvez a
solução para esta questão esteja nele.

Se ninguém se dispuser a fazer esse trabalho manual, que se importe
assim mesmo. Estando no OSM a comunidade naturalmente pode ir
adicionado os dados faltantes como addr:(street/postalcode)

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

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

De: Nelson A. de Oliveira 
Enviado: sexta-feira, 8 de fevereiro de 2019 10:38

>É o que também indicam...

Hum...São definições contraditórias:
-uma diz que "um programa pode" assumir o nome da rua mais próxima;
-outra que "deve" estar em "associatedStreet relation".

Afinal, qual diz o que efetivamente é necessário?

Aí nestes casos surge a dúvida evidente: quem definiu assim, diferente? E por 
quê?
Me parece que a definição parte mais de quem tem interesse no benefício do uso 
do resultado do trabalho todo feito,
do que de quem tem que realizar o trabalho.

>* a proposta original de endereçamento...
>...If not given a program may assume the name of the nearest street it can 
>find,
>but this is **not easy or fast to do** in all cases 

..."Nem todos os casos" é fácil para o aplicativo fazer
Quer dizer: em "muitos outros casos" seria "fácil" para o aplicativo fazer? 
Deduz-se que sim.
E ainda, seja fácil ou difícil, sempre seria "possível" de o aplicativo fazê-lo.
Ora, se pode, e não o faz, está transferindo aquilo que considera que "não é 
fácil" para que "nós" o façamos.


>Importação quase nunca é algo mágico, rápido e que sai sem esforço

Não considero o que tem-se até agora como feito "ainda sem esforço".
Já tem umas 60h de trabalho.

Me parece é que há um esforço "adicional", que depende de a quem caberá.

Até agora, do que entendo, é o aplicativo, este sim, que vai se beneficiar "sem 
esforço" nesta parte,
ganhar dados a mais de graça, como "mágica", para fazer a navegação de modo 
mais "fácil" e "rápido"...
...e ainda ganhar dinheiro com isso.



- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[santamariense]

Notou se algum campo destes pontos teria algum código que
referenciasse um logradouro ao invés de diretamente o nome do
logradouro?

> -Levantada a questão de que: "para um endereço ser localizado no OSM, precisa 
> ter ainda addr:street=*".

Eu diria que seria a melhor situação, a qual não geraria erros. Pontos
sem addr:street são associados ao logradouro mais próximo, ou seja,
nem sempre ao logradouro ao qual está registrado (como você comentou).
Em Paris por exemplo foi importado assim ( ex.:
https://www.openstreetmap.org/node/1916243227 ) com relação
type=associatedStreet. Creio que o nominatim não encontra pela
associatedStreet.

Não entendo muito. Mas não seria possível associar um logradouro
automaticamente pelo "angle" do ponto? No QGIS? Algum código? Talvez a
solução para esta questão esteja nele.

Se ninguém se dispuser a fazer esse trabalho manual, que se importe
assim mesmo. Estando no OSM a comunidade naturalmente pode ir
adicionado os dados faltantes como addr:(street/postalcode)

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

[Talk-at]  Mit. 13.02  Maptime Salzburg: Jupyter

[Jakob Miksch]

Hallo liebe Liste,

am Mittwoch findet wieder das nächste Maptime Salzburg Meetup statt. 
Siehe ausführliches Infos unten. Es wird dabei um Geo-Themen allgemein 
gehen, oft auch um OpenStreetMap.


Viele Grüße,
Jakob

PS: Bitte gebt mir Bescheid, falls diese Einladung "off-topic" ist und 
ich sie nicht mehr senden soll.



--

Hallo liebe Geo-Interessierte,

das Thema für unser nächstes Maptime Treffen geht um *Jupyter*.

Zeit: Mittwoch *13.Februar - 19:00 Uhr*
Ort: iDEAS:lab , Schillerstraße 30, 
Techno_Z Gebäude Nordseite 
 (Bauteil XV)


Es wird dazu (englisch-sprachige) Vorträge mit folgenden Themen geben:

 * Einführung in Jupyter
 * Module "Pandas" und "Seaborn"
 * PostgreSQL mit Jupyter
 * Präsentationen mit Jupyter


Wir treffen uns im iDEAS:lab in Itzling. Vielen Dank an Z_GIS 
 für die Bereitstellung der Räume! Für Getränke und 
Snacks ist gesorgt. Wer mag kann gerne selbst etwas mitbringen.


Aktuelle Infos gibt es auf http://maptime.io/salzburg/. Bei Fragen sind 
wir per Email erreichbar: maptime.salzb...@gmail.com Neue Teilnehmer 
sind herzlich willkommen. Wir freuen uns auf einen tollen Abend!


Viele Grüße,
Euer Maptime-Team
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Nelson A. de Oliveira]

On Fri, Feb 8, 2019 at 9:56 AM Sérgio V.  wrote:
> -Levantada a questão de que:
> "para um endereço ser localizado no OSM, precisa ter ainda addr:street=*".

Precisa.
Senão só se tem apenas um número "jogado" no mapa, sem associação com
qual rua ele pertence.

É o que também indicam:

* o validador do JOSM (House number without street/Número de casa sem rua)

* a wiki https://wiki.openstreetmap.org/wiki/Key:addr (com as várias
citações que precisa de addr:housenumber=* + addr:street=* e também
pela parte "Please do not only tag addr:housenumber=*, but also add at
least addr:street=* or addr:place=* for places without streets (or map
the belonging to a street with a relation using associatedStreet
relation or street relation.)"

* o plugin https://wiki.openstreetmap.org/wiki/JOSM/Plugins/FixAddresses
(que considera o endereço sem rua como incompleto/inválido)

* a proposta original de endereçamento
https://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema
(as chaves addr:*), onde diz para addr:street: "The (main) name of the
related street. If not given a program may assume the name of the
nearest street it can find, but this is not easy or fast to do in all
cases (especially at intersections), so putting the name in here is
strongly encouraged (more reliable)."

* o osmose https://wiki.openstreetmap.org/wiki/Osmose/issues#Missing_tags
(ver o item street numbers, onde diz ""addr:housenumber or
addr:housename without addr:street, addr:district, addr:neighbourhood,
addr:quarter, addr:suburb, addr:place or addr:hamlet must be in a
associatedStreet relation" : there is a portion of the needed tag
addr=*. They do not provide a consistent address.")

* o OSM Inspector https://tools.geofabrik.de/osmi/ na camada
"Addresses", que também indica os objetos com "No addr:street tag"


Os aplicativos poderiam fazer algum cálculo para obter o endereço a
partir da rua mais próxima, mas isso também geraria erros e
inconsistência de toda forma.
Também não tem garantia de que todos iriam calcular os endereços da
mesma forma, precisaria convencer todos os consumidores a fazer isso,
etc.

Talvez menos pior nesse caso é calcular as ruas automaticamente e
quebrar em várias áreas pequenas (arquivos .osm), pegando uma
quantidade de pessoas para verificar se esses endereços calculados
estão corretos (usando o plugin todo do JOSM facilita e torna mais
rápido olhar os dados e passar para a frente, caso estejam corretos).

Ir inserindo blocos pequenos no OSM, aos poucos, é melhor do que não
inserir nada.

Importação quase nunca é algo mágico, rápido e que sai sem esforço
(pode escolher qualquer uma dessas carinhas para representar isso: ,
, , , ☹️)

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

[Talk-br] Sobre a necessidade (ou não) de ter addr:street em importação de addr:housenumber

[Sérgio V .]

Trago aqui questão levantada,
da necessidade (ou não) de ter addr:street:
https://wiki.openstreetmap.org/wiki/Talk:Pt:Import/Catalogue/Brazil_PMPA_Addresses_Import

(esta questão é muito importante para esta e quaisquer outras importações do 
tipo de "endereços")

-Levantada a questão de que:
"para um endereço ser localizado no OSM, precisa ter ainda addr:street=*".

-Problema:
Nos dados originais não tem registrado nome da rua.
O que pode ser obtido do original é: addr:housenumber=* + coordenadas.

Necessidade (teórica ou real?): teria que complementar (adicionar) 
addr:street=* para todos os 200.000 nós. (?!?)

Dúvidas: Isso vale para qualquer endereço, para que possa ser localizado?

Possibilidades de executar:
a) automatizado: gerando e adicionando valores de "nome de rua" por análise de 
proximidade aos pontos: pode gerar erros;
b) manualmente: adicionando valores de "nome de rua" (preciso).

Objeções:

-É possível "retornar" o "nome de rua" por busca? Como com análise de 
proximidade? Os aplicativos podem operar assim? Isso não pode deixar para ser 
feito pelos aplicativos de localização/navegação, sob demanda? Se isso for 
possível, não necessitaria adicionar valor de "nome de rua", nem manualmente, 
nem automatizadamente. Simplesmente não adicionar addr:street.

-Se for real a "necessidade indispensável" de ter que constar ou "adicionar" 
addr:street=* a cada nó importado de addr:housenumber=* (mesmo onde não haja no 
original), então vai certamente inviabilizar inúmeras possibilidades de 
importações de endereços.

-Se tiver que adicionar, sobretudo "manualmente": trabalho gigantesco - 
esqueça-se, eu não faço; outros se quiserem peguem os dados ali 
disponibilizados e continuem.
De todo modo, certamente inviabiliza maior parte de futuras importações em 
outros locais.


- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-GB] Possible Unattributed Map on Labrokes Website

[Steve Pointer]

>Not sure if this is the right place to ask but is there anyone who can
>look at https://thegrid.ladbrokes.com/en/shoplocator to see if they are
>using OpenStreetmap data without proper attribution?
In Firefox if you right click on the map -> This Frame -> Show only
this frame
 then the map has OSM tag at the bottom.

SP


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

Re: [Talk-it] FOSS4G-IT 2019

[Alessandro Vitali]

Io sarò a 3 workshop!

Ale Vit


Mail
priva di virus. www.avg.com

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

Il giorno gio 7 feb 2019 alle ore 14:46 Alessandro Palmas <
alessandro.pal...@wikimedia.it> ha scritto:

> Buongiorno lista,
> vi ricordo che le registrazioni per Foss4G-IT 2019 terminano mercoledì
> 13 febbraio. Speriamo vi sia una buona partecipazione.
>
> http://foss4g-it2019.gfoss.it/registrazione
>
>
> Alessandro Ale_Zena_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-br] Proposta de Importação de endereços SMF/PMPA

[Peter Krauss]

PARABENS Sergio!

Não é uma tradição, mas convém solicitar que aqueles que participam em
geral deste fórum, que deem seu *voto*...

Na Wiki

o Sergio também esclareceu o processo em lote com figuras e detalhes
técnicos, ou seja,
*está transparente o que será feito no piloto automático*, e temos plena
confiança no "piloto do piloto automático", que é o Sergio.

Por mim, APROVADISSIMO!

- - -
PS: fica a sugestão de importar como CC0, se é que existe essa
possibilidade.


On Thu, Feb 7, 2019 at 5:12 PM Sérgio V.  wrote:

> Prezados/as,
>
> Envio aqui para avaliação da comunidade a documentação formalizada da
> Proposta de "Importação da camada de numeração de endereços da PMPA",
> conforme dados disponibilizados pela SMF/PMPA (Secretaria da
> Fazenda/Prefeitura Municipal de Porto Alegre).
>
> A proposta integral está documentada na seguinte página wiki, para
> avaliação:
>
> https://wiki.openstreetmap.org/wiki/Pt:Import/Catalogue/Brazil_PMPA_Addresses_Import
>
> Contém:
> -descrição da proposta;
> -documentação legal;
> -descrição dos procedimentos de exame, conversão, separação de conflitos
> encontrados, validação do material para importação;
> -listagem do material finalizado, preparado para importação;
> -links (ao final da página), para baixar os arquivos, para exames:
> 1) ZIP com os arquivos dos resultados finais em .osm 
> (SMF-RESULTADOS-FINAIS-OSM.zip
> 4,6MB), contendo:
> -OBJETOS VALIDADOS, preparados para importação:
>05 arquivos .osm  =  199.614 objetos (nós)
> -OBJETOS REMOVIDOS, com quaisquer conflitos, separados para
> avaliação caso-a-caso:
>03 arquivos .osm  = 6.444  objetos (nós)
> Total de objetos em .osm = 206.058
> 2) ZIP com os arquivos dos dados integrais originais
> (SMF-XLSX-ORIGINAIS.zip 55MB) ;  total original = 206.061 objetos
> (03 objetos destes 206.061 originais foram excluídos de início, cf.
> documentado na wiki: 01 objeto não importado por coordenada inválida, e
> 02 objetos removidos de início por campos nulo e inválido.)
>
> Apresento para avaliação da comunidade. A proposta pode ser alterada se
> necessário.
>
> (comentários podem ser na página de discussão da mesma wiki:
>
> https://wiki.openstreetmap.org/wiki/Talk:Pt:Import/Catalogue/Brazil_PMPA_Addresses_Import
>  )
>
> Creio que a importação pode suceder em cerca de 05 changesets para os
> validados. Ao menos estes 199.614 objetos validados (em 05 arquivos .osm)
> estão a princípio prontos para importação imediata ao OSM, em sendo
> aprovada a proposta.
> Os demais 6.444 separados por não validação necessitam de avaliação
> caso-a-caso, por conflitos diversos entre si e com o existente no OSM.
>
> Peço considerar um prazo inicial proposto de 2 semanas a partir da
> presente data para avaliações e considerações.
> Após o que, se não houver outras considerações ou alterações necessárias,
> propõe-se considerar apto à importação o material indicado como validado.
>
> Atenciosamente e à disposição,
>
> - - - - - - - - - - - - - - - -
>
> Sérgio - http://www.openstreetmap.org/user/smaprs
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br