Re: [Talk-at] Import der Gewässer im Raum Sankt Michael in Obersteiermark

[Friedrich Volkmann]

On 14.12.2015 23:45, Michael Reichert wrote:
> Folgende Punkte hast du noch nicht erfüllt:
> - Dokumentation im Wiki auf einer eigenen Seite
> - Benachrichtigung auf der Import-Mailingliste
> - Posting in eurem Forum (das ist nicht tot) http://
> forum.openstreetmap.org/viewforum.php?id=89
> - Import mit einem separaten Account durchführen
> - Dokumentation im Import-Katalog https://wiki.openstreetmap.org/wiki/
> Import/Catalogue
> 
> Bitte nimm die Hinweise ernst. Die Richtlinie wurde nicht aus Spaß 
> erfunden.

Die Richtlinie zu den krummen Gurken auch nicht. Man kann auch etwas
überreglementieren. Es handelt sich hier nicht um einen Monsterimport a la
TIGER oder plan.at, sondern um ein paar Gewässer rund um ein Dorf.
Angesichts dieses Umfangs finde ich Boruts Kommunikation völlig ausreichend,
und selbsternannte Ordnungshüter sind in solchen Angelegenheiten so nützlich
wie Pest und Cholera.

Betreffend das Webforum: Das ist nicht nur tot, sondern das war nie
lebendig. Es gibt seit jeher einen Konsens, dass wir für AT nicht zugleich
eine Mailingliste und ein Webforum brauchen. Wer auch immer das Webforum
eingerichtet hat, hat es gegen den Willen unserer Community gemacht.

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

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

Re: [Talk-us] SunCertPathBuilderException

[Clifford Snow]

I had the problem and created a bug report.
https://josm.openstreetmap.de/ticket/12192

JOSM is running the latest 9117 version. Version 9102 on another machine
did not have a problem.

Clifford

On Mon, Dec 14, 2015 at 3:27 PM, Steve Friedl  wrote:

> Me too! Me too!
>
>
>
> I’ve been using 9092 from home for several days, and it started fine this
> morning, but now it’s objecting.
>
>
>
> I’m on a stable home network with a quality commercial firewall and no
> proxies.  Win 7
>
>
>
> Steve
>
>
>
> *From:* Mike Thompson [mailto:miketh...@gmail.com]
> *Sent:* Monday, December 14, 2015 3:24 PM
> *To:* Greg Morgan 
> *Cc:* Alan Bragg ; talk-us@openstreetmap.org
> Openstreetmap 
> *Subject:* Re: [Talk-us] SunCertPathBuilderException
>
>
>
> I too am now getting the problem (but am on a corporate network at the
> moment, will try from home later):
>
> Version 8969
>
> Last change at 2015-10-29 22:15:23 +0100 (Thu, 29 Oct 2015)
>
> Java Version 1.8.0_65
>
> Windows 7
>
>
>
> On Mon, Dec 14, 2015 at 3:58 PM, Greg Morgan  > wrote:
>
>
>
> Checking the certificate[1] via a web browser says that the certificate
> for https://josm.openstreetmap.de/wiki/StartupPage is valid
>
> I get the same results from a web browser as you, it is valid.
>
>
>
>
>
>
>
> If the issue is a proxy problem as Mike pointed out, then I recall that
> you have to add -Dhttp.proxyHost=yourProxyURL to your JOSM arguments before
> you can change the proxy settings in your preferences.
>
> That is correct, but if web traffic is being filtered I don't think there
> is anything that can be done within JOSM to fix the problem.  The problem
> for me in the past has been that the filter returned a response like "are
> you sure you want to go to xyz.com", which normally in a browser would be
> displayed and you would have an opportunity to say "yes", but JOSM didn't
> know what to do with that response, hence the error.  That isn't the
> problem for me today as I can go to josm.openstreetmap.de (and directly
> to its IP address) without a warning from a browser.
>
>
>
> Mike
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>


-- 
@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-ja] 京都世界遺産マッピングパーティ：第１０回［特別編］醍醐寺

[yasunari]

京都世界遺産「マッパー」の山下です。
みなさんこんにちわ。

鬼が笑うかもしれませんが
京都世界遺産マッピングパーティ：第１０回［特別編］醍醐寺
は来年１月１６日に開催します。
https://openstreetmap.doorkeeper.jp/events/35922

朝１０時集合、
上醍醐までは１時間の登山が必要、
２万歩以上は歩くことになるでしょう。

皆さんのチャレンジをお待ちしています
--
山下康成＠京都府向日市

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

Re: [Talk-co] [talk-latam] Apoyo para un titán mapero

[hyan...@gmail.com]

Hoy se da reconocimiento a los maperos de OSM representados en Fredy
Rivera, Titan ganador en la categoría de tecnología!!

http://www.elespectador.com/noticias/nacional/estos-son-los-titanes-de-colombia-articulo-605522

Enhorabuena Fredy! Estos son los valores a resaltar, somos humildemente
nosotros los q creamos y liberamos los datos, somos también los llamados a
aplicarlos en beneficio de nuestros pueblos, cerrando los círculos
virtuosos vendrá el contagio, seguirán las instituciones q vean la bondad
de lo q hacemos y adopten su uso.

Por una Colombia y Latinoamérica q adopte información desde la sociedad
civil!

Abrazos y gracias por sus votos!

Humberto Yances
El dic. 3, 2015 3:32 PM, "hyan...@gmail.com"  escribió:

> "nosotros simplemente vamos en los hombros de los gigantes"  Fredy en la
> entrevista publicada hoy en Canal Caracol http://bcove.me/ccq7wvfh
>
> Gracias a todos los gigantes que contribuyen creando tecnología para hacer
> la aplicación de los mapas una realidad!
>
> Sigan votando!
>
> https://titanes.noticiascaracol.com/nominado/fredy-rivera
>
> El 1 de diciembre de 2015, 10:02, carlos felipe castillo <
> kaxti...@gmail.com> escribió:
>
>> En la recta final, no olvides el voto diario por el #Titán @fredy_rivera
>> en https://titanes.noticiascaracol.com/nominado/fredy-rivera
>> El 18/11/2015 11:38, "hyan...@gmail.com"  escribió:
>>
>>> Hola a todos,
>>>
>>> en días pasados unos de nuestros maperos en la región fue seleccionado
>>> como finalista de "Titanes Caracol", un programa de TV nacional en Colombia
>>> que trabaja bajo los lineamientos del Pacto Global de las Naciones Unidas y
>>> sus principios. Comprometiéndose a divulgar programas que sean ejemplo de
>>> equidad, compromiso y solidaridad y que favorezcan el desarrollo de
>>> iniciativas en favor de personas, grupos y su entorno social y ambiental.
>>>
>>> Se trata de Fredy Rivera: pionero, fundador e impulsor de la comunidad
>>> OSM en Colombia, quién ahora se enfoca en llevar OSM a las comunidades
>>> rurales.  Fredy en conjunto con "puentero" (mapero experto en levantar
>>> puntos sobre puentes destruidos) fueron los primeros en llevar OSM a los
>>> GPS en Haití, idea que luego tuvo una rápida acogida.
>>>
>>> Fredy es un campeón mapero con más de 1.000.000 de cambios en OSM!
>>>
>>> http://hdyc.neis-one.org/?humano
>>>
>>> Experto y prolífico mapero en campo también, donde usa un casco con
>>> cámara para fotomapping, en conjunto con toda una suite de herramientas
>>> para recopilar datos geográficos, tal como lo demostró durante su estancia
>>> en la tragedia de Salgar, Colombia.
>>>
>>> Humildemente abogo a ustedes por el apoyo a uno más de nosotros, ojalá
>>> gane y circule entonces por TV, lo que es OSM y como sirve a nuestros
>>> países.  Aquí les dejo unas instrucciones sobre cómo votar:
>>>
>>> youtu.be/wN0Jxsun7S4
>>>
>>> Si quieren escucharlo directamente, esta es una entrevista radial
>>> reciente:
>>>
>>>
>>> https://m.soundcloud.com/humberto-yances/entrevista-la-nube-naranja-titan-fredy-rivera
>>>
>>> Mil gracias!
>>>
>>> Humberto Yances
>>>
>>
>> ___
>> talk-latam mailing list
>> talk-la...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-latam
>>
>>
>
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

Re: [talk-latam] Apoyo para un titán mapero

[hyan...@gmail.com]

Hoy se da reconocimiento a los maperos de OSM representados en Fredy
Rivera, Titan ganador en la categoría de tecnología!!

http://www.elespectador.com/noticias/nacional/estos-son-los-titanes-de-colombia-articulo-605522

Enhorabuena Fredy! Estos son los valores a resaltar, somos humildemente
nosotros los q creamos y liberamos los datos, somos también los llamados a
aplicarlos en beneficio de nuestros pueblos, cerrando los círculos
virtuosos vendrá el contagio, seguirán las instituciones q vean la bondad
de lo q hacemos y adopten su uso.

Por una Colombia y Latinoamérica q adopte información desde la sociedad
civil!

Abrazos y gracias por sus votos!

Humberto Yances
El dic. 3, 2015 3:32 PM, "hyan...@gmail.com"  escribió:

> "nosotros simplemente vamos en los hombros de los gigantes"  Fredy en la
> entrevista publicada hoy en Canal Caracol http://bcove.me/ccq7wvfh
>
> Gracias a todos los gigantes que contribuyen creando tecnología para hacer
> la aplicación de los mapas una realidad!
>
> Sigan votando!
>
> https://titanes.noticiascaracol.com/nominado/fredy-rivera
>
> El 1 de diciembre de 2015, 10:02, carlos felipe castillo <
> kaxti...@gmail.com> escribió:
>
>> En la recta final, no olvides el voto diario por el #Titán @fredy_rivera
>> en https://titanes.noticiascaracol.com/nominado/fredy-rivera
>> El 18/11/2015 11:38, "hyan...@gmail.com"  escribió:
>>
>>> Hola a todos,
>>>
>>> en días pasados unos de nuestros maperos en la región fue seleccionado
>>> como finalista de "Titanes Caracol", un programa de TV nacional en Colombia
>>> que trabaja bajo los lineamientos del Pacto Global de las Naciones Unidas y
>>> sus principios. Comprometiéndose a divulgar programas que sean ejemplo de
>>> equidad, compromiso y solidaridad y que favorezcan el desarrollo de
>>> iniciativas en favor de personas, grupos y su entorno social y ambiental.
>>>
>>> Se trata de Fredy Rivera: pionero, fundador e impulsor de la comunidad
>>> OSM en Colombia, quién ahora se enfoca en llevar OSM a las comunidades
>>> rurales.  Fredy en conjunto con "puentero" (mapero experto en levantar
>>> puntos sobre puentes destruidos) fueron los primeros en llevar OSM a los
>>> GPS en Haití, idea que luego tuvo una rápida acogida.
>>>
>>> Fredy es un campeón mapero con más de 1.000.000 de cambios en OSM!
>>>
>>> http://hdyc.neis-one.org/?humano
>>>
>>> Experto y prolífico mapero en campo también, donde usa un casco con
>>> cámara para fotomapping, en conjunto con toda una suite de herramientas
>>> para recopilar datos geográficos, tal como lo demostró durante su estancia
>>> en la tragedia de Salgar, Colombia.
>>>
>>> Humildemente abogo a ustedes por el apoyo a uno más de nosotros, ojalá
>>> gane y circule entonces por TV, lo que es OSM y como sirve a nuestros
>>> países.  Aquí les dejo unas instrucciones sobre cómo votar:
>>>
>>> youtu.be/wN0Jxsun7S4
>>>
>>> Si quieren escucharlo directamente, esta es una entrevista radial
>>> reciente:
>>>
>>>
>>> https://m.soundcloud.com/humberto-yances/entrevista-la-nube-naranja-titan-fredy-rivera
>>>
>>> Mil gracias!
>>>
>>> Humberto Yances
>>>
>>
>> ___
>> talk-latam mailing list
>> talk-latam@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-latam
>>
>>
>
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

Re: [Talk-at] Import der Gewässer im Raum Sankt Michael in Obersteiermark

[Jens Steinhauser]

2015-12-14 23:45 GMT+01:00 Michael Reichert :
> Hallo Borut,
>
> Am Thu, 10 Dec 2015 08:22:37 +0100 schrieb Borut Maricic:
>> Beabsichtige in den nächsten Tagen und Wochen die Gewässer im Raum Sankt
>> Michael in Obersteiermark zu importieren.
>>
>> Genau geht es um zwei Bereiche:
>>
>> * SE von Sankt Michael um die A9 bis zum Gleinalmtunnel * NW von Sankt
>> Michael um Seidingerkogel
>>
>> Dieser Raum ist hier gut zu erkennen:
>>
>> http://www.wanderreitkarte.de/index.php?lon=15.0367=47.3222=12
>>
>> Ich werde es grob so machen, wie ich in dieser Nachricht beschrieben
>> habe:
>>
>> https://lists.openstreetmap.org/pipermail/talk-at/2015-April/007425.html
>
> Bitte denk daran, die Import-Guidelines einzuhalten, ansonsten wird es
> vermutlich wieder revertiert werden.
> https://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> Folgende Punkte hast du noch nicht erfüllt:
> - Dokumentation im Wiki auf einer eigenen Seite
> - Benachrichtigung auf der Import-Mailingliste
> - Posting in eurem Forum (das ist nicht tot) http://
> forum.openstreetmap.org/viewforum.php?id=89

"unser Forum". Der Oesterreich-Bereich des Forums wurde kuerzlich
eroeffnet, nachdem ein User, der nicht im Stande war sich auf der
Mailinglist anzumelden, lange genug herumgeweint hat. (Seine genauen
Beweggruende kann man leider nicht nachvollziehen, der im OSMBlog
verlinkte Thread http://forum.openstreetmap.org/viewtopic.php?id=52410
ist nicht mehr zugaenglich.) Und wenn man sich den Inhalt des
AT-Bereichs anschaut, sieht man dass es im Grunde aus einem einzigen
User besteht, der dort entweder Dinge postet die eigentlich ins Wiki
gehoeren wuerden oder sich in einem passive-aggressive Ton ueber OSM
beschwert ("gewollte Unschaerfe", "OSM in der Krise", ...). Und dann
wundert er sich dass sich niemand beteiligen will Mein aktuelles
Highlight ist der Thread
http://forum.openstreetmap.org/viewtopic.php?id=52667, der zeigt wie
ungeeignet dieses Medium ist (User loescht aus Angst vor Kritik alle
seine Beitraege wieder heraus, ein Nachvollziehen der Diskussion ist
nicht mehr moeglich.). Entschuldige dass ich diesen Thread hier
hijacke, aber diese versuchte Spaltung der AT-Community hat mir sehr
bitter aufgestossen.

lg,
Jens

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

Re: [Talk-us] SunCertPathBuilderException

[Steve Friedl]

Me too! Me too!

 

I’ve been using 9092 from home for several days, and it started fine this 
morning, but now it’s objecting. 

 

I’m on a stable home network with a quality commercial firewall and no proxies. 
 Win 7

 

Steve

 

From: Mike Thompson [mailto:miketh...@gmail.com] 
Sent: Monday, December 14, 2015 3:24 PM
To: Greg Morgan 
Cc: Alan Bragg ; talk-us@openstreetmap.org 
Openstreetmap 
Subject: Re: [Talk-us] SunCertPathBuilderException

 

I too am now getting the problem (but am on a corporate network at the moment, 
will try from home later):

Version 8969 

Last change at 2015-10-29 22:15:23 +0100 (Thu, 29 Oct 2015) 

Java Version 1.8.0_65 

Windows 7

 

On Mon, Dec 14, 2015 at 3:58 PM, Greg Morgan  > wrote:

 

Checking the certificate[1] via a web browser says that the certificate for 
https://josm.openstreetmap.de/wiki/StartupPage is valid 

I get the same results from a web browser as you, it is valid.

 

 

 

If the issue is a proxy problem as Mike pointed out, then I recall that you 
have to add -Dhttp.proxyHost=yourProxyURL to your JOSM arguments before you can 
change the proxy settings in your preferences.

That is correct, but if web traffic is being filtered I don't think there is 
anything that can be done within JOSM to fix the problem.  The problem for me 
in the past has been that the filter returned a response like "are you sure you 
want to go to xyz.com  ", which normally in a browser would be 
displayed and you would have an opportunity to say "yes", but JOSM didn't know 
what to do with that response, hence the error.  That isn't the problem for me 
today as I can go to josm.openstreetmap.de   (and 
directly to its IP address) without a warning from a browser.

 

Mike

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

Re: [Talk-cz] OSM Hospoda Praha

[Jiří Sedláček]

Nakonec nemůžu, neboť ten večer se koná (jak jsem zjistil) i vánoční
setkání brněnské Wikikomunity - ale dobrá restaurace - třeba u Dobré
Myšlenky (http://www.dobramyslenka.cz/) - mezi Výtoní a Palackého nám. Je
tam poměrně klid, mají tam dobré jídlo, většinou je i poměrně v pohodě
obsluha.

J.

2015-12-14 7:50 GMT+01:00 Marián Kyral :

> Dva týdny uplynuly a dle všeho je ideální termín tato středa, 16.12. v
> 18:00.
> Prosím všechny o revizi své účasti, ať víme, kolik nás skotečně nakonec
> bude a tip na vhodnou restauraci.
>
> Marián
>
> -- Původní zpráva --
> Od: Marián Kyral 
> Komu: talk-cz@openstreetmap.org
> Datum: 25. 11. 2015 22:11:08
> Předmět: [Talk-cz] OSM Hospoda Praha
>
> Ahoj,
> vánoce se pomalu, ale jistě blíží, co takhle zkusit ještě jedno OSM pivko?
>
> http://doodle.com/poll/xygiab522kee4r29
>
> Návrhy na vhodnou, ideálně nezakouřenou, restauraci vítány.
>
> Marián
> ___
> 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
>
>


-- 
S pozdravem,
Jirka Sedláček
---
jirisedla...@gmail.com
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk] Nominatim weakness

[Dave F.]

On 14/12/2015 08:25, Sarah Hoffmann wrote:


Some helpful person has put a wikipedia link to the Starbucks
wikipedia page on every single Starbucks in Japan. That's what
throwing off Nominatim. Having a wikipedia page boosts the importance
of an object.


Have you considered that the program is over weighting the importance of 
a wiki page?


Do end users want to find a coffee shop local to them or one thousands 
of kilometres away just because it has an extra tag attached?



  And in this case the boost is quite large because
the Starbucks wiipedia page is pretty prominent.


Prominent to who? Could you expand your explanation please?

Cheers
David F.


---
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: [OSM-talk-be] Voorstel import GRB gebouwen

[Ben Abelshausen]

Dag Sander,

2015-12-13 18:07 GMT+00:00 Sander Deryckere :
>
> In theorie is dit allemaal niet zo moeilijk, maar de GRB database is vele
> malen groter dan de CRAB database, dus zullen we dit niet meer kunnen
> hosten op Github, en zullen we een aparte server moeten nemen. Ik vrees ook
> dat ik niet genoeg computerkracht heb om een dergelijke database in te
> lezen en te splitsen in verschillende OSM bestanden. Dus zullen we dit
> verder moeten automatiseren op een zwaardere server.
>
> Wat denken jullie hier over?
>

Ik heb een tijd geleden een server gehuurd die ik samen met joost gebruik
voor OSM-gerelateerde zaken. Daar kan jij ook toegang toe krijgen als je
wil. Dat zou meer dan genoeg moeten zijn om dit te hosten.

Over de import zelf:

Ik heb altijd gedacht dat we dit op termijn zouden moeten doen in de meeste
steden omdat het gewoon heel moeilijk is om via luchtfoto's alle gebouwen
te mappen op een fatsoenlijke manier (probeer maar eens het patershol in
gent goed te krijgen). Ik denk ook dat de kwaliteit van de GRB-data
waarschijnlijk beter is dan de onze waar gebouwen echt op elkaar gepakt
staan.

Waar ik niet zo zeker van ben is of dit ook klopt in meer landelijke
gemeentes. Heb je daar ook info over? Hoe heb je kwaliteit vergeleken? Veel
gebouwen zijn ook al in orde buiten de steden omdat het gewoon gemakkelijk
in te tekenen is.

Met vriendelijke groeten,
Best regards,

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

Re: [Talk-it] La Notte dei Mappatori viventi

[Andrea Albani]

Personalmente  uso sempre l'ultima stable release disponibile. Ma il punto
è stato colto da Martin.
Se spieghiamo in dettaglio come usare Josm vuol dire che il target della
pagina wiki è un utente poco avvezzo a Josm che magari non ha attivato il
remote control... e quando andrà in editing del task non vedrà succedere
nulla. Se forniamo il dettaglio su come verificare che sia attivo chiudiamo
il cerchio.
Il 14/Dic/2015 12:09, "Martin Koppenhoefer"  ha
scritto:

>
> 2015-12-14 11:27 GMT+01:00 Alessandro :
>
>> E' stato inserito nel core di Josm dalla versione 3715, ora siamo alla
>> versione 9060 (9117 per chi come me usa josm-latest)
>>
>> http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl
>>
>> Se avete una versione così vecchia conviene aggiornarla.
>>
>
>
> si, conviene sempre aggiornare, ma il problema dell'attivazione rimane con
> l'integrazione nel core, perché è un (credo veramente piccolo) potenziale
> rischio nel aprire una porta, quindi l'attivazione deve essere fatto
> dall'utente stesso, non viene fatto in automatico...
>
> Ciao,
> Martin
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-fr] Problème dans la BAN

[Christian Quest]

Corrigé dans le code:
https://github.com/etalab/ban-data/commit/5c278950f234775c0ab26f7be57ca3821cd0e145

ça sera corrigé dans les data à la prochaine livraison... c'est à dire dans
la soirée

Le 13 décembre 2015 à 22:20, Vincent de Château-Thierry 
a écrit :

> Bonsoir,
>
> Le 13/12/2015 22:14, Aurélien  a écrit :
>
>>
>> Je me suis retrouvé bloqué suite à cette erreur :
>>
>> {"id":"45122__d51385","type":"street","name":"ZONE D'ACTIVITES "LES
>> GABILLONS","postcode":"45570","citycode":"45122","lon":2.506828,"lat":
>> 47.760558,"city":"Dampierre-en-Burly","context":"45, Loiret, Centre
>>
>> Val-de-Loire","importance":0.0141,"housenumbers":{"1":{"lat":47.760558,"lon":2.506828,"id":"ADRNIVX_000288431943"},"2":{"lat":47.760558,"lon":2.506828,"id":"ADRNIVX_000288431944"},"3":{"lat":47.760558,"lon":2.506828,"id":"ADRNIVX_000288431946"},"4":{"lat":47.760558,"lon":2.506828,"id":"ADRNIVX_000288431947"},"5":{"lat":47.760558,"lon":2.506828,"id":"ADRNIVX_000288431948"},"6":{"lat":47.760558,"lon":2.506828,"id":"ADRNIVX_000288431949"},"7":{"lat":47.760558,"lon":2.506828,"id":"ADRNIVX_000288431950"},"8":{"lat":47.760558,"lon":2.506828,"id":"ADRNIVX_000288431951"},"9":{"lat":47.760558,"lon":2.506828,"id":"ADRNIVX_000288431952"}}}
>>
>> Le souci vient du faire qu'un guillemet intervient dans "ZONE
>> D'ACTIVITES *"*LES GABILLONS"
>>
>> Du coup le json n'est pas valide.
>>
>> Je ne sais pas si l'erreur est dû aux données d'entrée brutes ou à un
>> traitement "post" pour générer le json, mais en tout cas il y a un loup
>> quelque part.
>>
>
> Pour s'y retrouver, il faudrait signaler l'erreur ici :
> https://github.com/etalab/ban-data
>
> vincent
>
> ___
> 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

Re: [Talk-br] Ativação do HOT sobre o colapso da barragem em Mariana

[andre viana]

Bom dia!Moro em Mariana,caso possa ajudar em alguma coisa!

Em 11 de dezembro de 2015 00:33, Tarcisio Oliveira 
escreveu:

> Amanha de manhã eu dou uma ajuda final.
>
> Em 10-12-2015 19:53, Gerald Weber escreveu:
>
> Que tal a gente concluir o mapeamento?
>
> http://tasks.hotosm.org/project/1317
>
> abraço
>
> Gerald
>
> 2015-11-10 19:00 GMT-02:00 Vitor George :
>
>> Oi pessoal,
>>
>> Vamos começar uma tarefa de mapeamento remoto da região afetada pelo
>> colapso da barragem em Mariana. O trabalho é uma ativação do Humanitarian
>> OpenStreetMap Team:
>>
>> http://wiki.openstreetmap.org/wiki/2015_Mariana_Dam_Collapse
>>
>> A página está em inglês porque não temos um template em português ainda,
>> quem puder colaborar traduza alguma parte desta página:
>>
>> http://wiki.openstreetmap.org/wiki/Template:Pt:Activation
>>
>> Em breve vamos ter acesso a imagens pós-desastre. Quem quiser acompanhar
>> mais de perto, acesso o grupo do Telegram.
>>
>> Abraços,
>> Vitor
>>
>> ___
>> Talk-br mailing list
>> Talk-br@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>
>
>
> ___
> Talk-br mailing 
> listTalk-br@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-br
>
>
>
> ___
> 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] Nominatim weakness

[Sarah Hoffmann]

On Mon, Dec 14, 2015 at 09:37:42AM +0100, Simon Poole wrote:
> Sigh, this could easily be the silliest thread ever on talk.
> 
> See http://wiki.openstreetmap.org/wiki/Nominatim#Parameters
> 
> In general for POI search in an area I would suggest using
> OverPass/OverPass Turbo (note however that this has the same issue as a
> bounded Nominatim POI search in that it will only return POIs in the
> area specified, which is less useful than it sounds and not what the
> original poster was asking for).
> 
> See
> https://help.openstreetmap.org/questions/14407/nominatim-radius-search
> for some more information and alternative ways of searching on the topic.

To clarify: we are not really talking about POI searches here.

If you type in 'Starbucks' in the search box, then you just get
objects named that way. No difference with searching for, say Berlin.

Now, if you type 'cafes' in the search box, then you are probably
looking for all amenity=cafe and that is a POI search. It's true
that this particular query doesn't work on osm.org. You have to
additionally specify a place, e.g. 'cafes in Poughkeepsie' actually
returns the one Starbucks in town.

Sarah

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

Re: [Talk-es] Información de límites de velocidad máxima por tramos de carretera en OpenStreetMap

[Miguel Sevilla-Callejo]

Hola Ismael,

Respecto a lo que preguntas, podrías hacer una consulta usando una de las
APIs que tiene OSM, overpass, por ejemplo, para extraer los elementos que
contangan la información de velocidad que quieras a partir de parámetros
espaciales (no altitudinales, OSM, no tiene información de alturas sensu
estricto).

Échale un ojo a
 la documentación de overpass API:
http://wiki.openstreetmap.org/wiki/Overpass_API
 y al etiquetado de velocidad:
http://wiki.openstreetmap.org/wiki/Speed_limits

Otro asunto es que la información sobre la velocidad máxima ese incluida en
las carreteras que quieras consultar...

Lo único es animarte a que si no lo están, lo incluyas!  --> puedes empezar
con alguno de los tutoriales: http://learnosm.org/es/ ó
http://wiki.openstreetmap.org/wiki/Beginners'_guide

Un saludo

Miguel

*[image: Geo]Miguel Sevilla Callejo*
*Doctor en Geografía | Doctor in Geography*
*Consultor freelance e investigador | Freelance Consultant & Researcher*
Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza | Fellow at
the Pyrenean Institute of Ecology - Spanish National Research Council
Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
Professional Association of Geographers
Web: http://bit.ly/sevillacallejo

2015-12-08 23:41 GMT+01:00 Ismael Rihawi Aragón :

> Buenas noches a todos,
>
> os escribo porque he conocido recientemente la plataforma *OpenStreetMap*,
> ando realizando un proyecto experimental de tráfico que quiere partir de
> datos de limitaciones de velocidad por tramos según un origen de
> coordenadas (x,y) y/o parámetros tales como altitud y latitud, y quería
> saber si el uso de vuestra API podría proveerme de esta información.
>
> Muchas gracias por vuestra atención y tiempo, quedo pendiente de toda
> contestación por vuestra parte, saludos
>
> *Ismael R.*
>
>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk] Nominatim weakness

[Jorge Gustavo Rocha]

Hi,

I think that we can add an option to bound the results to the current 
viewport. That option would be passed to nominatim or any other search 
engine.


Personally, I would prefer the search bounded by default, but users 
could change it to "everywhere" to see additional results.


Regards,

J. Gustavo

Às 11:17 de 14-12-2015, Martin Koppenhoefer escreveu:


2015-12-14 10:04 GMT+01:00 Sarah Hoffmann >:

If you type in 'Starbucks' in the search box, then you just get
objects named that way. No difference with searching for, say Berlin.

Now, if you type 'cafes' in the search box, then you are probably
looking for all amenity=cafe and that is a POI search. It's true
that this particular query doesn't work on osm.org .
You have to
additionally specify a place, e.g. 'cafes in Poughkeepsie' actually
returns the one Starbucks in town.



if I search for
"Starbucks in Holland" I get not hit, neither for
"Starbucks in the Netherlands"
"Starbucks in Netherlands"
"Starbucks in Amsterdam"

but "starbucks, Netherlands" yields a lot of results (there's even a
restaurant among them). Btw., also "starbucks, Holland" leads to a lot
of results (not sure if they are the sama, they are in different sorting
order at least). You can even omit the comma, but you shouldn't add an
"in" because this will lead to no results.

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

Re: [Talk-it-trentino] Modifica pagina Trentino

[Paolo Ianes]

Penso che Luca abbia pienamente ragione.
A parte forse i due primi box della pagina di benvenuto a mio parere
andrebbero:
1) eliminati i box (rendono difficile lo zoom e occupano spazio
inutilmente), 2) eliminati i colori (oltre ad essere oldfashion rendono
difficile la lettura),
3) sostituito il carattere con grazie adottando il carattere standard della
wiki senza grazie (per uniformità e perché facilita la lettura soprattutto
sui supporti a piccolo schermo).

Paolo

Il giorno 14 dicembre 2015 11:27, girarsi_liste 
ha scritto:

> On 14/12/2015 09:00, Luca Delucchi wrote:
>
> > e continuo a pensare la stessa cosa di 2 anni fa, per fortuna ci vedo
> > molto bene ma altrimenti non sarei in grado di leggere quelle pagine.
> > Bisogna fare qualcosa per aumentare la leggibilità delle pagine:
> > - in primis rimuovere tutti quei colori
> > - cercare di risistemare e aggiornare le pagine
> >
> > che ne pensate?
> >
> > [0] http://wiki.openstreetmap.org/wiki/Trentino
> >
>
> Penso che basta farlo, ci posso mettere mano un pò alla volta, adsl
> permettendo.
>
>
> --
> Simone Girardelli
> _|_|_|_|_|_|_|_|_|_
> |_|_|_|_|_|_|_|_|_|_|
>
>
>
> ___
> Talk-it-trentino mailing list
> Talk-it-trentino@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it-trentino
>
___
Talk-it-trentino mailing list
Talk-it-trentino@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-trentino

[Talk-br] Dúvidas radares e sinaleiras

[Helio Cesar Tomio]

Colegas, falando em ajuda, alguém poderia explicar como mapear corretamente
radares?
Vi muitos usando apenas as tags:
highway=speed_camera
maxspeed=80

Outros acrescentaram as tags:
enforcement=maxspeed
type=enforcement

Qual seria a forma correta?
E não entendi a função deste enforcement.

Em alguns sinaleiros tb achei além de highway=traffic_signals, as tags:
enforcement=traffic_signals
type=enforcement

Não sei se é possível definir os radares para atuarem apenas numa direção
de deslocamento e se posso juntar sinaleiros e radares em um único nó
(sinaleiros com radares).

Comecei a usar o Osmand e percebi que ele lê os radares do OSM.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk-be] missing maps in Gent

[Pieter-Jan Pauwels]

Hallo Joost, 

Ik vind de praktische info op de osm content page zeker OK!
Alleen inderdaad met iets meer duiding over waarom missing maps, wat kan je 
ermee verwezenlijken (en bijleren voor de beginners). 
Dus iets meer geschreven voor zij die OSM weinig of niet kennen maar wel 
algemeen een open hart uitdragen. 
Als je daar al een alinea van hebt in combinatie met de praktische info heb ik 
al genoeg!

Groeten,
Pieter-Jan


Pieter-Jan Pauwels
Community Coordinator, Open Knowledge Belgium
m: +32 476 66 27 77  | e: pieter-jan.pauw...@okfn.org 
 | w: okfn.be  

> On 14 Dec 2015, at 09:18, joost schouppe  wrote:
> 
> Hoi Pieter-Jan,
> 
> Wat denk je zelf? :)
> 
> Er is al een Engelstalige pagina i.v.m. het event: 
> http://osm.be/nl/content/missing-maps-mapathon-ghent 
> 
> Maar ik vermoed dat die te veel gewoon praktisch is en gericht op de reeds 
> overtuigden.
> 
> Klopt het dat dat je eerder op zoek bent naar iets dat uitlegt wat voor 
> geweldige open data we allemaal gaan maken, en waarom we dat op deze manier 
> doen? En als ik naar de andere posts kijk, zou ik denken: niet meer dan een 
> alinea of vier. Juist?
> 
> Als je dat bevestigt, zal ik hier wat schrijven/copy pasten van bestaand 
> materiaal:
> https://hackpad.com/Mapathon-Ghent-XcfAOgaaYNV 
> 
> En 't is een hackpad - dus, community, welkom om mee te schrijven.
> 
> Groeten,
> Joost
> 
> Op 14 december 2015 09:09 schreef Pieter-Jan Pauwels 
> >:
> Hallo Joost, 
> 
> Goesting om een oproep te schrijven in het EN op 
> http://2016.openbelgium.be/blog ? 
> Sinds vorige week is de website en blog volledig aangepast en voor alle 
> ‘open’ events hebben we daar zeker een plaats voor. 
> 
> Wij kunnen gerust helpen met zoeken van afbeeldingen, proofreading en 
> implementeren. Dus een documentje met de tekst is al voldoende voor ons. 
> 
> Wat denk je? 
> 
> Groeten,
> Pieter-Jan
>   
> Pieter-Jan Pauwels
> Community Coordinator, Open Knowledge Belgium
> m: +32 476 66 27 77  | e: 
> pieter-jan.pauw...@okfn.org  | w: okfn.be 
>  
> 
>> On 11 Dec 2015, at 17:31, joost schouppe > > wrote:
>> 
>> Mappers in het Gentse,
>> 
>> Bij deze is het helemaal bevestigd, de volgende Missing Maps Mapathon is op 
>> 23 januari in het Gentse. De blogpost staat al online:
>> 
>> http://osm.be/nl/content/missing-maps-mapathon-gent 
>> 
>> 
>> Wat nog niet helemaal duidelijk is, zijn de uren. De zaal is geboekt van 
>> 10:00 tot 17:00. Ik twijfel nog tussen beginnen om 13:00, of beginnen om 
>> 10:00 met enkel een mapping-intro en een officieel begin om 13:00. Graag uw 
>> meningen. 
>> 
>> Met de promotiemachine van stad Gent achter ons gaan we allicht meer mensen 
>> hebben dan vorige keer. Vrijwilligers gezocht dus: hoe meer ervaren mappers 
>> in the house, hoe sneller de nieuwkes op weg zijn. Maar ook wie meer wil 
>> doen dan dat, graag!
>> 
>> Heb je nog ideëen over hoe we dit zo goed mogelijk kunnen doen, ken je 
>> iemand die wil sponseren, of heb je promotie-ideëen, laat ze maar komen.
>> 
>> Groeten,
>> Joost
>> 
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-be 
>> 
> 
> 
> 
> 
> -- 
> Joost @
> Openstreetmap  | Twitter 
>  | LinkedIn 
>  | Meetup 
>  | Reddit 
>  | Wordpress 
> 
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-br] O que houve com Fernando Trebien?

[Peter Krauss]

Oi gente ... Ouvindo aqui, e lembrando da discussão recente sobre "os donos
dos nomes das ruas" . ;-)

A Conferência mundial do Clima (COP21) da semana passada parece ter dado um
indicativo: há diversidade de opiniões, diversidade de metas, etc. mas *não
podemos deixar de fechar uma negociação*...
E os pontos-chave são justamente os consensos, e em seguida as
padronizações em torno desses consensos.

Nome de rua não tem dono, mas *tá na hora da OSM ter um dono, um Conselho*,
algum tipo de decisão central (*democrática*!) a ser acatada. A solução de
conflitos sempre passa por isso: um poder maior que as partes conflitantes
para fixar decisões simples e idealmente consensuais.

- - - -
PS: a internet está repleta de ferramentas para tomada de decisão
democrática, discussão em grupos focais, etc, nós e que estamos socialmente
na idade da pedra... acho que não tem desculpa, estamos enrolando.






Em 13 de dezembro de 2015 23:51, Blademir Andrade de Lima <
blademi...@hotmail.com> escreveu:

> É uma pena mesmo.
>
> Espero que ninguém mais desista, estive afastado uns bons meses.
>
> Att,
> BladeTC
>
> --
> From: openstreet...@arlindopereira.com
> Date: Sun, 13 Dec 2015 11:49:13 -0200
> To: talk-br@openstreetmap.org
> Subject: Re: [Talk-br] O que houve com Fernando Trebien?
>
> Desistiu do projeto depois de discussões improdutivas na lista com outro
> mapeador aqui do Rio.
>
> > mailman-boun...@openstreetmap.org
> >
> > Jul 8
> > to talk-br-owner
> > fernando.treb...@gmail.com foi removido da lista Talk-br.
>
> []s
> Arlindo
>
> 2015-12-13 11:42 GMT-02:00 Erick de Oliveira Leal <
> erickdeoliveiral...@gmail.com>:
>
> Opa pessoal, alguém sabe o que aconteceu com o Fernando Trebien?
> Diz nessa página "retired"
> http://wiki.openstreetmap.org/wiki/User:Ftrebien
>
> As mensagens indicam um link
> https://www.openstreetmap.org/user/user_401472 como se o usuário dele não
> existisse mais.
>
> ___
> 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 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-it] relazioni amministrative in Italia -

[Martin Koppenhoefer]

Scusate l'enorme ritardo, volevo informare che ho ottenuto da tempo
risposta sia da SldrHartman che da Verdy_p, ecco:

SldrHartman: "ciao ok, procedete come meglio preferite."

Verdy_p: "

The hint on the wiki was added much later, and in most countries the tag is
disarable, notably because those relations are in contruction and require
frequent updates.
The documentaiton is there since long and in facxt does not impact anything
in the way items are found or loaded.
Even if people want to load those relations in an editor, the suareas MUST
also be loaded in order to edit them also properly (because their boundary
ways are shared between touching relations of the same type or with borders
of subareas delimited inside of them.
There's absolutely no problem loading relations: editors will load just was
is needed and don't need to load all members of subarea relations, but will
load automatically the ways or nodes that are shared. Not loading these
suelements will create very frequent edit errors, such that one relation is
broken unexpectedly by ediing another using the same ways.
The concept of child/parent relations is standard in OSM since long.

Romoving the subareas just means more frequent errors, even in regions
where all administrative regions are already defined, becuase they need to
be refined further, or because the administrative subdivisions are also
frequently changing.

If your editor loads too many items, it is a problem of the editor, but it
does not break any data.
But this causes absolutely no problem in the most frequently used tools :
iD, JOSM, Nominatim, Mapnik and MapQuest renderers...

In fact only a few users were intrigeted about them but nothing is wrong.
Those elements just add ONE and ONLY ONE member item per administrative
subdvision in its parent subdivision relation: this is very small in fact
compared to the definition of ways and nodes in those relations of ways, or
even compared to their tags. But very useful for editors, as well as
reusers (geometric searches are extremely costly and have low performance,
they also do not find all the needed items (and notably not when any
relation has been partly broken because users did not load all the needed
relations when they edited them and broke others).
Repairing broken relations is also much easier with these elements. And it
is much easier to track all the needed changes (notably when there's a
large administrative reform, for which those elements are really needed to
work with incomplete data, sometimes during many months)."


-


Ciao,

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

Re: [OSM-talk] Nominatim weakness

[Maarten Deen]

On 2015-12-14 09:25, Sarah Hoffmann wrote:

On Sun, Dec 13, 2015 at 05:52:21PM -0500, John Goodman wrote:

Am I missing something, or is there no way to sort Nominatim
searches on the main OpenStreetMap map page?

For example, if my map is showing an area of the United States where
I happen to know a mapped Starbucks exists, and I search for
"Starbucks" in the search panel, the entire panel is filled with
Starbucks in Japan. Do the same on a "competitor's" map, and you get
what you expect: the Starbucks that are closest to the current map
view are listed first.


Some helpful person has put a wikipedia link to the Starbucks
wikipedia page on every single Starbucks in Japan. That's what
throwing off Nominatim. Having a wikipedia page boosts the importance
of an object. And in this case the boost is quite large because
the Starbucks wiipedia page is pretty prominent.

Nominatim does take into account the current view (and, yes, the
OSM page sends exactly the right parameters for that) but unless
explicitly requested, the searches are not bounded. That means
the importance of the object is weighted aganst how far away it
is from the current map view. In the case of the wikipedia-tagged
Starbucks importance wins.

To make a long story short: it's a tagging error. The wikipedia tag
should contain only links to wikipedia pages describing the object
not to pages about the operator.


IMHO it is a programming error on the account of importance. No amount 
of importance could be so great that local results get flooded and 
pushed down so much in importance.
In the Netherlands there is one Starbucks I believe (Schiphol Airport) 
and even standing at that location does not return it in the search.


That can not be put to tagging error, the website links to a japan 
website so it should only be of importance to searches in Japan.


Regards,
Maarten

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

Re: [OSM-talk-fr] Sens unique et sens de circulation

[Tony Emery]

Cela veut donc dire que, sémantiquement, on n'a pas la possibilité de
distinguer un tronçon de voie en sens unique d'une chaussée séparée d'une
voie en double sens.

Parce que réaliser des calculs informatiques de voisinage et de comparaison
de tags me parait quand même très aléatoire...



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Sens-unique-et-sens-de-circulation-tp5862168p5862421.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [OSM-talk-be] Voorstel import GRB gebouwen

[Sander Deryckere]

Op 14 december 2015 11:43 schreef Ben Abelshausen :

> Dag Sander,
>
> 2015-12-13 18:07 GMT+00:00 Sander Deryckere :
>>
>> In theorie is dit allemaal niet zo moeilijk, maar de GRB database is vele
>> malen groter dan de CRAB database, dus zullen we dit niet meer kunnen
>> hosten op Github, en zullen we een aparte server moeten nemen. Ik vrees ook
>> dat ik niet genoeg computerkracht heb om een dergelijke database in te
>> lezen en te splitsen in verschillende OSM bestanden. Dus zullen we dit
>> verder moeten automatiseren op een zwaardere server.
>>
>> Wat denken jullie hier over?
>>
>
> Ik heb een tijd geleden een server gehuurd die ik samen met joost gebruik
> voor OSM-gerelateerde zaken. Daar kan jij ook toegang toe krijgen als je
> wil. Dat zou meer dan genoeg moeten zijn om dit te hosten.
>
> Het volledige GRB is 15.4GB gecomprimeerd. Natuurlijk hebben we niet alles
nodig (slechts 1 tabel), maar we hebben die wel nodig in ongecomprimeerde
vorm.


> Over de import zelf:
>
> Ik heb altijd gedacht dat we dit op termijn zouden moeten doen in de
> meeste steden omdat het gewoon heel moeilijk is om via luchtfoto's alle
> gebouwen te mappen op een fatsoenlijke manier (probeer maar eens het
> patershol in gent goed te krijgen). Ik denk ook dat de kwaliteit van de
> GRB-data waarschijnlijk beter is dan de onze waar gebouwen echt op elkaar
> gepakt staan.
>
> Waar ik niet zo zeker van ben is of dit ook klopt in meer landelijke
> gemeentes. Heb je daar ook info over? Hoe heb je kwaliteit vergeleken? Veel
> gebouwen zijn ook al in orde buiten de steden omdat het gewoon gemakkelijk
> in te tekenen is.
>
> Ook van landelijke gemeentes zijn quasi alle voorgevels opgemeten (de
meetpunten kan je trouwens zien in een aparte database, alle terristische
meetpunten zijn precies tot op 10cm). Wat de achterkanten betreft kan je
soms enkele fouten zien, maar deze zijn meestal het gevolg van moeilijk
interpreteerbare foto's (zoals kleine aanhangsels gecombineerd met bomen en
struiken). Soms kunnen wij het beter doen, omdat we b.v. ondertussen al
betere foto's hebben. Maar in OSM zullen we volgens mij net zo vaak fouten
maken.

De gevels lijken mij ook belangrijker, omdat ze dan voornamelijk in de
steden de mogelijk geven om in de toekomst met een betere precisie de
voetpaden en straatoppervlaktes te tekenen.

Het vergelijken van de precisie van de achtergevels heb ik simpelweg gedaan
door huizen waarvan ik de achterkant ken te controleren (kennissen, buren,
...), en gemerkt dat daar soms wel wat verkeerde interpretaties in zitten,
maar die niet echt duidelijk zijn op de foto's en ook niet van de straat
kunnen gezien worden.


> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-it] La Notte dei Mappatori viventi

[Alessandro]

Il 14/12/2015 10:50, Andrea Albani ha scritto:
Una piccola nota: nella pagina wiki non si parla della necessità di 
attivare il controllo remoto di JOSM. Non mi sembra sia attivo per 
default, ma potrei ricordare male




E' stato inserito nel core di Josm dalla versione 3715, ora siamo alla 
versione 9060 (9117 per chi come me usa josm-latest)


http://wiki.openstreetmap.org/wiki/JOSM/Plugins/RemoteControl

Se avete una versione così vecchia conviene aggiornarla.

Alessandro Ale_Zena_IT

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

[talk-au] Fwd: Importing Vicmap Lite data

[Russell Edwards]

Hi Simon,

Yes I'm aware of the dangers of just breaking things with a mass of
automated data.

I was going to start with one boundary, and potentially just trace it to
avoid importing problems. But I assume all those IP issues also apply to
tracing? The problem with boundaries is they are pure data. You can't see
them on the ground or from the air. So surely they are impossible to do
without accessing government data.

Russell

On Mon, Dec 14, 2015 at 8:34 PM, Simon Poole  wrote:

>
>
> Am 14.12.2015 um 03:17 schrieb Russell Edwards:
>
> Hi,
>
> I just wanted to double check before I do this as people seem to talk
> casually about using Vicmap Lite data but the OSM Wiki has a long process
> to go through with the community before doing any imports.
>
>
> It should be pointed out that the rules are there for a reason: a decade
> of experience that imports are in general screwed up and the people
> responsible for them then vanish leaving a mess behind for others to clean
> up.
>
>
> I have downloaded "Statewide Public Land Classification boundaries,
> polygon - 1:250,000 to 1 :2 million. Vicmap Lite". It is CC
> BY-4.0-International.
>
>
> Currently the status of  CC BY-4.0 licensed data is unclear, this is due
> to some quirks in how the 4.0 version of CC BY works. We are waiting for CC
> to get back to the OSMF to clarify. which might happen in this decade or
> not. In other words: such data will need explicit permission for an import.
>
> I want to add boundaries of some local state forests I frequent, using
> this data. My questions are
>
> * Can I just go ahead and do it?
> * I haven't done boundaries before, do I need a shared node where roads
> and waterways cross the boundary?
> * What if there is an existing overlapping area natural=wood that follows
> the aerial tree extent (which doesn't exactly match the boundary)? Leave
> them both there? Do I need natural=wood on the state forest boundary area
> to, to make it display green? What about the conflict there?
> * Anything else to watch for?
>
> Landuse imports are notoriously difficult to do correctly, matter of fact
> I'm fairly sure that we have never had one which wasn't a failure in one
> way or another. If you have never done boundaries before then you should be
> doing boundaries before. That will give you some idea of what you are
> getting in to and will give you answers to your questions.
>
> Simon
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [OSM-talk-be] Voorstel import GRB gebouwen

[joost schouppe]

De miserie is niet zozeer dat dat GRB zo groot is, want je kan lagen ook
apart downloaden (toch degene die ik nodig had tot nu toe). Voor gebouwen
aan de grond:
https://download.agiv.be/Producten/Detail?id=968=GRB_Gbg_gebouw_aan_de_grond

Maar aangezien je moet inloggen op een webpagina om te downloaden, vermoed
ik dat het ook niet mogelijk is om een service op te zetten die automatisch
actualiseert.

Dat betekent dan wel dat je ook buiten een serveromgeving verwerkingen kan
doen. En dat ik eventueel zou kunnen helpen met verwerkingen in SPSS of
FME, als dat handig zou zijn.

Op 14 december 2015 13:13 schreef Sander Deryckere :

>
>
> Op 14 december 2015 11:43 schreef Ben Abelshausen <
> ben.abelshau...@gmail.com>:
>
>> Dag Sander,
>>
>> 2015-12-13 18:07 GMT+00:00 Sander Deryckere :
>>>
>>> In theorie is dit allemaal niet zo moeilijk, maar de GRB database is
>>> vele malen groter dan de CRAB database, dus zullen we dit niet meer kunnen
>>> hosten op Github, en zullen we een aparte server moeten nemen. Ik vrees ook
>>> dat ik niet genoeg computerkracht heb om een dergelijke database in te
>>> lezen en te splitsen in verschillende OSM bestanden. Dus zullen we dit
>>> verder moeten automatiseren op een zwaardere server.
>>>
>>> Wat denken jullie hier over?
>>>
>>
>> Ik heb een tijd geleden een server gehuurd die ik samen met joost gebruik
>> voor OSM-gerelateerde zaken. Daar kan jij ook toegang toe krijgen als je
>> wil. Dat zou meer dan genoeg moeten zijn om dit te hosten.
>>
>> Het volledige GRB is 15.4GB gecomprimeerd. Natuurlijk hebben we niet
> alles nodig (slechts 1 tabel), maar we hebben die wel nodig in
> ongecomprimeerde vorm.
>
>
>> Over de import zelf:
>>
>> Ik heb altijd gedacht dat we dit op termijn zouden moeten doen in de
>> meeste steden omdat het gewoon heel moeilijk is om via luchtfoto's alle
>> gebouwen te mappen op een fatsoenlijke manier (probeer maar eens het
>> patershol in gent goed te krijgen). Ik denk ook dat de kwaliteit van de
>> GRB-data waarschijnlijk beter is dan de onze waar gebouwen echt op elkaar
>> gepakt staan.
>>
>> Waar ik niet zo zeker van ben is of dit ook klopt in meer landelijke
>> gemeentes. Heb je daar ook info over? Hoe heb je kwaliteit vergeleken? Veel
>> gebouwen zijn ook al in orde buiten de steden omdat het gewoon gemakkelijk
>> in te tekenen is.
>>
>> Ook van landelijke gemeentes zijn quasi alle voorgevels opgemeten (de
> meetpunten kan je trouwens zien in een aparte database, alle terristische
> meetpunten zijn precies tot op 10cm). Wat de achterkanten betreft kan je
> soms enkele fouten zien, maar deze zijn meestal het gevolg van moeilijk
> interpreteerbare foto's (zoals kleine aanhangsels gecombineerd met bomen en
> struiken). Soms kunnen wij het beter doen, omdat we b.v. ondertussen al
> betere foto's hebben. Maar in OSM zullen we volgens mij net zo vaak fouten
> maken.
>
> De gevels lijken mij ook belangrijker, omdat ze dan voornamelijk in de
> steden de mogelijk geven om in de toekomst met een betere precisie de
> voetpaden en straatoppervlaktes te tekenen.
>
> Het vergelijken van de precisie van de achtergevels heb ik simpelweg
> gedaan door huizen waarvan ik de achterkant ken te controleren (kennissen,
> buren, ...), en gemerkt dat daar soms wel wat verkeerde interpretaties in
> zitten, maar die niet echt duidelijk zijn op de foto's en ook niet van de
> straat kunnen gezien worden.
>
>
>> Met vriendelijke groeten,
>> Best regards,
>>
>> Ben Abelshausen
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>


-- 
Joost @
Openstreetmap  |
Twitter  | LinkedIn
 | Meetup
 | Reddit
 | Wordpress

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

Re: [OSM-talk] Nominatim weakness

[Lester Caine]

On 14/12/15 09:00, Maarten Deen wrote:
> IMHO it is a programming error on the account of importance. No amount
> of importance could be so great that local results get flooded and
> pushed down so much in importance.
> In the Netherlands there is one Starbucks I believe (Schiphol Airport)
> and even standing at that location does not return it in the search.

Now I can see both sides of this debate.

If I am looking for POI's near by it is a different search to asking to
find say 'Starbucks, Birmingham' and having the focus change to the
selected result. As a new user I'm just as likely to put in my home
location and select it as I am to look for something adjacent when the
map is not already centred on my location. ASSUMING that the computer IS
defaulting to one's physical location is a mistake.

*I* use the search to find places that are not 'within range' and can
then make an educated guess at wanting 'Birmingham, UK' over one of the
American alternatives, and having selected Birmingham, UK, a search for
Starbucks, Birmingham, UK fine tunes the results.

That is not to say that options for 'near by' would not be useful, but
just that 'importance' is difficult to gauge if you don't know what the
user expects to see?

(An the pigging change of motorway colour really does not help a new
user in the UK! One can not readily distinguish the motorways around
Birmingham)

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

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

Re: [Talk-es] Ubicación de los números de las porterías

[Jorge Sanz Sanfructuoso]

La numeración es un tema que no es la primera vez que sale y nunca ha
llegado la cosa a un consenso. Yo mismo los he puesto de maneras diferentes
normalmente influenciado por lo que a puesto la gente al rededor de donde
edito.

Todos los métodos tienen sus pros y sus contras. El de el nodo suelto en
medio de la parcela ese si que si siempre lo considero totalmente
incorrecto. En el país vasco creo que era, están muchos así de una
importación que se hizo (hay más zonas así).
Poner el polígono con la numeración lo bueno que tiene es que cualquier POI
que esté dentro si no tiene numeración coge la numeración del polígono por
lo que en muchos casos te ahorras meter la misma información 2 veces. El
tema de poner los datos en el punto de un banco que comenta Miguel si
coincide con el del polígono no haría falta pero en el resto de casos creo
que en todos si habría que ponerle la numeración, porque sino no se sabe la
dirección que tiene. Lo que creo que no hace es encontrar la entrada del
edificio cosa que creo que sí se podría hacer, pero creo que Nominatim no
está preparado para ello.

Yo como empecé a editar y la mejor opción que veo aunque como comento ahora
mismo no la uso siempre y estoy abierta al consenso que se haga es:
- Cuando es un edificio con un único portal poner la numeración en el
polígono del edificio.
- Si tiene varios portales con diferente numeración ponerlo en el nodo de
cada portal.
- Los nodos de numeración de las casas que siempre sean puntos parte del
polígono del edificio, al menos de que sea exterior por tener un valla y se
ponga en el nodo de la valla.
- El nodo de entrada, del portal, ponerlo con entrance=main

La otra posibilidad que he visto en zonas y veo correcta pero como digo lo
suyo es llegar a un consenso de cual usar, es ponerlo siempre en un nodo y
lo suyo es ponerlo en un punto del edificio, en el portal si es la
numeración del portal.

Y como suelo comentar en esta página
http://mapas.alternativaslibres.es/descargas.php hay listados de errores y
sobre el tema de la numeración quedan muchisimos errores por corregir en
España. Son errores que veo esenciales corregir para tener un buen mapa ya
que es mucha información de numeración metida incorrectamente que al final
tiene utilidad nula. Y no es información que nos sobre precisamente.

Un saludo.

El lun., 14 dic. 2015 a las 9:44, Miguel Sevilla-Callejo (<
msevill...@gmail.com>) escribió:

> Hola Carlos,
>
> Yo llevo tiempo teniendo esta duda también. En ZAragoza se importaron los
> números de los portales y andan ligeramente movidos y al reubicarlos
> siempre me planteo cual es la posición correcta.
>
> En mi caso tiro de Catastro, que al fin y al cabo, parece una fuente de
> fiar y a tener en cuenta. Ellos ponen el número en la puerta, junto a la
> salida a la calle.
>
> El ejemplo que mandas con los números en el centro de la parcela no me
> parece el correcto. Parece más que corresponde a una importación de
> polígonos del catastro o similar y puede llevar a confusión si se trata de
> parcelas que dan a dos calles.
>
> Otro asunto del que tengo dudas es si he de poner un nodo adicional si
> sobre un número de calle existe un negocio, pongamos un banco (y es de una
> sola planta). ¿He de hacer esto o incluir las etiquetas del mismo sobre el
> nodo del número de calle?
>
> Ya direis
>
> Un saludo
>
>
> *[image: Geo]Miguel Sevilla Callejo*
> *Doctor en Geografía | Doctor in Geography*
> *Consultor freelance e investigador | Freelance Consultant & Researcher*
> Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza | Fellow at
> the Pyrenean Institute of Ecology - Spanish National Research Council
> Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
> Professional Association of Geographers
> Web: http://bit.ly/sevillacallejo
>
> 2015-12-13 1:55 GMT+01:00 Carlos Cabezas :
>
>> Buenas a todos,
>>
>> Echando un vistazo a los edificios en distintas ciudades, me he dado
>> cuenta que la ubicación de las porterías varía y tras hacer una búsqueda
>> rápida en la wiki no he encontrado ninguna respuesta, sé que es una
>> pregunta muy tonta pero desconozco si hay alguna forma "oficial" de
>> asignarle los números a los edificios/porterías.
>>
>> Adjunto 3 imágenes, en el caso de Madrid el número se añade a veces en un
>> nodo aparte y otras veces en un nodo del área (método que me parece más
>> correcto si un mismo edificio tiene varias porterías además de localizar la
>> entrada en el sitio exacto), en el caso de Barcelona se le asigna el número
>> al edificio/área y si un mismo edificio tiene varios números pues se separa
>> el edificio el 2 áreas; en el caso de Múnich me he fijado que usan todas
>> las formas mencionadas anteriormente.
>>
>> ¿Hay algún método correcto?
>>
>> Saludos.
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
> 

Re: [OSM-talk] Nominatim weakness

[Martin Koppenhoefer]

2015-12-14 10:04 GMT+01:00 Sarah Hoffmann :

> If you type in 'Starbucks' in the search box, then you just get
> objects named that way. No difference with searching for, say Berlin.
>
> Now, if you type 'cafes' in the search box, then you are probably
> looking for all amenity=cafe and that is a POI search. It's true
> that this particular query doesn't work on osm.org. You have to
> additionally specify a place, e.g. 'cafes in Poughkeepsie' actually
> returns the one Starbucks in town.
>


if I search for
"Starbucks in Holland" I get not hit, neither for
"Starbucks in the Netherlands"
"Starbucks in Netherlands"
"Starbucks in Amsterdam"

but "starbucks, Netherlands" yields a lot of results (there's even a
restaurant among them). Btw., also "starbucks, Holland" leads to a lot of
results (not sure if they are the sama, they are in different sorting order
at least). You can even omit the comma, but you shouldn't add an "in"
because this will lead to no results.

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

[OSM-talk-fr] Enclave espagnole à Nîmes ?

[Tony Emery]

Bonjour à tous, je vous informe qu'un des quartier de Nîmes a décidé de faire
sécession avec la ville de Nîmes.

De fait, ce quartier, a priori à forte concentration d'immigrés espagnol,
s’érige en commune nommée "Estadio" :
http://www.openstreetmap.org/#map=17/43.84463/4.39106
  

Trêve de bêtise, il semble que Ness3010 ait eu un problème. Il a taggué le
stade de l'école primaire comme s'il s'agissait d'une commune.
Il a aussi renommé les noms des rues alentours en espagnol. Je pense que
c'est une erreur est qu'il va falloir corriger...



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Enclave-espagnole-a-Nimes-tp5862451.html
Sent from the France mailing list archive at Nabble.com.

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

[Talk-it] Parrocchiale

[Ilario Valdelli]

Potreste indicarmi come segnalare una parrocchiale?

Cioé la casa dove dovrebbe vivere il parroco, in genera annessa alla chiesa?


-- 
Ilario Valdelli
Wikimedia CH
Verein zur Förderung Freien Wissens
Association pour l’avancement des connaissances libre
Associazione per il sostegno alla conoscenza libera
Switzerland - 8008 Zürich
Wikipedia: Ilario 
Skype: valdelli
Facebook: Ilario Valdelli 
Twitter: Ilario Valdelli 
Linkedin: Ilario Valdelli 
Tel: +41764821371
http://www.wikimedia.ch
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-br] Digest Talk-br, volume 87, assunto 32

[Helio Cesar Tomio]

Arlindo e naoliv,

Entendi:
- que o enforcement vincula o radar ou sinaleiro com a via.
- que o enforcement pode criar uma relação indicando o sentido do radar
from/to como em
https://www.openstreetmap.org/relation/4146285
- que o radar fica antes do cruzamento da sinaleira, na mesma posição da
haste que sustenta a câmera
- que a sinaleira sempre é um nó na via, mas o radar pode ser na via ou ao
lado usando o enforcement
- que a sinaleira deve ficar antes do cruzamento
Qto esta última acho difícil por causa da faixa de pedestre
(highway=crossing), que fica praticamente na mesma posição.
Me parece que ao cadastrar faixa de pedestre + sinaleira + radar vai ficar
tumultuado no local.
Se alguém souber um exemplo, agradeço.
Vou fazer umas "artes" por aqui e posto o resultado.

Obrigado imensamente pela paciência e agradeço antecipadamente qq correção.
Cordialmente, Helio.
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Digest Talk-br, volume 87, assunto 32

[Arlindo Pereira]

Geralmente aqui no Rio eu coloco primeiro o nó da sinaleira, depois o da
faixa de pedestre, os dois antes do nó do cruzamento em si.

Exemplo: http://www.openstreetmap.org/node/3649910872

Mas aqui no RJ os semáforos são sempre antes do cruzamento (e ficam na
linha aonde os carros devem parar). Em SP é sempre depois (e eu acho
confuso pacas). Neste caso, acho que eu colocaria o nó do semáforo no ponto
aonde os carros devem parar.

[]s

2015-12-14 13:27 GMT-02:00 Helio Cesar Tomio :

> Arlindo e naoliv,
>
> Entendi:
> - que o enforcement vincula o radar ou sinaleiro com a via.
> - que o enforcement pode criar uma relação indicando o sentido do radar
> from/to como em
> https://www.openstreetmap.org/relation/4146285
> - que o radar fica antes do cruzamento da sinaleira, na mesma posição da
> haste que sustenta a câmera
> - que a sinaleira sempre é um nó na via, mas o radar pode ser na via ou ao
> lado usando o enforcement
> - que a sinaleira deve ficar antes do cruzamento
> Qto esta última acho difícil por causa da faixa de pedestre
> (highway=crossing), que fica praticamente na mesma posição.
> Me parece que ao cadastrar faixa de pedestre + sinaleira + radar vai ficar
> tumultuado no local.
> Se alguém souber um exemplo, agradeço.
> Vou fazer umas "artes" por aqui e posto o resultado.
>
> Obrigado imensamente pela paciência e agradeço antecipadamente qq
> correção.
> Cordialmente, Helio.
>
> ___
> 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-pt] Consenso sobre mapeação de povoações

[Marcos Oliveira]

Obrigado Rui!

De facto, a diferenciação de *place = suburb* e *place = neighbourhood* é a
mais difícil de ser feita. Normalmente *place = suburb *utiliza-se só nas
maiores metrópoles, que para Portugal deveria ser Lisboa e Porto e poucos
mais.

Sim, segundo esta classificação os *place = suburb *que
vigoram tornar-se-iam *place = neighbourhood*. Um compromisso poderia ser a
reclassificação de um *place = neighbourhood *para *place = suburb* só
quando este é (ou foi) capital de uma freguesia que está "anexada" à cidade
ou vila vizinha, como por exemplo em Viana do Castelo, onde existe uma
malha urbana que se estende por várias freguesias onde é impossível
delimitar um "limite" da cidade. [1]

Será que é possível fazer o mesmo para Coimbra, ou será que a cidade em si
está confinada dentro da Cintura Externa de Coimbra?

Quanto às cidades e vilas, penso que seja é melhor esperar e receber mais
comentários com o apoio/contra da sua união sob a tag *place = town* de
forma a chegarmos a um consenso.

[1] - http://www.openstreetmap.org/#map=14/41.7042/-8.8266


No dia 14 de dezembro de 2015 às 15:34, Nuno Gomes Lopes <
n.gomeslo...@gmail.com> escreveu:

> Boa tarde a tod@s. Fui eu que sugeri ao Marcos a alteração em relação às
> vilas. Em Portugal a diferenciação entre 'vilas' e 'cidades' é muitas das
> vezes pro forma, e as elevações de vilas a cidades passa mais pela
> afirmação política de determinada aglomeração. Lembro que o concelho de
> Paredes tem várias vilas e cidades e que Sintra, Cascais e Ponte de Lima
> são vilas (por vontade própria). O mesmo para a definição de 'city' - Porto
> e Lisboa serão certamente 'city', mas Portalegre e Bragança nem por isso.
>
>
> --
>  
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
>

-- 
Um Abraço,
Marcos Oliveira
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [OSRM-talk] Shortest path post-processing

[Patrick Niklaus]

Hey Franics!


the naming is a little bit unfortunate in that code path. I started
refactoring this a little bit but got caught up in other tasks. What
UnpackPath() actually does it to unpack (remove shortcut edges) _and_
decompress (translate it to a geometry). That means the node ids you
get back don't fit into the edge-based-graph that is used in facade.

What I would suggest in this case is to take a look at the
alternative_path.hpp file. The alternative search needs to to
something similar (unpack paths to do post-processing).[1] You can
basically copy that code and unpack the path yourself. The resulting
path will work for `facade` (as you can see a few lines lower)

[1] 
https://github.com/Project-OSRM/osrm-backend/blob/5a9bee052753ab6c978e60ac2ca331f2ed378aa8/routing_algorithms/alternative_path.hpp#L433
[2] 
https://github.com/Project-OSRM/osrm-backend/blob/5a9bee052753ab6c978e60ac2ca331f2ed378aa8/routing_algorithms/alternative_path.hpp#L469

Hope this helps.

Cheers,
Patrick

On Sun, Dec 13, 2015 at 10:05 PM, Francis Giraldeau
 wrote:
> Hello!
>
> I would like to do some post-processing on the resulting shortest path using
> edges from the graph. In ViaRoutePlugin, I tried to iterate on the
> raw_route.unpacked_path_segments, but the BeginEdges(node) and
> EndEdges(node) returns an empty range as if the a segment is not connected
> to the next.
>
> for (std::vector data: raw_route.unpacked_path_segments) {
>
> std::cout << "DEBUG FOR EACH NODE:" << std::endl;
>
> for (int i = 0; i < data.size(); i++) {
>
> PathData path = data[i];
>
> std::cout << "[" << facade->BeginEdges(path.node) << ", " <<
>
>  facade->EndEdges(path.node) << "]" << std::endl;
>
> for (const auto edge : facade->GetAdjacentEdgeRange(path.node)) {
>
> std::cout << edge << std::endl;
>
> }
>
> }
>
> }
>
>
> What would be the right way to iterate on segments and access the EdgeData?
>
>
> Thanks!
>
>
> Francis Giraldeau
>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>

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

Re: [Talk-cz] OSM Hospoda Praha

[Marián Kyral]

Škoda. Tak třeba příště.

Díky za tip na restauraci. Já mezitím trochu brouzdal po mapě a hledal v 
centru. A že tam těch restaurací je :-D
A narazil jsem na restauraci s mým oblíbeným pivem - těch asi tady v Praze 
moc nebude: http://peronsmichov.cz/

Vyhovuje, nebo chcete něco méně hořkého? (i když dnes už to prý není to co 
to bývalo)

Marián


-- Původní zpráva --
Od: Jiří Sedláček 
Komu: OpenStreetMap Czech Republic 
Datum: 15. 12. 2015 1:55:20
Předmět: Re: [Talk-cz] OSM Hospoda Praha

"

Nakonec nemůžu, neboť ten večer se koná (jak jsem zjistil) i vánoční setkání
brněnské Wikikomunity - ale dobrá restaurace - třeba u Dobré Myšlenky (
http://www.dobramyslenka.cz/(http://www.dobramyslenka.cz/)) - mezi Výtoní a 
Palackého nám. Je tam poměrně klid, mají tam dobré jídlo, většinou je i 
poměrně v pohodě obsluha.



J.




2015-12-14 7:50 GMT+01:00 Marián Kyral :
"
Dva týdny uplynuly a dle všeho je ideální termín tato středa, 16.12. v 18:
00. 
Prosím všechny o revizi své účasti, ať víme, kolik nás skotečně nakonec bude
a tip na vhodnou restauraci.

Marián


-- Původní zpráva --
Od: Marián Kyral 
Komu: talk-cz@openstreetmap.org(mailto:talk-cz@openstreetmap.org)
Datum: 25. 11. 2015 22:11:08
Předmět: [Talk-cz] OSM Hospoda Praha

"


Ahoj,
vánoce se pomalu, ale jistě blíží, co takhle zkusit ještě jedno OSM pivko?

http://doodle.com/poll/xygiab522kee4r29
(http://doodle.com/poll/xygiab522kee4r29)

Návrhy na vhodnou, ideálně nezakouřenou, restauraci vítány.

Marián



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

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

"





-- 

S pozdravem,
Jirka Sedláček
---
jirisedla...@gmail.com(mailto:jirisedla...@gmail.com)


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

Re: [Talk-at] Import der Gewässer im Raum Sankt Michael in Obersteiermark

[Borut Maricic]

Hallo!

@Martin Raifer:

Besten Dank für Deine Information über dem
"combine-highways"-Script. Dies hat mit neue Perspektiven
geöffnet! (Blöder weise bringe ich zurzeit kein Script zum
Laufen. Auch das Original-Script, das halt mit meinen Daten
nichts bewirken würde (aber doch durchlaufen soll), will
nicht laufen. Ich erhalte immer: "An error occured in the
script". Muss sich um etwas triviales handeln, aber im
Moment stecke ich an dieser Stelle).

@Frederik Ramm:

Ja, die sachlichen Fragen sind besser, danke. Südlich von
Sankt Michael sind es gerade im die 1000 nodes (genau 1280,
aber einige kleine Bäche sind schon früher manuell gemappt
worden). Ways, nach Kombinieren, werden es nicht viele sein
- ich denke bestimmt unter 100, die meisten davon namenlos.
Nördlich von Sankt Michael habe ich noch nicht
ausgeschnitten und kann nicht sagen, erwarte aber weniger
Daten.

@Jens Steinhauser, Erwin OSM et al:

Bitte, für die Österreich-Forum Diskussion, erstellt euch
einen eigenen Thread. Danke.

@Michael Reichert:

Danke für die Hinweise. Der Ton aber, wenn auch gut gemeint,
ist nicht gerade ermutigend. Nach fast jedem solchen Import
bin ich oft ("monatelang") mit GPS im Gebiet unterwegs, um
die Details (bridges, fords, culverts, ...) in Ordnung zu
bringen (was man in solchen Schluchten und Wäldern nicht
anders machen kann). Ein Revert solch einer Bemühung würde
ganz bestimmt das Ende meiner OSM-Tätigkeit bedeuten.

Liebe Grüße,

Borut


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

Re: [Talk-at] Import der Gewässer im Raum Sankt Michael in Obersteiermark

[Erwin OSM]

Morgen,

Also ich finde das Form gut.

Und es wurde auch nicht gegen meinen Willen eingerichtet. Wenn, dann sprich Bitte nur für Dich und nicht für die gesamte Community, OK?

Und es ist auch nicht tot, es erwacht mehr und mehr zum Leben.

Grüße
-- 
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.

Friedrich Volkmann schrieb:

  
On 14.12.2015 23:45, Michael Reichert wrote:
> Folgende Punkte hast du noch nicht erfüllt:
> - Dokumentation im Wiki auf einer eigenen Seite
> - Benachrichtigung auf der Import-Mailingliste
> - Posting in eurem Forum (das ist nicht tot) http://
> forum.openstreetmap.org/viewforum.php?id=89
> - Import mit einem separaten Account durchführen
> - Dokumentation im Import-Katalog https://wiki.openstreetmap.org/wiki/
> Import/Catalogue
>
> Bitte nimm die Hinweise ernst. Die Richtlinie wurde nicht aus Spaß
> erfunden.

Die Richtlinie zu den krummen Gurken auch nicht. Man kann auch etwas
überreglementieren. Es handelt sich hier nicht um einen Monsterimport a la
TIGER oder plan.at, sondern um ein paar Gewässer rund um ein Dorf.
Angesichts dieses Umfangs finde ich Boruts Kommunikation völlig ausreichend,
und selbsternannte Ordnungshüter sind in solchen Angelegenheiten so nützlich
wie Pest und Cholera.

Betreffend das Webforum: Das ist nicht nur tot, sondern das war nie
lebendig. Es gibt seit jeher einen Konsens, dass wir für AT nicht zugleich
eine Mailingliste und ein Webforum brauchen. Wer auch immer das Webforum
eingerichtet hat, hat es gegen den Willen unserer Community gemacht.

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

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


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

Re: [OSM-talk-be] Voorstel import GRB gebouwen

[Jakka]

Wat gebeurt er met de 3D taggen die op de manueel ingetekende buildings 
verder uitgewerkt werden ?


http://wiki.openstreetmap.org/wiki/3D

http://demo.f4map.com/#lat=50.7799026=3.1892977=16=33.827=-0.573

http://demo.f4map.com/#lat=50.7960880=3.1202353=19=70.514=77.636

http://demo.f4map.com/#lat=50.7892170=3.1404653=19=70.514=77.636 




Sander Deryckere schreef op 13/12/2015 om 19:07:

Hallo,

Na het bekijken van een hoop GRB data zou ik graag voorstellen om de
gebouwen te importeren.

Ik heb het hier over het "Gebouwen aan de Grond" (Gbg) bestand, en de
tabel van de gebouwen met adressen (TblGbgAdr).

De kwaliteit van de GRB gebouwen is goed genoeg. De voorgevels zijn veel
precieser dan wat wij momenteel kunnen opmeten, en de achtergevels
hebben ongeveer dezelfde kwaliteit als onze kwaliteit.

In het GRB zitten dus ook adressen, maar een gebouw kan geen, één of
meerdere adressen hebben, en een adres uit het GRB kan toegekend zijn
aan één of meerdere gebouwen (daarnaast bevat het GRB ook niet alle
adressen).

Ik zou dus graag de GRB import koppelen aan de CRAB import, en de web
app uitbreiden.

De gebouwen van het GRB kunnen opgesplitst worden per postcode, en de
gebouwen die 1-op-1 overeenkomen met een adres kunnen onderverdeeld
worden per straat. De gebouwen die niet toebehoren aan een straat kunnen
in een apart bestand per postcode gezet worden.

Door een kolom toe te voegen aan de crab-import web app kunnen dus eerst
de gebouwen per straat worden geïmporteerd, en daarna de aparte
adrespunten voor welke we zelf nog moeten uitzoeken tot welk gebouw ze
behoren.

In theorie is dit allemaal niet zo moeilijk, maar de GRB database is
vele malen groter dan de CRAB database, dus zullen we dit niet meer
kunnen hosten op Github, en zullen we een aparte server moeten nemen. Ik
vrees ook dat ik niet genoeg computerkracht heb om een dergelijke
database in te lezen en te splitsen in verschillende OSM bestanden. Dus
zullen we dit verder moeten automatiseren op een zwaardere server.

Wat denken jullie hier over?

Mvg,
Sander


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





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

Re: [Talk-br] Dúvidas radares e sinaleiras

[Arlindo Pereira]

Helio,

o wiki menciona que o mínimo seria adicionar câmeras como um nó que não
faça parte da via, com as tags highway=speed_camera + maxspeed=XX [1].
Existe ainda a opção de criar uma relação "enforcement", que denota mais
explicitamente que a speed_camera se liga à highway em questão [2]. Mas
mesmo sem usar a relação, é interessante colocar também o maxspeed na via
em questão.

A princípio, não se deveria juntar os sinaleiros aos radares pois os
sinaleiros, ao contrário dos radares, devem sempre fazer parte da via [3].
Mais especificamente, o ideal seria colocar o nó dos sinaleiros antes do
cruzamento, conforme os exemplos "Tag all incoming ways" / "Tag all
incoming one-ways". No caso de radares de sinal, pode se colocar a relação
"enforcement" citada acima.

1: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dspeed_camera
2: http://wiki.openstreetmap.org/wiki/Relation:enforcement
3: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals

[]s
Arlindo

2015-12-14 10:41 GMT-02:00 Helio Cesar Tomio :

> Colegas, falando em ajuda, alguém poderia explicar como mapear
> corretamente radares?
> Vi muitos usando apenas as tags:
> highway=speed_camera
> maxspeed=80
>
> Outros acrescentaram as tags:
> enforcement=maxspeed
> type=enforcement
>
> Qual seria a forma correta?
> E não entendi a função deste enforcement.
>
> Em alguns sinaleiros tb achei além de highway=traffic_signals, as tags:
> enforcement=traffic_signals
> type=enforcement
>
> Não sei se é possível definir os radares para atuarem apenas numa direção
> de deslocamento e se posso juntar sinaleiros e radares em um único nó
> (sinaleiros com radares).
>
> Comecei a usar o Osmand e percebi que ele lê os radares do OSM.
>
> ___
> 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-ja] 富田林市インポート作業報告

[浅野和仁]

飯田さん、muramotoさん、村上さん

インポートメンバーの協議にて、sourceを削除することにしました。

今後、既にインポートした道路データに対して
1、ノードの不接合解消処理
2、オブジェクトのsource、source_refの削除
3、道路種別の見直し
を実施します。
また、これと並行して建物データのインポートを開始します。

-- 
**
浅野 和仁
helicobacter_y...@hera.eonet.ne.jp（メインメール）
**
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk-fr] Transilien.com - OpenStreetMap

[dHuy Pierre]

Il y avait le site raildar.fr qui couvrait aussi bien le réseau transilien que 
national mais qui depuis peu ne couvre plus rien en France (d'après eux à cause 
de la sncf). En espérant qu'un jour ça revienne...En attendant, il marche avec 
l'Eurostar et plusieurs pays européens. 


Le Lundi 14 décembre 2015 14h02, Florian LAINEZ  a écrit 
:
 

 Bonjour,
Merci pour vos retours.


Il y a deux fois "Horaires" dans le menu:
http://www.transilien.com/lignes/rer-trains/rer-A


Ce sont les anciens horaires avant le 13 décembre et ceux après le 13 décembre, 
afin de permettre aux usagers de prévoir leurs trajets à l'avance.
Maintenant que la date est passée, nous n'allons pas tarder à enlever cette 
information dupliquée. Bien vu !


J'imagine que les horaires sont les théoriques : y a-t-il un moyen d'avoir
les horaires en temps réel, voire une carte montrant où se trouvent les
trains sur la ligne?


Pour avoir accès à notre API temps réel, il faut me faire une demande à 
l'adresse ext.synergie.florian.lai...@sncf.fr
Plus d'informations et la doc sont disponibles à l'adresse 
https://ressources.data.sncf.com/explore/dataset/api-temps-reel-transilien/

Pour la carte de tous les trains SNCF en temps réel, ça se passe ici : 
http://www.sncf.com/fr/geolocalisation
Vous noterez le fond de carte OSM ;)

Bonne journée


Le 12 décembre 2015 à 18:04, pepilepi...@ovh.fr  a écrit :

  Le 12/12/2015 11:49, Shohreh a écrit :
  
 Il y a deux fois "Horaires" dans le menu:
http://www.transilien.com/lignes/rer-trains/rer-A

J'imagine que les horaires sont les théoriques : y a-t-il un moyen d'avoir
les horaires en temps réel, voire une carte montrant où se trouvent les
trains sur la ligne?

Vu le nombre de retards et annulations, c'est plus utile que les horaires
officiels. 
 
 Bonsoir,
  Jusque il y a pas longtemps il y avait OSM tchoutchou mais comme le déplore 
son créateur (?) il a été torpillé par la SNCF (ou du moins sa source de 
données). Il reste sur ce site un moyen de contacter l'auteur.
  Ceci dit je ne sais pas s'il allait jusqu'à suivre les RER.
  Bon dimanche,
  JP
  
 
 
 
 
--
View this message in context: 
http://gis.19327.n5.nabble.com/Transilien-com-OpenStreetMap-tp5861552p5862303.html
Sent from the France mailing list archive at Nabble.com.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
 
 
 
 -- 
    Joyeux Noël et Bonne Année 2016
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr





-- 
  FlorianLainez
@overflorian

___
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] 2 relations pour le Rhône

[Jérôme Seigneuret]

Salut,

Les polygons sont tous englobé dans un multipolygon.  Vas savoir
pourquoi... C'est pour cela que tout les tag sont remontés au niveau de la
relation.

Pour le reste, il y a tous les éléments à inclure dans une relation
type=waterway inclus dans la relation sous la forme d'un main_stream,
d'un side_stream ou d'autre type... dont waterbody ou riverbank (area)

J'ai l'impression que la relation englobante est le mutipolygone et ça n'a
pas de sens... les élément de type natural=water
doivent être inclus dans la relation type=waterway et la relation de type
mulipolygon sur tous les éléments natural=water est inutile. Il y a lieu
d'avoir du multipolygone seulement s'il y a des iles

Dans tous les cas l'emprise des zones d'eau n'est pas incluse dans la
première relation et c'est pas normal donc à voir
http://wiki.openstreetmap.org/wiki/Relation:waterway

Jérôme



Le 14 décembre 2015 à 14:21, Tony Emery  a écrit :

> Bonjour à tous,
>
> Je ne sais pas si vous l'avez remarqué, mais le fleuve Rhône possède 2
> relations 660056 et 1075117.
>
> Si j'ai bien compris, la relation  660056
>    concerne
> l'emprise surfacique du fleuve alors que la relation  1075117
>    concerne le
> filaire.
>
> Comprenez-vous la même chose que moi et si c'est la cas, pourquoi cette
> bizarrerie ?
> De plus, le objets de la relation des emprises n'ont (presque tous) plus
> aucun tag, ce qui fait qu'on ne peut plus les récupérer dans les requêtes
> simples (waterway=* ou natural=water).
>
> Avez-vous le même problème ? Est-ce une erreur ?
>
>
>
> -
> Tony EMERY
> Administrateur OpenStreetMap.fr
> Mandataire Grand Sud-Est
> Géomaticien & chef de projets
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/2-relations-pour-le-Rhone-tp5862437.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> 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] Nouvelle gare de Rosa Parks

[Florian LAINEZ]

il y a bien un et un seul quai qui dessert d'une part la voie 1 et d'autre
part la voie 2.
les autre voies ne marquent pas l'arrêt dans cette gare. Par contre il y a
peut être un travail de recalage des voies à effectuer suite aux travaux.

Le 14 décembre 2015 à 14:35, dHuy Pierre  a écrit :

> Petit commentaire sur la plateforme: Y a-t-il un ou deux quais? Dans ce
> cas il y aura deux plateformes, non?
>
>
>
> Le Lundi 14 décembre 2015 14h24, Florian LAINEZ  a
> écrit :
>
>
> Hello,
> Hier a ouvert la nouvelle gare Transilien de Rosa Parks, sur la ligne E,
> pas loin de gare du Nord.
>
> On est quelques uns à avoir bossé sur une micro-carto indoor, voici le
> résultat :
> http://github.pavie.info/openlevelup/?lat=48.896459=2.374063=20=0=0=1=0=0=0=0
>
> Tout n'est pas encore terminé, je pense à certains équipements qu'on a pas
> encore ajouté, ou encore la description des alentours (ex. arbres au sud,
> calage des arbres ...).
>
> On a calé le bâti depuis le plan d'architecte et importé certains éléments
> comme les piliers, et pour compléter ça je suis allé prendre des photos
> 360° hier dans la gare cf.
> http://www.mapillary.com/map/search/48.89667895659059/2.3741417040492365/17.334957027564734Q
>
> Votre aide est la bienvenue pour boucler tout ça !  Si vous voulez un
> petit guide concernant les tags ça se passe ici :
> http://wiki.openstreetmap.org/wiki/FR:Railway_stations
>
> Bonne journée
>
> --
> *Florian Lainez*
> @overflorian 
>
> ___
> 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
>
>


-- 

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

Re: [OSM-talk] Nominatim weakness

[Marc Zoutendijk]

> Op 14 dec. 2015, om 10:00 heeft Maarten Deen  het volgende 
> geschreven:
> 
> In the Netherlands there is one Starbucks I believe (Schiphol Airport) and 
> even standing at that location does not return it in the search.

I’m in no way connected to Starbucks, but your statement is far from true: I 
know at least a Starbucks in: Den Bosch, Utrecht, Den Haag, Nijmegen and I’m 
sure there are many more…


Marc.

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

Re: [OSM-talk] Nominatim weakness

[Colin Smale]

It would be nice to have some shades of grey in there, like a choice of
radius, e.g. within 1km, 10km, 100km, 1000km

On 2015-12-14 13:43, Jorge Gustavo Rocha wrote:

> Hi,
> 
> I think that we can add an option to bound the results to the current 
> viewport. That option would be passed to nominatim or any other search engine.
> 
> Personally, I would prefer the search bounded by default, but users could 
> change it to "everywhere" to see additional results.
> 
> Regards,
> 
> J. Gustavo
> 
> Às 11:17 de 14-12-2015, Martin Koppenhoefer escreveu: 
> 
>> 2015-12-14 10:04 GMT+01:00 Sarah Hoffmann > >:
>> 
>> If you type in 'Starbucks' in the search box, then you just get
>> objects named that way. No difference with searching for, say Berlin.
>> 
>> Now, if you type 'cafes' in the search box, then you are probably
>> looking for all amenity=cafe and that is a POI search. It's true
>> that this particular query doesn't work on osm.org .
>> You have to
>> additionally specify a place, e.g. 'cafes in Poughkeepsie' actually
>> returns the one Starbucks in town.
>> 
>> if I search for
>> "Starbucks in Holland" I get not hit, neither for
>> "Starbucks in the Netherlands"
>> "Starbucks in Netherlands"
>> "Starbucks in Amsterdam"
>> 
>> but "starbucks, Netherlands" yields a lot of results (there's even a
>> restaurant among them). Btw., also "starbucks, Holland" leads to a lot
>> of results (not sure if they are the sama, they are in different sorting
>> order at least). You can even omit the comma, but you shouldn't add an
>> "in" because this will lead to no results.
>> 
>> 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-es] Información de límites de velocidad máxima por tramos de carretera en OpenStreetMap

[Jesús Gómez Fernández]

Como bien dice Miguel, puedes utilizar Overpass.
No todos los tramos de carretera en España tienen velocidades. Ito! tiene
un visor de mapa que quizás te pueda interesar para revisar cuáles disponen
de ellas.
Ojo, aparte de la etiqueta *maxspeed*, existen* maxspeed:forward=** y
*maxspeed:backward=** que son más precisas para carreteras con ambos
sentidos ya que aquí se tiene en cuenta cada uno de ellos.

Ito! speed:
http://product.itoworld.com/map/124?lon=-3.57933=39.88437=7=true
Utilización de la etiqueta maxspeed:
http://wiki.openstreetmap.org/wiki/Key:maxspeed

Un saludo

Jesús Gómez

El 14 de diciembre de 2015, 13:04, Miguel Sevilla-Callejo <
msevill...@gmail.com> escribió:

> Hola Ismael,
>
> Respecto a lo que preguntas, podrías hacer una consulta usando una de las
> APIs que tiene OSM, overpass, por ejemplo, para extraer los elementos que
> contangan la información de velocidad que quieras a partir de parámetros
> espaciales (no altitudinales, OSM, no tiene información de alturas sensu
> estricto).
>
> Échale un ojo a
>  la documentación de overpass API:
> http://wiki.openstreetmap.org/wiki/Overpass_API
>  y al etiquetado de velocidad:
> http://wiki.openstreetmap.org/wiki/Speed_limits
>
> Otro asunto es que la información sobre la velocidad máxima ese incluida
> en las carreteras que quieras consultar...
>
> Lo único es animarte a que si no lo están, lo incluyas!  --> puedes
> empezar con alguno de los tutoriales: http://learnosm.org/es/ ó
> http://wiki.openstreetmap.org/wiki/Beginners'_guide
>
> Un saludo
>
> Miguel
>
> *[image: Geo]Miguel Sevilla Callejo*
> *Doctor en Geografía | Doctor in Geography*
> *Consultor freelance e investigador | Freelance Consultant & Researcher*
> Colaborador del Instituto Pirenaico de Ecología, CSIC, Zaragoza | Fellow at
> the Pyrenean Institute of Ecology - Spanish National Research Council
> Colegiado nº698, Colegio Oficial de Geógrafos | Member #698, Spanish
> Professional Association of Geographers
> Web: http://bit.ly/sevillacallejo
>
> 2015-12-08 23:41 GMT+01:00 Ismael Rihawi Aragón :
>
>> Buenas noches a todos,
>>
>> os escribo porque he conocido recientemente la plataforma *OpenStreetMap*,
>> ando realizando un proyecto experimental de tráfico que quiere partir de
>> datos de limitaciones de velocidad por tramos según un origen de
>> coordenadas (x,y) y/o parámetros tales como altitud y latitud, y quería
>> saber si el uso de vuestra API podría proveerme de esta información.
>>
>> Muchas gracias por vuestra atención y tiempo, quedo pendiente de toda
>> contestación por vuestra parte, saludos
>>
>> *Ismael R.*
>>
>>
>>
>> ___
>> Talk-es mailing list
>> Talk-es@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-es
>>
>>
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-it] mapathon umanitario OSM @PoliMi

[Marco Minghini]

Ciao,

riguardo al mapathon di oggi pomeriggio/stasera al Politecnico di Milano,
qui trovate alcune slide che sintetizzano i 2 task su cui ci concentreremo
e spiegano sommariamente come usare il Tasking Manager per chi non l'ha mai
visto: http://tinyurl.com/ptmyhzl

In sintesi, per chi volesse contribuire pur non essendo fisicamente
presente:

1) i task (concordati con HOT e Missing Maps) sono questi due:
- Kampala, Uganda – TASK #1334
- Central Swaziland – TASK #1393

2) vi chiediamo di aggiungere ai commenti dei changeset (che di default
conterranno già la descrizione del task) anche l'hashtag che identifica
l'evento, che è *#xmasmappolimi*. Questo ci serve per poi quantificare il
mapping fatto.

Grazie a chiunque vorrà partecipare!

Marco


Marco Minghini, Ph.D.
GEOlab, Politecnico di Milano - Como Campus
via Valleggio 11, 22100 Como (Italy)
+39 031 3327540
marco.mingh...@polimi.it
@MarcoMinghini

Scopri il nostro MOOC M'appare il mondo:

dalle carte alla Terra digitale partecipata

- un'introduzione per tutti alla cartografia e ai GIS!

Il giorno 11 dicembre 2015 10:08, Stefano  ha scritto:

>
>
> Il giorno 11 dicembre 2015 08:10, Martin Koppenhoefer <
> dieterdre...@gmail.com> ha scritto:
>
>>
>>
>> sent from a phone
>>
>> > Am 11.12.2015 um 07:32 schrieb Stefano :
>> >
>> > Nella stessa discussione si parla di non usare *solo* tags nei commenti
>> al changeset. Non di non usarli. C'erano 54 mail nella discussione, non una.
>>
>>
>> il commento deve essere rivolto agli umani, non è stato contestato. Gli
>> hashtag nei commenti non servono agli scopi e non sono intesi per persone
>> ma per le macchine:
>>
>
>
> OK, E QUINDI?
>
>
>>
>> http://wiki.openstreetmap.org/wiki/Good_changeset_comments
>>
>> questo è il thread:
>> https://lists.openstreetmap.org/pipermail/talk/2015-November/074992.html
>>
>> ciao,
>> Martin
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-br] Conselho do OpenStreetMap == Conselho da OSMF?

[Alexandre Magno Brito de Medeiros]

*Era: "Re: [Talk-br] O que houve com Fernando Trebien?"*

Peter, estou criando novo tópico para sua mensagem.

Internacionalmente existe o Conselho da Fundação OpenStreetMap. Mas eu não
sei o que eles fazem. Estou totalmente por fora. Só sei que recentemente
teve eleições e o nosso Wille estava entre os candidatos.

Alexandre Magno

Em 14 de dezembro de 2015 09:33, Peter Krauss  escreveu:

> Oi gente ... Ouvindo aqui, e lembrando da discussão recente sobre "os
> donos dos nomes das ruas" . ;-)
>
> A Conferência mundial do Clima (COP21) da semana passada parece ter dado
> um indicativo: há diversidade de opiniões, diversidade de metas, etc. mas *não
> podemos deixar de fechar uma negociação*...
> E os pontos-chave são justamente os consensos, e em seguida as
> padronizações em torno desses consensos.
>
> Nome de rua não tem dono, mas *tá na hora da OSM ter um dono, um Conselho*,
> algum tipo de decisão central (*democrática*!) a ser acatada. A solução
> de conflitos sempre passa por isso: um poder maior que as partes
> conflitantes para fixar decisões simples e idealmente consensuais.
>
> - - - -
> PS: a internet está repleta de ferramentas para tomada de decisão
> democrática, discussão em grupos focais, etc, nós e que estamos socialmente
> na idade da pedra... acho que não tem desculpa, estamos enrolando.
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Dúvidas radares e sinaleiras

[Nelson A. de Oliveira]

2015-12-14 10:41 GMT-02:00 Helio Cesar Tomio :
> Qual seria a forma correta?

As duas! :-)

Você vai utilizar um nó na rua apenas quando o radar está posicionado
na própria rua (acima dela, por exemplo).
Ou se quiser representar o mesmo de forma muito simplista.

Com a relação você tem a possibilidade de informar onde exatamente o
radar está, além de especificar a área de atuação dele.
Vai ter "from" e "to", igual uma relação de restrição (aquelas que a
gente mapeia que é proibido retornar ou virar). A diferença é que ao
invés de ter um nó "via" vai ter um "device", que é o nó do radar que
não está conectado na rua.

Você precisa usar uma relação, por exemplo, quando o radar se aplica
apenas a uma direção em uma rodovia de pista simples.

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

[Talk-es] Semanario Nr. 281

[Laura Barroso]

Hola, el semanario Nr. 281, el sumario de todo lo que está ocurriendo en el
mundo de OpenStreetMap está en línea en español
http://www.weeklyosm.eu/es/ ¡Disfruta!

WeeklyOSM en Español esta produzido por:
https://wiki.openstreetmap.org/wiki/WeeklyOSM








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

Re: [Talk-it] Uffici ACI

[Federico Cortese]

2015-12-12 21:25 GMT+01:00 Martin Koppenhoefer :
>
> interessante. Essendo l'ACI un ente dello stato è quindi molto diversa la 
> situazione rispetto agli altri club automobilistici, che sono di diritto 
> civile. In questo caso direi che leisure=club non va bene per l'ACI.
>

Si infatti pur chiamandosi "Automobile Club", la sua funzione è
propriamente amministrativa, piuttosto che ludica.


2015-12-12 20:22 GMT+01:00 Stefano :
>
> Finché non sposteranno il PRA alla Motorizzazione (o simile riforma), rimane
> un ente che offre servizi pubblici, quindi dovrebbe essere rappresentato
> come gli sportelli dell'agenzia delle entrate e simili...
>

Per l'Agenzia delle Entrate  si dovrebbe usare office=tax (wiki:
Fiscal authorities, tax and revenue office. Possible duplicate of
office=government.)
Forse per l'ACI a questo punto preferirei office=administrative (wiki:
Local authorities, administrative and supervising institutions that
are not related to state government.)

Ciao

Federico

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

Re: [OSM-talk-fr] 2 relations pour le Rhône

[Tony Emery]

Jérôme Seigneuret wrote
> Dans tous les cas l'emprise des zones d'eau n'est pas incluse dans la
> première relation et c'est pas normal donc à voir
> http://wiki.openstreetmap.org/wiki/Relation:waterway
> 
> Jérôme

Du coup, on peut corriger tout ça ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/2-relations-pour-le-Rhone-tp5862437p5862448.html
Sent from the France mailing list archive at Nabble.com.

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

[OSM-talk-fr] 2 relations pour le Rhône

[Tony Emery]

Bonjour à tous,

Je ne sais pas si vous l'avez remarqué, mais le fleuve Rhône possède 2
relations 660056 et 1075117.

Si j'ai bien compris, la relation  660056
   concerne
l'emprise surfacique du fleuve alors que la relation  1075117
   concerne le
filaire.

Comprenez-vous la même chose que moi et si c'est la cas, pourquoi cette
bizarrerie ?
De plus, le objets de la relation des emprises n'ont (presque tous) plus
aucun tag, ce qui fait qu'on ne peut plus les récupérer dans les requêtes
simples (waterway=* ou natural=water).

Avez-vous le même problème ? Est-ce une erreur ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/2-relations-pour-le-Rhone-tp5862437.html
Sent from the France mailing list archive at Nabble.com.

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

[OSM-talk-fr] Nouvelle gare de Rosa Parks

[Florian LAINEZ]

Hello,
Hier a ouvert la nouvelle gare Transilien de Rosa Parks, sur la ligne E,
pas loin de gare du Nord.

On est quelques uns à avoir bossé sur une micro-carto indoor, voici le
résultat :
http://github.pavie.info/openlevelup/?lat=48.896459=2.374063=20=0=0=1=0=0=0=0

Tout n'est pas encore terminé, je pense à certains équipements qu'on a pas
encore ajouté, ou encore la description des alentours (ex. arbres au sud,
calage des arbres ...).

On a calé le bâti depuis le plan d'architecte et importé certains éléments
comme les piliers, et pour compléter ça je suis allé prendre des photos
360° hier dans la gare cf.
http://www.mapillary.com/map/search/48.89667895659059/2.3741417040492365/17.334957027564734Q

Votre aide est la bienvenue pour boucler tout ça !  Si vous voulez un petit
guide concernant les tags ça se passe ici :
http://wiki.openstreetmap.org/wiki/FR:Railway_stations

Bonne journée

-- 

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

Re: [Talk-br] Conselho do OpenStreetMap == Conselho da OSMF?

[Linhares XT]

Alexandre, eu acho que o OSMF se preocupa com questões mais administrativas
e menos práticas. Quem resolve conflitos é o Data Working Goup (wiki
).

Abraços, Linhares

PS: aproveitando o ensejo: As discussões sobre classificação de vias são
realmente muito desgastantes. Eu comentei no fórum sobre o sumiço das
*highway=trunk*, mas depois me veio à mente que isto deve ser fruto de
alguma dessas discussões e, pra variar, alguém resolveu mudar todo o Brasil
por conta disso...
Enfim :-/


2015-12-14 10:52 GMT-02:00 Alexandre Magno Brito de Medeiros <
alexandre@gmail.com>:

> *Era: "Re: [Talk-br] O que houve com Fernando Trebien?"*
>
> Peter, estou criando novo tópico para sua mensagem.
>
> Internacionalmente existe o Conselho da Fundação OpenStreetMap. Mas eu não
> sei o que eles fazem. Estou totalmente por fora. Só sei que recentemente
> teve eleições e o nosso Wille estava entre os candidatos.
>
> Alexandre Magno
>
> Em 14 de dezembro de 2015 09:33, Peter Krauss 
> escreveu:
>
>> Oi gente ... Ouvindo aqui, e lembrando da discussão recente sobre "os
>> donos dos nomes das ruas" . ;-)
>>
>> A Conferência mundial do Clima (COP21) da semana passada parece ter dado
>> um indicativo: há diversidade de opiniões, diversidade de metas, etc. mas 
>> *não
>> podemos deixar de fechar uma negociação*...
>> E os pontos-chave são justamente os consensos, e em seguida as
>> padronizações em torno desses consensos.
>>
>> Nome de rua não tem dono, mas *tá na hora da OSM ter um dono, um
>> Conselho*, algum tipo de decisão central (*democrática*!) a ser acatada.
>> A solução de conflitos sempre passa por isso: um poder maior que as partes
>> conflitantes para fixar decisões simples e idealmente consensuais.
>>
>> - - - -
>> PS: a internet está repleta de ferramentas para tomada de decisão
>> democrática, discussão em grupos focais, etc, nós e que estamos socialmente
>> na idade da pedra... acho que não tem desculpa, estamos enrolando.
>>
>
> ___
> 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-be] Voorstel import GRB gebouwen

[Jo]

Hallo Frank,

Als wij hier een 'import' opzetten, dan komt dat eigenlijk neer op het
klaarzetten van data die omgezet is in OSM-formaat. Het eigenlijke
toevoegen van de gebouwen en hun adressen, is iets dat we dan met z'n allen
aanpakken. In geval van 'conflicten' met bestaande gebouwen, is het dan de
bedoeling dat degene die zich daarmee bezig houdt, nakijkt wat er (al)
beter is en eventueel het beste van beide werelden overneemt.

Voor 3D-gebouwen zou het dus kunnen dat het grondplan wat wijzigt en dat er
moet worden nagekeken of dat invloed heeft op het resultaat. In de meeste
gevallen, denk ik, dat die gebouwen gewoon worden overgeslagen, als we ze
al in voldoende detail voor 3D hebben.

In Brussel was het de bedoeling om veel 'overbodige' punten te verwijderen,
dat is niet altijd gebeurd. Ik heb er nog niet naar gekeken, maar als deze
gebouwcontouren ook zulke punten hebben, zijn die misschien wel interessant
voor iemand die er verder mee wil, richting 3D. Ik zou ze dan dus gewoon
behouden.

Jo

Op 14 december 2015 13:49 schreef Jakka :

> Wat gebeurt er met de 3D taggen die op de manueel ingetekende buildings
> verder uitgewerkt werden ?
>
> http://wiki.openstreetmap.org/wiki/3D
>
>
> http://demo.f4map.com/#lat=50.7799026=3.1892977=16=33.827=-0.573
>
>
> http://demo.f4map.com/#lat=50.7960880=3.1202353=19=70.514=77.636
>
>
> http://demo.f4map.com/#lat=50.7892170=3.1404653=19=70.514=77.636
>
>
> Sander Deryckere schreef op 13/12/2015 om 19:07:
>
>> Hallo,
>>
>> Na het bekijken van een hoop GRB data zou ik graag voorstellen om de
>> gebouwen te importeren.
>>
>> Ik heb het hier over het "Gebouwen aan de Grond" (Gbg) bestand, en de
>> tabel van de gebouwen met adressen (TblGbgAdr).
>>
>> De kwaliteit van de GRB gebouwen is goed genoeg. De voorgevels zijn veel
>> precieser dan wat wij momenteel kunnen opmeten, en de achtergevels
>> hebben ongeveer dezelfde kwaliteit als onze kwaliteit.
>>
>> In het GRB zitten dus ook adressen, maar een gebouw kan geen, één of
>> meerdere adressen hebben, en een adres uit het GRB kan toegekend zijn
>> aan één of meerdere gebouwen (daarnaast bevat het GRB ook niet alle
>> adressen).
>>
>> Ik zou dus graag de GRB import koppelen aan de CRAB import, en de web
>> app uitbreiden.
>>
>> De gebouwen van het GRB kunnen opgesplitst worden per postcode, en de
>> gebouwen die 1-op-1 overeenkomen met een adres kunnen onderverdeeld
>> worden per straat. De gebouwen die niet toebehoren aan een straat kunnen
>> in een apart bestand per postcode gezet worden.
>>
>> Door een kolom toe te voegen aan de crab-import web app kunnen dus eerst
>> de gebouwen per straat worden geïmporteerd, en daarna de aparte
>> adrespunten voor welke we zelf nog moeten uitzoeken tot welk gebouw ze
>> behoren.
>>
>> In theorie is dit allemaal niet zo moeilijk, maar de GRB database is
>> vele malen groter dan de CRAB database, dus zullen we dit niet meer
>> kunnen hosten op Github, en zullen we een aparte server moeten nemen. Ik
>> vrees ook dat ik niet genoeg computerkracht heb om een dergelijke
>> database in te lezen en te splitsen in verschillende OSM bestanden. Dus
>> zullen we dit verder moeten automatiseren op een zwaardere server.
>>
>> Wat denken jullie hier over?
>>
>> Mvg,
>> Sander
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Transilien.com - OpenStreetMap

[Florian LAINEZ]

Bonjour,
Merci pour vos retours.

Il y a deux fois "Horaires" dans le menu:
> http://www.transilien.com/lignes/rer-trains/rer-A
>

Ce sont les anciens horaires avant le 13 décembre et ceux après le 13
décembre, afin de permettre aux usagers de prévoir leurs trajets à l'avance.
Maintenant que la date est passée, nous n'allons pas tarder à enlever cette
information dupliquée. Bien vu !

J'imagine que les horaires sont les théoriques : y a-t-il un moyen d'avoir
> les horaires en temps réel, voire une carte montrant où se trouvent les
> trains sur la ligne?
>

Pour avoir accès à notre API temps réel, il faut me faire une demande à
l'adresse ext.synergie.florian.lai...@sncf.fr
Plus d'informations et la doc sont disponibles à l'adresse
https://ressources.data.sncf.com/explore/dataset/api-temps-reel-transilien/

Pour la carte de tous les trains SNCF en temps réel, ça se passe ici :
http://www.sncf.com/fr/geolocalisation
Vous noterez le fond de carte OSM ;)

Bonne journée


Le 12 décembre 2015 à 18:04, pepilepi...@ovh.fr  a
écrit :

> Le 12/12/2015 11:49, Shohreh a écrit :
>
> Il y a deux fois "Horaires" dans le 
> menu:http://www.transilien.com/lignes/rer-trains/rer-A
>
> J'imagine que les horaires sont les théoriques : y a-t-il un moyen d'avoir
> les horaires en temps réel, voire une carte montrant où se trouvent les
> trains sur la ligne?
>
> Vu le nombre de retards et annulations, c'est plus utile que les horaires
> officiels.
>
>
> Bonsoir,
>
> Jusque il y a pas longtemps il y avait OSM tchoutchou
>  mais comme le déplore son créateur (?) il a été
> torpillé par la SNCF (ou du moins sa source de données). Il reste sur ce
> site un moyen de contacter l'auteur.
>
> Ceci dit je ne sais pas s'il allait jusqu'à suivre les RER.
>
> Bon dimanche,
>
> JP
>
>
>
>
>
>
> --
> View this message in context: 
> http://gis.19327.n5.nabble.com/Transilien-com-OpenStreetMap-tp5861552p5862303.html
> Sent from the France mailing list archive at Nabble.com.
>
> ___
> Talk-fr mailing 
> listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr
>
>
>
> --
>
> Joyeux Noël et Bonne Année 2016
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

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

[Talk-co] Semanario Nr. 281

[Laura Barroso]

Hola, el semanario Nr. 281, el sumario de todo lo que está ocurriendo en el
mundo de OpenStreetMap está en línea en español
http://www.weeklyosm.eu/es/ ¡Disfruta!

WeeklyOSM en Español esta produzido por:
https://wiki.openstreetmap.org/wiki/WeeklyOSM








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

[Talk-cl] Semanario Nr. 281

[Laura Barroso]

Hola, el semanario Nr. 281, el sumario de todo lo que está ocurriendo en el
mundo de OpenStreetMap está en línea en español
http://www.weeklyosm.eu/es/ ¡Disfruta!

WeeklyOSM en Español esta produzido por:
https://wiki.openstreetmap.org/wiki/WeeklyOSM








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

Re: [OSM-talk] Nominatim weakness

[Colin Smale]

Could there also be sorting options for the result set? For example by
distance (nearest first), importance (the current algorithm?), ... 

And how about filters to show what you are looking for: returning
places, POIs, roads, ...

//colin 

On 2015-12-14 13:43, Jorge Gustavo Rocha wrote:

> Hi,
> 
> I think that we can add an option to bound the results to the current 
> viewport. That option would be passed to nominatim or any other search engine.
> 
> Personally, I would prefer the search bounded by default, but users could 
> change it to "everywhere" to see additional results.
> 
> Regards,
> 
> J. Gustavo
> 
> Às 11:17 de 14-12-2015, Martin Koppenhoefer escreveu: 
> 
>> 2015-12-14 10:04 GMT+01:00 Sarah Hoffmann > >:
>> 
>> If you type in 'Starbucks' in the search box, then you just get
>> objects named that way. No difference with searching for, say Berlin.
>> 
>> Now, if you type 'cafes' in the search box, then you are probably
>> looking for all amenity=cafe and that is a POI search. It's true
>> that this particular query doesn't work on osm.org .
>> You have to
>> additionally specify a place, e.g. 'cafes in Poughkeepsie' actually
>> returns the one Starbucks in town.
>> 
>> if I search for
>> "Starbucks in Holland" I get not hit, neither for
>> "Starbucks in the Netherlands"
>> "Starbucks in Netherlands"
>> "Starbucks in Amsterdam"
>> 
>> but "starbucks, Netherlands" yields a lot of results (there's even a
>> restaurant among them). Btw., also "starbucks, Holland" leads to a lot
>> of results (not sure if they are the sama, they are in different sorting
>> order at least). You can even omit the comma, but you shouldn't add an
>> "in" because this will lead to no results.
>> 
>> 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: [OSM-talk-fr] Nouvelle gare de Rosa Parks

[dHuy Pierre]

Petit commentaire sur la plateforme: Y a-t-il un ou deux quais? Dans ce cas il 
y aura deux plateformes, non? 


Le Lundi 14 décembre 2015 14h24, Florian LAINEZ  a écrit 
:
 

 Hello,
Hier a ouvert la nouvelle gare Transilien de Rosa Parks, sur la ligne E, pas 
loin de gare du Nord.

On est quelques uns à avoir bossé sur une micro-carto indoor, voici le résultat 
: 
http://github.pavie.info/openlevelup/?lat=48.896459=2.374063=20=0=0=1=0=0=0=0

Tout n'est pas encore terminé, je pense à certains équipements qu'on a pas 
encore ajouté, ou encore la description des alentours (ex. arbres au sud, 
calage des arbres ...).

On a calé le bâti depuis le plan d'architecte et importé certains éléments 
comme les piliers, et pour compléter ça je suis allé prendre des photos 360° 
hier dans la gare cf. 
http://www.mapillary.com/map/search/48.89667895659059/2.3741417040492365/17.334957027564734Q
Votre aide est la bienvenue pour boucler tout ça !  Si vous voulez un petit 
guide concernant les tags ça se passe ici : 
http://wiki.openstreetmap.org/wiki/FR:Railway_stations

Bonne journée

-- 
  FlorianLainez
@overflorian

___
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] Nominatim weakness

[John Goodman]

> To make a long story short: it's a tagging error. The wikipedia tag
> should contain only links to wikipedia pages describing the object
> not to pages about the operator.

Sorry, I'm with Maarten on this: it's a programming error.

I've tried searching on plenty of common stores and businesses that the 
average user here in the US might -- Dunkin' Donuts, Kohl's, PetSmart, 
Lowe's, Dollar Tree, Sports Authority, Red Roof Inn -- and the matching 
location that is ACTUALLY ON THE MAP in front of me is almost never 
shown in the first page of hits, let alone on the top of the list.


I'm well aware that OSM is more than a map, but the fact remains that 
when I tell people "Hey, you should check out OpenStreetMap", the first 
thing they see is the main map page. And if its searching facility is 
braindead, I feel we're doing ourselves a disservice.


John

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

[OSM-talk-be] Mapper in the Spotlight

[Marc Gemis]

Hallo,

While you are waiting for the next interview with a Belgian mapper,
you can read one with Lutz Lange from Germany

http://www.openstreetmap.org/user/escada/diary/37532 (in German)
http://www.openstreetmap.org/user/escada/diary/37533 (in English)


regards

m

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

Re: [Talk-it] Parrocchiale

[Simone Cortesi]

2015-12-14 16:11 GMT+01:00 Ilario Valdelli :
> Cioé la casa dove dovrebbe vivere il parroco, in genera annessa alla chiesa?

potrebbe anche essere la sede della diocesi locale?

prova a guardare in questa pagina wiki:
http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreligious

-- 
-S

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

Re: [OSM-talk] Nominatim weakness

[John Goodman]

Please avoid being gratuitously offensive by describing something that lots
of volunteers have put countless hours into as "braindead".


No offense meant; it just seemed an apt term for a search algorithm that 
favors matches 15,000 km away from one right in the area of obvious 
interest.


As an aside, I've just spent the last 2-1/2 months completely addressing 
and detailing a city of 40,000, so I am familiar with "countless hours".


John

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

Re: [OSM-talk-be] Voorstel import GRB gebouwen

[Sander Deryckere]

Jo,

De GRB gebouwen hebben ook enkele overbodige punten, maar deze zijn niet
nuttig in OSM. De overbodige punten uit het GRB zijn meetpunten.
Bijvoorbeeld als de achterkant van het gebouw niet opgemeten is kan het
gebeuren dat er een extra meetpunt staat op de zijgevel, om de hoek exact
te bepalen. Dit meetpunt op de zijgevel is natuurlijk totaal overbodig in
OSM, maar doordat het zo exact op een rechte lijn ligt, kan het ook
eenvoudig verwijderd worden. Ook bij enkele gebouwen met boogvormen zijn er
meer nodes dan nodig in OSM.

De simplifyAreas plugin van JOSM werkt het best om deze te verwijderen (en
je kan gerust heel strikte instellingen gebruiken), maar ik denk dat we die
functionaliteit wel kunnen kopiëren naar de preprocessor.

@jakka: het is zeker niet de bedoeling om iedereens werk zomaar te
overschrijven. Daar zijn we in België niet meteen voorstander van ;)



Op 14 december 2015 14:45 schreef Jo :

> Hallo Frank,
>
> Als wij hier een 'import' opzetten, dan komt dat eigenlijk neer op het
> klaarzetten van data die omgezet is in OSM-formaat. Het eigenlijke
> toevoegen van de gebouwen en hun adressen, is iets dat we dan met z'n allen
> aanpakken. In geval van 'conflicten' met bestaande gebouwen, is het dan de
> bedoeling dat degene die zich daarmee bezig houdt, nakijkt wat er (al)
> beter is en eventueel het beste van beide werelden overneemt.
>
> Voor 3D-gebouwen zou het dus kunnen dat het grondplan wat wijzigt en dat
> er moet worden nagekeken of dat invloed heeft op het resultaat. In de
> meeste gevallen, denk ik, dat die gebouwen gewoon worden overgeslagen, als
> we ze al in voldoende detail voor 3D hebben.
>
> In Brussel was het de bedoeling om veel 'overbodige' punten te
> verwijderen, dat is niet altijd gebeurd. Ik heb er nog niet naar gekeken,
> maar als deze gebouwcontouren ook zulke punten hebben, zijn die misschien
> wel interessant voor iemand die er verder mee wil, richting 3D. Ik zou ze
> dan dus gewoon behouden.
>
> Jo
>
> Op 14 december 2015 13:49 schreef Jakka :
>
> Wat gebeurt er met de 3D taggen die op de manueel ingetekende buildings
>> verder uitgewerkt werden ?
>>
>> http://wiki.openstreetmap.org/wiki/3D
>>
>>
>> http://demo.f4map.com/#lat=50.7799026=3.1892977=16=33.827=-0.573
>>
>>
>> http://demo.f4map.com/#lat=50.7960880=3.1202353=19=70.514=77.636
>>
>>
>> http://demo.f4map.com/#lat=50.7892170=3.1404653=19=70.514=77.636
>>
>>
>> Sander Deryckere schreef op 13/12/2015 om 19:07:
>>
>>> Hallo,
>>>
>>> Na het bekijken van een hoop GRB data zou ik graag voorstellen om de
>>> gebouwen te importeren.
>>>
>>> Ik heb het hier over het "Gebouwen aan de Grond" (Gbg) bestand, en de
>>> tabel van de gebouwen met adressen (TblGbgAdr).
>>>
>>> De kwaliteit van de GRB gebouwen is goed genoeg. De voorgevels zijn veel
>>> precieser dan wat wij momenteel kunnen opmeten, en de achtergevels
>>> hebben ongeveer dezelfde kwaliteit als onze kwaliteit.
>>>
>>> In het GRB zitten dus ook adressen, maar een gebouw kan geen, één of
>>> meerdere adressen hebben, en een adres uit het GRB kan toegekend zijn
>>> aan één of meerdere gebouwen (daarnaast bevat het GRB ook niet alle
>>> adressen).
>>>
>>> Ik zou dus graag de GRB import koppelen aan de CRAB import, en de web
>>> app uitbreiden.
>>>
>>> De gebouwen van het GRB kunnen opgesplitst worden per postcode, en de
>>> gebouwen die 1-op-1 overeenkomen met een adres kunnen onderverdeeld
>>> worden per straat. De gebouwen die niet toebehoren aan een straat kunnen
>>> in een apart bestand per postcode gezet worden.
>>>
>>> Door een kolom toe te voegen aan de crab-import web app kunnen dus eerst
>>> de gebouwen per straat worden geïmporteerd, en daarna de aparte
>>> adrespunten voor welke we zelf nog moeten uitzoeken tot welk gebouw ze
>>> behoren.
>>>
>>> In theorie is dit allemaal niet zo moeilijk, maar de GRB database is
>>> vele malen groter dan de CRAB database, dus zullen we dit niet meer
>>> kunnen hosten op Github, en zullen we een aparte server moeten nemen. Ik
>>> vrees ook dat ik niet genoeg computerkracht heb om een dergelijke
>>> database in te lezen en te splitsen in verschillende OSM bestanden. Dus
>>> zullen we dit verder moeten automatiseren op een zwaardere server.
>>>
>>> Wat denken jullie hier over?
>>>
>>> Mvg,
>>> Sander
>>>
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-it] Estratti regionalidi FMACH

[Martin Koppenhoefer]

2013-09-26 12:39 GMT+02:00 Cristian Consonni :

> Il 21 settembre 2013 14:52, Luca Delucchi  ha
> scritto:
> > 2013/9/21 Luca Delucchi :
> >>
> >> ok, ho investigato meglio e sembra che ci sia un errore con
> >> osmconvert, ho scaricato la nuova versione e lanciato lo script,
> >> vediamo che succede (intanto controllo il log)
> >
> > allora continua a darmi l'errore ma crea dei file che sembrano essere
> validi.
> > L'errore è il seguente ma non trovo nulla:
> > osmconvert Error: main-element type unknown: 0x4C 0xA1.
>



mi succede anche a me, ottengo:
$ osmconvert --out-statistics molise.pbf

osmconvert Error: main-element type unknown: 0xFE 0xC3.


Avete cambiato qualcosa negli ultimi giorni? A voi funziona?

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

Re: [OSM-talk] Nominatim weakness

[Richard Fairhurst]

John Goodman wrote:
> And if its searching facility is braindead

Please avoid being gratuitously offensive by describing something that lots
of volunteers have put countless hours into as "braindead".

Thank you.

Richard




--
View this message in context: 
http://gis.19327.n5.nabble.com/Nominatim-weakness-tp5862392p5862453.html
Sent from the General Discussion mailing list archive at Nabble.com.

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

[Talk-cz] WeeklyOSM CZ 280

[Tom Ka]

Ahoj, je dostupné vydání 280 týdeníku weeklyOSM:

http://www.weeklyosm.eu/cz/archives/6166

Téma čísla: Trasy KČT – projekt taskman

* Videa z OpenAlt 2015.
* Další úsek D1 na Slovensku.
* lokální letecké snímky v iD.
* Přehled kandidátů do OSMF.
* Velikost národních komunit
* Nové domény osm.map a spol.

Pěkné počtení...

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

Re: [Talk-it] Parrocchiale

[Simone]

Il 14 dicembre 2015 16:11:10 CET, Ilario Valdelli  ha 
scritto:
>Potreste indicarmi come segnalare una parrocchiale?
>
>Cioé la casa dove dovrebbe vivere il parroco, in genera annessa alla
>chiesa?

Cerca una recente discussione su "canonica", l'ho aperta io e riguarda questo.


-- Simone Girardelli--

Inviato con K-9 Mail dal mio Samsung S5
Scusate la brevità dello scritto.

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

Re: [Talk-at] Seehöhen

[grubernd]

On 2015-12-13 22:14, Friedrich Volkmann wrote:

Damit wir nicht den Überblick verlieren, hier die beiden Dinge, für die ich
mir von dir ein Beispiel wünschen würde:
1) herumspringende oder dubiose Werte im Laserscan
2) Gipfel, die in der Basemap gerendert werden, aber nicht in der höchsten
Zoomstufe


https://overpass-api.de/achavi/?changeset=35589250

das ist das Gelände in dem ich mich in letzter Zeit viel virtuell bewegt 
habe, der letzte persönliche Besuch ist schon eine zeitlang her, aber 
dort oben ist das Leben langsam.


das Changeset ist noch ohne Querreferenz zum Laserscan gemacht, aber ich 
habe auf Grund der Aktualität nach deinem Hinweis dort den Laserscan 
angeschaut. und beim Eintragen hatte ich alle vorher beschriebenen 
Effekte irgendwann.




insofern hast du schon recht. GIS nehmen. klicki-bunti, 5 Werte mitteln, passt.

Nicht mitteln. Der höchste Wert gewinnt! Dadurch sind Gipfelhöhen eh sehr
einfach abzufragen, im Gegensatz zu Sattel-Höhen.


wie gesagt .. ich traue dem Laserscan nicht so sehr, dass da zuverlässig 
alle Latschen sauber rausgerechnet wurden und ausserdem der höchste 
Punkt exakt erwischt wurde und man den dann auch noch findet.

und alles was unsicher ist wird aus Prinzip genähert und gerundet.

grüsse, grubernd

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

Re: [Talk-pt] Consenso sobre mapeação de povoações

[Rui Oliveira]

Quanto ao caso de coimbra a cidade em si vai um pouco mais além cintura
externa do lado direito, apanha ainda a zona norte por perto de eiras /
trouxemil e apanha ainda do lado esquerdo uma boa parte de santa clara que
fica para além do rio mondego.   As delimitações de Coimbra cidade não são
talvez tão evidentes como viana do castelo.

Mas talvez isso seja devido ao facto de eu sempre de ainda termos que
diferenciar o distrito de coimbra esse é uma área bastante grande que
apanha  todo o litoral até à figueira da foz, e apanha ainda um pouco do
interior até perto da serra da estrela.

Mas se a comunidade optar pela tua proposta seria uma questão de  a
trabalharmos mais com outras ideias que espero que venham.

Esqueci-me de dizer no mail anterior que, na prática eu tenho seguido uma
classificação muito idêntica ao que referes, apenas diferente em dois
pormenores. Tento diferenciar quando é village ou town, e tenho usado
suburb em vez e neighborhood. Mas pode-se mudar desde que a comunidade
suporte as tuas alterações.

Vamos dar mais tempo e esperar que outros dêem a sua opinião, porque uma
alteração destas deve merecer o feedback de mais membros da comunidade.

2015-12-14 16:10 GMT+00:00 Marcos Oliveira :

> Obrigado Rui!
>
> De facto, a diferenciação de *place = suburb* e *place = neighbourhood* é
> a mais difícil de ser feita. Normalmente *place = suburb *utiliza-se só
> nas maiores metrópoles, que para Portugal deveria ser Lisboa e Porto e
> poucos mais.
>
> Sim, segundo esta classificação os *place = suburb *que
> vigoram tornar-se-iam *place = neighbourhood*. Um compromisso poderia ser
> a reclassificação de um *place = neighbourhood *para *place = suburb* só
> quando este é (ou foi) capital de uma freguesia que está "anexada" à cidade
> ou vila vizinha, como por exemplo em Viana do Castelo, onde existe uma
> malha urbana que se estende por várias freguesias onde é impossível
> delimitar um "limite" da cidade. [1]
>
> Será que é possível fazer o mesmo para Coimbra, ou será que a cidade em si
> está confinada dentro da Cintura Externa de Coimbra?
>
> Quanto às cidades e vilas, penso que seja é melhor esperar e receber mais
> comentários com o apoio/contra da sua união sob a tag *place = town* de
> forma a chegarmos a um consenso.
>
> [1] - http://www.openstreetmap.org/#map=14/41.7042/-8.8266
>
>
> No dia 14 de dezembro de 2015 às 15:34, Nuno Gomes Lopes <
> n.gomeslo...@gmail.com> escreveu:
>
>> Boa tarde a tod@s. Fui eu que sugeri ao Marcos a alteração em relação às
>> vilas. Em Portugal a diferenciação entre 'vilas' e 'cidades' é muitas das
>> vezes pro forma, e as elevações de vilas a cidades passa mais pela
>> afirmação política de determinada aglomeração. Lembro que o concelho de
>> Paredes tem várias vilas e cidades e que Sintra, Cascais e Ponte de Lima
>> são vilas (por vontade própria). O mesmo para a definição de 'city' - Porto
>> e Lisboa serão certamente 'city', mas Portalegre e Bragança nem por isso.
>>
>>
>> --
>>  
>>
>> ___
>> Talk-pt mailing list
>> Talk-pt@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-pt
>>
>>
>
> --
> Um Abraço,
> Marcos Oliveira
>
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>
>
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

[OSM-talk] How does one tag a business that closed and was replaced by something else?

[Andrew Wiseman]

Hi,

In this case, two businesses closed and were replaced by a single business
that took over both buildings (they are adjoining.) How should I tag this?
I didn't see anything about closed: or former: on the wiki.

Thanks,

Andrew

-- 

600,000 DC residents don't have a vote in Congress -- http://www.dcvote.org/

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

Re: [Talk-it] Parrocchiale

[girarsi_liste]

Eccola, nel caso non l'hai trovata.

https://lists.openstreetmap.org/pipermail/talk-it/2015-December/050307.html


-- 
Simone Girardelli
_|_|_|_|_|_|_|_|_|_
|_|_|_|_|_|_|_|_|_|_|



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

Re: [OSM-talk] Nominatim is awesome

[michael spreng]

On 14/12/15 18:14, John Goodman wrote:
>> Please avoid being gratuitously offensive by describing something
>> that lots
>> of volunteers have put countless hours into as "braindead".
>
> No offense meant; it just seemed an apt term for a search algorithm
> that favors matches 15,000 km away from one right in the area of
> obvious interest.
>
This still sounds rather silly.
It is your definition of important, your important is not everyone's
view of important.
Nominatim has a rather large back log of a lot more helpful and
important features and fixes, with very few around to actually keep it
running. This thread feels not important in contrast to many other things.

I'm unfortunately not donating time to develop Nominatim. Non the less
this thread feels strange. It is good to voice issues, but please accept
the answer. Not much good comes of repeating how some think the
priorities are not set right.

Do it, don't keep talking about it. (By which I mean make an
implementation, and see it fail lots of times until you get it right. It
is a rather complex topic.)

Michael

P.S: John please do not top-post. Each of your mails started a new
thread in the mails.


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

Re: [OSM-talk] How does one tag a business that closed and was replaced by something else?

[Lester Caine]

On 14/12/15 17:18, Andrew Wiseman wrote:
> In this case, two businesses closed and were replaced by a single
> business that took over both buildings (they are adjoining.) How should
> I tag this? I didn't see anything about closed: or former: on the wiki.

If the units are individually identified simply re-tag each with the new
name. While some people will say 'historic data does not belong', the
change record for each building will retain the history. If you delete
each and create a new single building a lot of history which IS recorded
will be lost. At some point the two units may split again. I presume
that both already have their own address entries anyway?

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

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

[Talk-it] Strade presenti in open data e mancanti in OSM

[Simone F.]

Ciao,

tempo fa, avevo confrontato le strade in OSM con quelle rilasciate dai
comuni di Rimini e Verona, per la curiosità di vedere quelle ancora da
mappare. Un mese fa ho aggiunto altri confronti, grazie al rilascio di
nuovi dati segnalati in lista.
La pagina è stata spostata qui:

http://geodati.fmach.it/gfoss_geodata/osm/compare-to-osm-italy/

Grazie a Luca Delucchi per ospitarla sul server.

Cliccando sulla mappa compare un link per aprire JOSM o iD su quella
posizione.

Forse potrebbe essere utile per "La Notte dei Mappatori Viventi".

Note:
- ci sono diversi falsi positivi, vicino ai confini (per come vengono
ritagliati i dati OSM) e dove le strade open data ed OSM si discostano
- per il Veneto ho usato la CTR, su segnalazione di Leonardo. Gli shapefile
usati, però, contengono solamente le strade maggiori e programmate, quindi
non è molto utile e ci sono molti falsi positivi.

Domanda tecnica:
sarebbe bello sapere anche i km di strade da mappare; in Basilicata mi
risultano essere 12716... È possibile?
Per calcolarlo ho eseguito, su un tabella con geometrie Linestring in
PostGIS:
"SELECT SUM(ST_Length(geometry::geography))/1000 FROM nometabella;"


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

Re: [OSM-talk-fr] 2 relations pour le Rhône

[JB]

Le 14/12/2015 20:43, Jérôme Seigneuret a écrit :

D'ailleurs en multipolygone sous JOSM c'est automatiquement fusionné

Pardon ? Tu peux préciser, s'il te plait ?
JB.

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

Re: [OSM-talk-fr] 2 relations pour le Rhône

[Jérôme Seigneuret]

Le 14 décembre 2015 à 20:49, JB  a écrit :

> Le 14/12/2015 20:43, Jérôme Seigneuret a écrit :
>
>> D'ailleurs en multipolygone sous JOSM c'est automatiquement fusionné
>>
> Pardon ? Tu peux préciser, s'il te plait ?
> JB.


Ok j'ai mal présenté la chose...

Soit  un way fermé A, un way fermé B et un way fermé C.
A et B sont jointifs et C et situé entre les deux et est jointif donc avec
A et B

Si tu combines A et B les entités sont transformés en une seul faisant
parti d'un mutipolygone avec le role outer et C est incluse avec le role
inner directement. Les attributs de A et B sont alors remonté sur la
relation multipolygone (avec alerte si des clés ou valeurs sont différentes)

Sinon A et B sont juste incluse dans le multipolygone ça émet une alerte
car il existe des parties jointives

Sinon sans multipolygone, rien n’empêche de mettre A et B dans un autre
type de relation. type=waterway s'apparente à un dictionnaire de données
dans lequel on regroupe des objets avec des role specifique

Sans C, A et B peuvent être fusionné et cela n'implique en aucun cas un
multipolygone.

Si le multipolygone n'apporte pas de précision spécifique c'est qu'il sert
à rien. C'est juste un groupement d'élément de même nature.
C'est comme mettre des landuse=residential sans nom dans une relation
multipolygone. Inutile
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] Importing Vicmap Lite data

[Simon Poole]

Am 14.12.2015 um 03:17 schrieb Russell Edwards:
> Hi,
>
> I just wanted to double check before I do this as people seem to talk
> casually about using Vicmap Lite data but the OSM Wiki has a long
> process to go through with the community before doing any imports.

It should be pointed out that the rules are there for a reason: a decade
of experience that imports are in general screwed up and the people
responsible for them then vanish leaving a mess behind for others to
clean up.

>
> I have downloaded "Statewide Public Land Classification boundaries,
> polygon - 1:250,000 to 1 :2 million. Vicmap Lite". It is CC
> BY-4.0-International.
>

Currently the status of  CC BY-4.0 licensed data is unclear, this is due
to some quirks in how the 4.0 version of CC BY works. We are waiting for
CC to get back to the OSMF to clarify. which might happen in this decade
or not. In other words: such data will need explicit permission for an
import.

> I want to add boundaries of some local state forests I frequent, using
> this data. My questions are
>
> * Can I just go ahead and do it?
> * I haven't done boundaries before, do I need a shared node where
> roads and waterways cross the boundary?
> * What if there is an existing overlapping area natural=wood that
> follows the aerial tree extent (which doesn't exactly match the
> boundary)? Leave them both there? Do I need natural=wood on the state
> forest boundary area to, to make it display green? What about the
> conflict there?
> * Anything else to watch for?
>
Landuse imports are notoriously difficult to do correctly, matter of
fact I'm fairly sure that we have never had one which wasn't a failure
in one way or another. If you have never done boundaries before then you
should be doing boundaries before. That will give you some idea of what
you are getting in to and will give you answers to your questions.

Simon


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

Re: [Talk-it] La Notte dei Mappatori viventi

[Andrea Albani]

Una piccola nota: nella pagina wiki non si parla della necessità di
attivare il controllo remoto di JOSM. Non mi sembra sia attivo per default,
ma potrei ricordare male

Il giorno 10 dicembre 2015 16:13, Alessandro Palmas <
alessandro.pal...@wikimedia.it> ha scritto:

> Pubblicata la pagina wiki
>
> https://wiki.openstreetmap.org/wiki/2015_Dicembre_La_Notte_dei_Mappatori_Viventi
>
> Non è ancora definitivo, mancano ad esempio i link ai WMS della Regione
> Calabria perchè è da stamane che hanno il sito giù
> http://pr5sit.regione.calabria.it/web/pr5sit/home
>
> Si inizia venerdì 18, per chi quella sera non potrà (ma se potete mappate
> quella sera lì) il Tasking Manager rimarrà in piedi sino a domenica sera 20
> dicembre.
>
> 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-it-trentino] R: Mappa Osm

[Dario Zontini]

Ad occhio direi che è OSM ma gli elementi sono pochi e non ho la 
certezza. Lo dico guardando i torrenti, perchè ne ho inseriti alcuni 
settimana scorsa e proprio quelli mancano. Se fosse un'immagine 
realizzata tempo fa si spiega perchè landuse=forest ora non corrisponda.


Da che sito proviene l'immagine?

Dario Zontini




-- Messaggio originale --
Da: "Matteo Dalpas" 
A: "OpenStreetMap Mailing List Trentino" 


Inviato: 14/12/2015 11:27:07
Oggetto: [Talk-it-trentino] R: Mappa Osm


Sulla base del solo landuse=forest direi di no

Da: Michele Malfatti
Inviato: ‎14/‎12/‎2015 08:26
A: OpenStreetMap Mailing List Trentino
Oggetto: [Talk-it-trentino] Mappa Osm

Ciao a tutti secondo voi è una mappa Osm senza attribuzione?
Michele___
Talk-it-trentino mailing list
Talk-it-trentino@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it-trentino

[Talk-br] Fwd: Importação de aeródromos - ANAC

[Thiago Vieira]

Encaminhando as mensagens sobre o assunto da Importação de dados da ANAC
que por engano respondi somente ao Alexandre. 1/2

-- Mensagem encaminhada --
De: Thiago Vieira 
Data: 14 de dezembro de 2015 11:10
Assunto: Re: [Talk-br] Importação de aeródromos - ANAC
Para: Alexandre Magno Brito de Medeiros 


Alexandre,

O Marcio está acompanhando esse assunto. Eu não quis contradizer o que ele
explicou, só disse que por não haver mais uma interdependência (como antes
nos tempos de DAC) entre o órgão militar e a agência do governo, ainda que
possam se aplicar restrições no uso das informações da planilha da ANAC, as
restrições descritas no Rotaer se aplicam àquele próprio documento. Cabe à
ANAC esclarecer as restrições sobre os dados geridos por eles, ainda que
possuam origem militar.

Quanto à nem tudo dever ser mapeado, estamos abordando aqui somente a
questão dos aeródromos e nesse caso eles são mapeados.



Enviei uma mensagem na ANAC através do atendimento eletrônico do Fale com a
ANAC. Espero que eles respondam pois aparentemente o objetivo principal
desse canal é pra receber denúncia sobre problemas com empresas aéreas. As
outras formas de contato são telefone (não cogitei essa opção pois não fica
registro) e carta.

Segue o conteúdo da mensagem que mandei, registrado como manifestação nº
84293-2015:

>>Bom dia,
>>
>>Gostaria de esclarecer uma dúvida quanto à permissão para uso dos dados
de aeródromos disponibilizados no site da ANAC, nos seguintes links:
>>
>>http://www2.anac.gov.br/arquivos/pdf/aerodromos/AerodromosPublicos.xls
>>http://www2.anac.gov.br/arquivos/pdf/aerodromos/aerodromosPrivados.xls
>>
>>Sou colaborador no Projeto OpenStreetMap (http://www.openstreetmap.org/),
que se trata de uma iniciativa colaborativa, sem fins lucrativos e que
envolve todos os países com o objetivo de mapear todo o mundo para
benefício da própria sociedade já que é um mapa com licença livre e que
pode ser usado por todos gratuitamente da forma que bem entenderem, além de
ter a intenção de servir como uma alternativa de qualidade à mapas
proprietários como o Google Maps, Bing Maps, entre outros, que a qualquer
momento sob os interesses de suas empresas proprietárias podem ser
indisponibilizados, desativados ou ter informações manipuladas em seus
mapas.
>>Diversas prefeituras, o IBGE, entre outros órgãos públicos já entenderam
sua importância e autorizaram o uso dos dados por eles gerados para
utilização no OpenStreetMap, e por sua vez muitos também utilizam o
OpenStreetMap como uma camada em seus sistemas geoespaciais.
>>
>>O OpenStreetMap não tem como objetivo ser uma base de cartografia
aeronáutica oficial, porém aeródromos são pontos de interesse e referência
extremamente importantes para serem mapeados. Na verdade a grande maioria,
principalmente dos aeródromos públicos, já constam no mapa, no entanto
muitos não possuem o refinamento de dados conforme consta na planilha de
aeródromos da ANAC. Então nosso interesse seria justamente saber se há
algum tipo de impedimento ou restrição para uso dos dados destas planilhas
dos links referenciados acima (ou equivalentes caso venham a ser
modificadas no futuro) para detalhamento dos aeródromos no OpenStreetMap.
>>
>>Grato,
>>Thiago Peixoto Vieira

Em 12 de dezembro de 2015 23:03, Alexandre Magno Brito de Medeiros <
alexandre@gmail.com> escreveu:

> Thiago,
>
> Peço que você converse com Marcio *aka* thundercel. Ele pode contatar
> pessoas próximas à origem dos dados.
>
> Eu aceito o que Marcio diz estar restrito pelo ROTAER. E, apesar de não
> ser pelas mesmas razões que você apresenta, acredito que os dados que estão
> no DOU e nos arquivos de portarias de www.anac.gov.br (não os de
> pergamum.anac.gov.br ) são o subconjunto que
> pode ser usado. Porém, não tenho certeza se isso está garantido.
>
> Marcio está bem informado sobre o que os militares não querem. Eu acredito
> nele. Além disso, realmente nem tudo deve ser mapeado
>  no OpenStreetMap. Ele ficou
> de conversar com pessoas da aeronáutica.
>
> Você pode encaminhar este e-mail a Marcio, para adiantar conversa. Não
> tenho mais muito o que conversar. Eu e ele pausamos a conversação
> acordando, penso. Ele é muito bem informado. Fale com ele!
>
> Alexandre Magno
>
>
> Em 12 de dezembro de 2015 21:38, Thiago Vieira 
> escreveu:
>
>> Peço desculpa pela ausência no assunto. Após o primeiro questionamento
>> sobre licenças eu criei um cadastro no portal da ANAC pra fazer um
>> questionamento formal mas algum problema no sistema impossibilitou que eu
>> prosseguisse, vou tentar novamente.
>>
>> Quanto às restrições impostas à utilização dos dados do Rotaer entendo
>> que elas não se aplicam aos dados da ANAC já que ela não é subordinada ao
>> comando da aeronáutica, segue a descrição tirada do site:
>>
>>
>>
>> *"A ANAC, vinculada à Secretaria de Aviação Civil 

[Talk-br] Fwd: Importação de aeródromos - ANAC

[Thiago Vieira]

2/2

-- Mensagem encaminhada --
De: Thiago Vieira 
Data: 14 de dezembro de 2015 11:58
Assunto: Re: [Talk-br] Importação de aeródromos - ANAC
Para: Alexandre Magno Brito de Medeiros 


Alexandre,

Sobre os pontos comentados:

1) Não estamos tratando do Rotaer mas da planilha da ANAC;

2) Ok, acabei sendo omisso quanto à informação da licença do OSM, assim que
obtiver uma resposta, se necessário acrescento essa informação já que não
posso editar a mensagem enviada. Minha intenção foi questionar sob qual
forma de licenciamento estão aqueles dados, não foi sugerir formas de
licenciar tais dados, vou aguardar a resposta para eventualmente aprofundar
nessa questão da licença, aí formulamos em conjunto um texto mais adequado
pois não domino bem as peculiaridades sobre as diferentes licenças e suas
compatibilidades. Creio que alguém que vá responder com alguma propriedade
pesquisará o mínimo pra conhecer essas questões. Aguardemos. Os informarei
assim que receber algo.

Em 14 de dezembro de 2015 11:24, Alexandre Magno Brito de Medeiros <
alexandre@gmail.com> escreveu:

> Thiago,
>
> Dois pontos principais você tem negligenciado:
>
> 1) O ROTAER propriamente dito tem, sobre os aeródromos, dados que não
> deveriam ser mapeados.
>
> 2) É importantíssimo mencionar que o OpenStreetMap está sob ODbL
> . Dessa forma, o banco de dados
> do OSM, ou o "nosso mapa", *não* pode ser usado por todos "da forma que
> bem entenderem".
>
> Melhor do que pedir uma permissão particular para uso no OpenStreetMap, é
> pedir que eles licenciem dados publicamente sob uma licença que seja
> compatível com a ODbL. Poderia ser a CC0, como fez recentemente a CGM-SP.
>
> Alexandre Magno
>
> Em 14 de dezembro de 2015 10:10, Thiago Vieira 
> escreveu:
>
>> Alexandre,
>>
>> O Marcio está acompanhando esse assunto. Eu não quis contradizer o que
>> ele explicou, só disse que por não haver mais uma interdependência (como
>> antes nos tempos de DAC) entre o órgão militar e a agência do governo,
>> ainda que possam se aplicar restrições no uso das informações da planilha
>> da ANAC, as restrições descritas no Rotaer se aplicam àquele próprio
>> documento. Cabe à ANAC esclarecer *[...]*
>>
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk] How does one tag a business that closed and was replaced by something else?

[Martijn van Exel]

I usually just either replace the tags of the node with the info for the
new business  (example: http://www.openstreetmap.org/node/1400581558/history) ,
or in your case, the tags of the buildings. Perhaps merge the buildings
also if they are functionally one structure?

On Mon, Dec 14, 2015 at 10:20 AM Andrew Wiseman  wrote:

> Hi,
>
> In this case, two businesses closed and were replaced by a single business
> that took over both buildings (they are adjoining.) How should I tag this?
> I didn't see anything about closed: or former: on the wiki.
>
> Thanks,
>
> Andrew
>
> --
>
> 600,000 DC residents don't have a vote in Congress --
> http://www.dcvote.org/ 
> ___
> 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-it] Estratti regionalidi FMACH

[Martin Koppenhoefer]

2015-12-14 19:06 GMT+01:00 Luca Delucchi :

> Ricompilalo magari c'è stato qualche aggiornamento nelle librerie.



Avevo provato sia con il package che con il bin compilato da me.
veramente strano. Ho scaricato stanotte tutte le 20 regioni in pbf e tutte
mi davano errore (anche in taginfo), adesso riscaricando (con lo stesso
script, dopo averle cancellate prima) funzionano
I files sono grandi uguale ed hanno la stessa data / ora.

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

Re: [Talk-at] Seehöhen

[Friedrich Volkmann]

On 14.12.2015 18:34, grubernd wrote:
> On 2015-12-13 22:14, Friedrich Volkmann wrote:
>> Damit wir nicht den Überblick verlieren, hier die beiden Dinge, für die ich
>> mir von dir ein Beispiel wünschen würde:
>> 1) herumspringende oder dubiose Werte im Laserscan
>> 2) Gipfel, die in der Basemap gerendert werden, aber nicht in der höchsten
>> Zoomstufe
> 
> https://overpass-api.de/achavi/?changeset=35589250
> 
> das ist das Gelände in dem ich mich in letzter Zeit viel virtuell bewegt
> habe, der letzte persönliche Besuch ist schon eine zeitlang her, aber dort
> oben ist das Leben langsam.
> 
> das Changeset ist noch ohne Querreferenz zum Laserscan gemacht, aber ich
> habe auf Grund der Aktualität nach deinem Hinweis dort den Laserscan
> angeschaut. und beim Eintragen hatte ich alle vorher beschriebenen Effekte
> irgendwann.

Ich hab mir jetzt mal den ersten Gipfel des Changesets angeschaut, nämlich
den Rosskogel, und bei dem komme ich mit dem Laserscan auf max. 1400,1 m,
also 2m unter der amtlichen Höhenangabe (1402m). Das spricht auf jeden Fall
dafür, den höchsten Wert zu nehmen, nicht zu mitteln. Die Lage ist 13,752963
/ 47,538108, das ist 7m von deiner Position entfernt, während die Lage in
der Basemap 18m von deiner Position entfernt ist.

Bei diesem Beispiel kann ich weder ein Herumspringen der Werte im Laserscan
noch ein Verschwinden des Gipfels in der höchsten Zoomstufe der Basemap
beobachten.

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

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

Re: [Talk-it] Parrocchiale

[Martin Koppenhoefer]

sent from a phone

> Am 14.12.2015 um 17:25 schrieb Simone Cortesi :
> 
> potrebbe anche essere la sede della diocesi locale?

suggerisco questa pagina: https://it.m.wikipedia.org/wiki/Gerarchia_cattolica


> 
> prova a guardare in questa pagina wiki:
> http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreligious



per me, il tag landuse =religious non ha molto senso, al meno non nel nostro 
contesto, non dice niente più di religion=*
anzi crea problemi che incentiva di non usare il landuse appropriato. Credo che 
religious  è un landuse da mettere quasi solo  a chiese e pertinenze(?), invece 
altri landuse "religiosi" sarebbero residential, commercial etc.

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

Re: [OSM-talk-fr] 2 relations pour le Rhône

[Jérôme Seigneuret]

>
>
>
> Pour le lit, c'est un corps d'eau, et un multipolygone va très bien, qu'il
> y ai des iles ou non.
>
> Oui sauf que c'est inutile surtout pour des entités accolés... D'ailleurs
en multipolygone sous JOSM c'est automatiquement fusionné et dans le cas de
muti-area jointif ça renvois une alerte
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] How does one tag a business that closed and was replaced by something else?

[Mateusz Konieczny]

On Mon, 14 Dec 2015 12:18:41 -0500
Andrew Wiseman  wrote:

> Hi,
> 
> In this case, two businesses closed and were replaced by a single
> business that took over both buildings (they are adjoining.) How
> should I tag this? I didn't see anything about closed: or former: on
> the wiki.
> 
> Thanks,
> 
> Andrew
> 

Just delete it. There is no need for closed: former: etc (for start, it
is not verifiable in a reasonable way).

See https://www.openstreetmap.org/welcome - OSM is not a right place to
map historical data.

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

Re: [Talk-it] Estratti regionalidi FMACH

[Luca Delucchi]

Il 14/dic/2015 05:50 PM, "Martin Koppenhoefer"  ha
scritto:
>
>
> Avete cambiato qualcosa negli ultimi giorni? A voi funziona?
>

Ricompilalo magari c'è stato qualche aggiornamento nelle librerie.

> Ciao,
> Martin
>

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

Re: [OSM-talk-fr] 2 relations pour le Rhône

[Frédéric Rodrigo]

Là les deux ont
type = waterway
water = river
Ce n'est pas possible.
Ça ce n'est que pour le tracé filaire.

Pour le lit, c'est un corps d'eau, et un multipolygone va très bien, 
qu'il y ai des iles ou non.


http://wiki.openstreetmap.org/wiki/Relation:waterway

Frédéric.


Le 14/12/2015 15:40, Tony Emery a écrit :

Jérôme Seigneuret wrote

Dans tous les cas l'emprise des zones d'eau n'est pas incluse dans la
première relation et c'est pas normal donc à voir
http://wiki.openstreetmap.org/wiki/Relation:waterway

Jérôme

Du coup, on peut corriger tout ça ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/2-relations-pour-le-Rhone-tp5862437p5862448.html
Sent from the France mailing list archive at Nabble.com.

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



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

[OSM-talk] Changeset Revert Request

[Steve Doerr]

I spotted this on the Malaysia forum: 
http://forum.openstreetmap.org/viewtopic.php?pid=566307 . Here's the 
extent of the damage: https://overpass-api.de/achavi/?changeset=35942702 .


Can anyone assist?

--
Steve

---
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: [OSM-talk-fr] 2 relations pour le Rhône

[Philippe Verdy]

Sauf que le multipolygone a justement des attributs, partagé par tous ses
membres qui n'en ont pas besoin, et qu'il n'utilise qu'un seul membre à
part dans la relation waterway. Il est d'autant plus utile qu'il n'est pas
complet (il manque en fait des tas de riverbanks ou certains éléments ne
sont pas jointifs aux autres).
Le wiki décrit même cette possibilité au lieu d'ccumuler plein de membres
dans la relation waterway, justement pour les longs fleuves qui ont trop de
membres: les riverbanks peuvent être stockés à part dans leur propre
relation...
Ce n'est pas redondant, ça allège même énormément pour les longs fleuves
(et le Rhône n'est pas le seul dans ce cas...).

Cet
e-mail a été envoyé depuis un ordinateur protégé par Avast.
www.avast.com

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

Le 14 décembre 2015 à 21:15, Jérôme Seigneuret  a
écrit :

>
> Le 14 décembre 2015 à 20:49, JB  a écrit :
>
>> Le 14/12/2015 20:43, Jérôme Seigneuret a écrit :
>>
>>> D'ailleurs en multipolygone sous JOSM c'est automatiquement fusionné
>>>
>> Pardon ? Tu peux préciser, s'il te plait ?
>> JB.
>
>
> Ok j'ai mal présenté la chose...
>
> Soit  un way fermé A, un way fermé B et un way fermé C.
> A et B sont jointifs et C et situé entre les deux et est jointif donc avec
> A et B
>
> Si tu combines A et B les entités sont transformés en une seul faisant
> parti d'un mutipolygone avec le role outer et C est incluse avec le role
> inner directement. Les attributs de A et B sont alors remonté sur la
> relation multipolygone (avec alerte si des clés ou valeurs sont différentes)
>
> Sinon A et B sont juste incluse dans le multipolygone ça émet une alerte
> car il existe des parties jointives
>
> Sinon sans multipolygone, rien n’empêche de mettre A et B dans un autre
> type de relation. type=waterway s'apparente à un dictionnaire de données
> dans lequel on regroupe des objets avec des role specifique
>
> Sans C, A et B peuvent être fusionné et cela n'implique en aucun cas un
> multipolygone.
>
> Si le multipolygone n'apporte pas de précision spécifique c'est qu'il sert
> à rien. C'est juste un groupement d'élément de même nature.
> C'est comme mettre des landuse=residential sans nom dans une relation
> multipolygone. Inutile
>
> ___
> 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-br] Ativação do HOT sobre o colapso da barragem em Mariana

[Gerald Weber]

2015-12-14 20:19 GMT-02:00 Vitor George :

> Pessoal, o Gerald deu um gás e o mapeamento chegou a 100%. Agora é preciso
> revisar o que foi mapeado:
>
> http://tasks.hotosm.org/project/1317
>
>
Eu fechei os últimos lotes, mas devo dizer que eles já estavam quase
completamente mapeados. Minha contribuição aqui foi ínfima.

vamos às validações :D

abraços

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

Re: [Talk-us] SunCertPathBuilderException

[Blake Girardot]

Hi Alan,

Dirk did make a change to server certificates today I think.

It is possible this is related to that change.

If you could please provide your OS version, JOSM version and Java 
version, that would really be helpful.


JOSM -> Help menu -> Show Status Report provides all that info right up 
at the top of the resulting dialog box.


Cheers,
Blake


On 12/14/2015 9:49 PM, Alan Bragg wrote:



At 3pm EST JOSM is refusing to start. I getting this message.
​If I ignore the message I can continue to use JOSM as usual.

-

 JOSM tried to access the following resources:

  * https://josm.openstreetmap.de/maps
  * https://josm.openstreetmap.de/wiki/StartupPage

but *failed* to do so, because of the following network errors:

  * sun.security.provider.certpath.SunCertPathBuilderException: unable
to find valid certification path to requested target

It may be due to a missing proxy configuration.
Would you like to change your proxy settings now?
--




___
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-br] Ativação do HOT sobre o colapso da barragem em Mariana

[Vitor George]

Pessoal, o Gerald deu um gás e o mapeamento chegou a 100%. Agora é preciso
revisar o que foi mapeado:

http://tasks.hotosm.org/project/1317



2015-12-14 10:34 GMT-02:00 andre viana :

> Bom dia!Moro em Mariana,caso possa ajudar em alguma coisa!
>
> Em 11 de dezembro de 2015 00:33, Tarcisio Oliveira 
> escreveu:
>
>> Amanha de manhã eu dou uma ajuda final.
>>
>>
>> Em 10-12-2015 19:53, Gerald Weber escreveu:
>>
>> Que tal a gente concluir o mapeamento?
>>
>> http://tasks.hotosm.org/project/1317
>>
>> abraço
>>
>> Gerald
>>
>> 2015-11-10 19:00 GMT-02:00 Vitor George :
>>
>>> Oi pessoal,
>>>
>>> Vamos começar uma tarefa de mapeamento remoto da região afetada pelo
>>> colapso da barragem em Mariana. O trabalho é uma ativação do Humanitarian
>>> OpenStreetMap Team:
>>>
>>> http://wiki.openstreetmap.org/wiki/2015_Mariana_Dam_Collapse
>>>
>>> A página está em inglês porque não temos um template em português ainda,
>>> quem puder colaborar traduza alguma parte desta página:
>>>
>>> http://wiki.openstreetmap.org/wiki/Template:Pt:Activation
>>>
>>> Em breve vamos ter acesso a imagens pós-desastre. Quem quiser acompanhar
>>> mais de perto, acesso o grupo do Telegram.
>>>
>>> Abraços,
>>> Vitor
>>>
>>> ___
>>> Talk-br mailing list
>>> Talk-br@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-br
>>>
>>>
>>
>>
>>
>> ___
>> Talk-br mailing 
>> listTalk-br@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-br
>>
>>
>>
>> ___
>> 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 mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [OSM-talk] Nominatim weakness

[Neil Pilgrim]

Would it not simply be sufficient to list viewport results at the top, ie
having a 'local' and 'global' list? Possibly in a small 'tree' view, in the
sense of being able to hide 'local' and 'global' matches separately? (eg
little triangles rotating to indicate if they're shown)

Selecting other things seems to be a matter of knowing the search phrases,
enhancing them, or how easily they can be found/taught, and really is a
distinct problem IMO.

--
Neil


On Monday, 14 December 2015, Jorge Gustavo Rocha  wrote:

> Hi,
>
> I think that we can add an option to bound the results to the current
> viewport. That option would be passed to nominatim or any other search
> engine.
>
> Personally, I would prefer the search bounded by default, but users could
> change it to "everywhere" to see additional results.
>
> Regards,
>
> J. Gustavo
>
> Às 11:17 de 14-12-2015, Martin Koppenhoefer escreveu:
>
>>
>> 2015-12-14 10:04 GMT+01:00 Sarah Hoffmann > >:
>>
>> If you type in 'Starbucks' in the search box, then you just get
>> objects named that way. No difference with searching for, say Berlin.
>>
>> Now, if you type 'cafes' in the search box, then you are probably
>> looking for all amenity=cafe and that is a POI search. It's true
>> that this particular query doesn't work on osm.org .
>> You have to
>> additionally specify a place, e.g. 'cafes in Poughkeepsie' actually
>> returns the one Starbucks in town.
>>
>>
>>
>> if I search for
>> "Starbucks in Holland" I get not hit, neither for
>> "Starbucks in the Netherlands"
>> "Starbucks in Netherlands"
>> "Starbucks in Amsterdam"
>>
>> but "starbucks, Netherlands" yields a lot of results (there's even a
>> restaurant among them). Btw., also "starbucks, Holland" leads to a lot
>> of results (not sure if they are the sama, they are in different sorting
>> order at least). You can even omit the comma, but you shouldn't add an
>> "in" because this will lead to no results.
>>
>> 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