Re: [Talk-it] Idranti

[Andreas Lattmann]

>Segnalo comunque che il diametro >punzonato sull'idrante (esempio DN80) è >il 
>diametro della condotta sotterranea >che alimenta l'idrante (quindi va nel tag 
>>fire_hydrant:diameter=80) e non è il >diametro degli attacchi esterni.

Bravo! 
Aggiungo che in teoria la dimensione minima dovrebbe essere DN80 ma spesso si 
trovano ancora i DN50... 
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-be] 90->70 in Vlaanderen

[Marc Gemis]

2017-06-15 16:59 GMT+02:00 Guy Vanvuchelen :

> Misschien een domme vraag. Gaat het om ‘hoe het moet’ of ‘hoe het is’.  Ik
> bedoel hiermee dat er waarschijnlijk richtlijnen zijn die aangeven hoeveel
> de snelheid op de wegen moet zijn maar anderzijds ben ik nog nergens
> gekomen waar er verkeersborden weg genomen zijn.  Op één plaats merk ik dat
> een bord met “70/uur doorstreept’ 90° gedraaid is. Vroeger mocht je dan
> vandaar af 90° uur rijden, nu nog 70. In de andere richting staat een bord
> 90km/uur en mag je dus nu nog 90/uur rijden, ook al is dat een gewone
> tweevaks weg.  Hoe ik dit  zou moeten mappen weet ik niet.  Ik vrees dat
> het nog jaren zal duren voor die onduidelijkheid weg is.  Dus vandaar de
> vraag: welke instructies volgt OSM.
>
>
>

dan moet je met maxspeed:forward en maxspeed:backward werken.
Forward/backward worden bepaald door de richting van de OSM-weg.
In zo'n geval zou ik source:maxspeed niet vermelden.

Ik betwijfel wel of er veel apps zijn die er iets mee aanvangen.

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

Re: [Talk-GB] Mapping archaeology in towns

[Dave F]

From a quick check it appears she's also added them to OpenHistoricalMap
http://www.openhistoricalmap.org/user/Syvanne%20Aloni/history#map=10/51.5232/-2.1934=H
I'll wait a day or so, to see if she adds any more, then I'll revert her 
changesets from OSM.


DaveF



On 15/06/2017 11:52, Andy Townsend wrote:

On 15/06/2017 11:24, Derick Rethans wrote:

On Thu, 15 Jun 2017, Neil Matthews wrote:


...

Maybe other large historic towns have good solutions; Londinium, 
Eboracum?

I've always understood that OpenStreetMap maps what is *currently*
there. Visible, and verifyable.
That's pretty much the case in York - for example if you zoom out from 
http://www.openstreetmap.org/way/145367452 (a corner of the old Roman 
wall) you can see that only the still-existing part of that wall is 
mapped (this is separate to the new medieaval wall which is mostly 
still complete and mapped separately to the west).

Things that used to be there (dismantled railways, no longer visible old
forts and castles, etc.), should not be on OSM. OHM is the place for
that.


That's certainly where I've added stuff in the past - unfortunately a 
server crash meant that everything that I added to OHM was lost. The 
server's back now, so second time lucky I guess...


Depending on what the original mapper was trying to do, OHM might not 
be the best option - if they're trying to create a map highlighting 
historic sites then some sort of GIS package (or even JOSM) might be a 
better idea.


Best Regards,

Andy



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



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

Re: [Talk-es] Tresmiles del Pirineo

[Uranzu]

O sea, que han hecho una chapucilla (siendo benévolo). Igual llega un nuevo
Gobierno y nos vuelve a cambiar los nombres... Yo no tocaría nada hasta que
se aclare el tema y haya consenso.

Un saludo



--
View this message in context: 
http://gis.19327.n8.nabble.com/Tresmiles-del-Pirineo-tp5897892p5898008.html
Sent from the Spain mailing list archive at Nabble.com.

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

Re: [Talk-es] Propuesta de Importación de Catastro: Municipios en las direcciones

[Rafael Avila Coya]

Yo me inclinaría por no incluírlo, habida cuenta que el municipio el que 
está una dirección se puede derivar de la relación del propio municipio 
(fronteras). Caso de incluirlo, yo me decantaría por addr:municipality, 
que yo mismo he usado en otros países...


Saludos,

On 15/06/17 10:41, Javier Sánchez Portero wrote:

Se agradecen opiniones respecto a

https://wiki.openstreetmap.org/wiki/ES_talk:Catastro_espa%C3%B1ol/Importaci%C3%B3n_de_edificios/Conversi%C3%B3n_de_datos#.C2.BFQu.C3.A9_hacer_con_los_municipios.3F



___
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-es] Propuesta de Importación de Catastro: Municipios en las direcciones

[Javier Sánchez Portero]

¿Qué precisión tenía la fuente? Yo he tenido que corregir, hace tiempo, los
límites de algunos que estaban mal. No estaría de más dar un repaso y ver
que diferencias se encuentran.

El 15 jun. 2017 17:14, "David Marín Carreño"  escribió:

> Los municipios ya se importaron en su día con una buena calidad por lo
> que, salvo error u omisión, no deberían tocarse.
>
> No reinventemos la rueda ;-)
>
>
> El jue., 15 jun. 2017 a las 13:31, Javier Sánchez Portero (<
> javiers...@gmail.com>) escribió:
>
>> El 15 de junio de 2017, 11:34, dcapillae  escribió:
>>
>>> Me parece bien prescindir de ese dato si su procesamiento genera
>>> demasiadas
>>> dificultades. Definiendo bien los límites de los municipios, no hace
>>> falta
>>> replicar la información con "is_in". Y si un municipio no cuenta con sus
>>> límites bien mapeados, lo que debemos hacer es procurar mapearlos antes
>>> de
>>> añadir cualquier dirección que corresponda a ese municipio.
>>>
>>
>> La información del conjunto de datos de zonas catastrales (opción -z,
>> fichero rustic_zoning.geojson) se puede usar para obtener el límite del
>> municipio.
>> ___
>> 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-es] Propuesta de Importación de Catastro: Municipios en las direcciones

[David Marín Carreño]

Los municipios ya se importaron en su día con una buena calidad por lo que,
salvo error u omisión, no deberían tocarse.

No reinventemos la rueda ;-)


El jue., 15 jun. 2017 a las 13:31, Javier Sánchez Portero (<
javiers...@gmail.com>) escribió:

> El 15 de junio de 2017, 11:34, dcapillae  escribió:
>
>> Me parece bien prescindir de ese dato si su procesamiento genera
>> demasiadas
>> dificultades. Definiendo bien los límites de los municipios, no hace falta
>> replicar la información con "is_in". Y si un municipio no cuenta con sus
>> límites bien mapeados, lo que debemos hacer es procurar mapearlos antes de
>> añadir cualquier dirección que corresponda a ese municipio.
>>
>
> La información del conjunto de datos de zonas catastrales (opción -z,
> fichero rustic_zoning.geojson) se puede usar para obtener el límite del
> municipio.
> ___
> 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-fr] Test rendu carte

[JB]

Bonjour,
Pour conclure sur la carte de Samoëns, voici une version finale ici : 
http://randocarto.fr/demo/Samoens_A1_400dpi.png. Quelques bidouilles en 
plus (et un bug en moins) de la version 7. Florian a déjà partagé 
l'édition Bambiche.
À Avignon, j'ai rapidement présenté la démarche, la présentation est 
disponible ici : 
https://nextcloud.openstreetmap.fr/index.php/s/TpM5DnYe9C5mCWV/download?path=%2F=SotMFR2017_JB_Carte_Papier.pdf. 
Depuis, la partie suggérée en conclusion a été codée, elle est là : 
https://github.com/JBacc1/compare_osm. Christian avait proposé une autre 
évolution, celle-là n'est pas encore codée mais ça viendra surement. Je 
la testerai probablement sur une autre zone test… peut-être dans les 
Vosges ?

Voilà voilà,
Merci encore pour tous vos retours, merci à Romuald71 pour ses 
contributions dans la zone.

JB.

Le 06/06/2017 à 11:57, Florian LAINEZ a écrit :
Merci JB pour la version Bambiche ! Dispo en plusieurs résolutions à 
l'adresse http://panneauxbiche.com/Samoens/
SotM c'est quand même top pour avancer sur les vrais sujets qui 
comptent ;)



Le 24 avril 2017 à 23:26, > a écrit :


Le 07/04/2017 à 05:40, JB - jb...@mailoo.org
 a écrit :


Le 3 avril 2017 à 21:44, Philippe Verdy > a écrit :

Joli, mais peut-être que la mention en rouge de "Chap." pour
chapelle est redondante avec le symbole déjà affiché pour
une chapelle, et n'apporte rien de plus (pas de nom consacré
de chapelle)

+1

Autant, sur d'autres éléments, je valide, autant, vu l'importance
touristique mise sur les chapelles dans le coin, j'avais plutôt
envie de les mettre vraiment en avant.

C'est avec un beau picto et non avec un hideux Chap. que tu les
mettras en avant.
À quoi ça sert de faire une si belle carte ?


Autres détails :

-Les ruisseaux sont bien mieux rendus : super


Je maintiens qu'un fil de contour (plus fin que celui des routes)
bleu foncé vaudrait le coup d'être essayé.

Cols : plutôt que de mettre un chiffre entre parenthèses, ajouter
un espace insécable puis m après ce chiffre. Plus léger et plus
explicite.

Quand les derniers picto seront en vectoriel, ce sera vraiment une
très belle carte.

Jean-Yvon

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

Re: [Talk-it] Idranti

[Andreas Lattmann]

>Ciao, molto bene. Per me è persino più >importante il diametro degli attacchi

Condivido. È più importante conoscere gli attacchi che il diametro della 
tubazione. Eee domanda, ma in quanti sanno come prendere il diametro della 
tubazione? I casi sono due: uno lo sa, guarda l' idrante e segna il diametro 
scritto sotto DN oppure scava e prende il diametro! :-D
Ciao ragazzi. :-)
-- 
Inviato dal mio dispositivo Android con K-9 Mail. Perdonate la brevità.___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk-be] 90->70 in Vlaanderen

[Guy Vanvuchelen]

Misschien een domme vraag. Gaat het om ‘hoe het moet’ of ‘hoe het is’.  Ik 
bedoel hiermee dat er waarschijnlijk richtlijnen zijn die aangeven hoeveel de 
snelheid op de wegen moet zijn maar anderzijds ben ik nog nergens gekomen waar 
er verkeersborden weg genomen zijn.  Op één plaats merk ik dat een bord met 
“70/uur doorstreept’ 90° gedraaid is. Vroeger mocht je dan vandaar af 90° uur 
rijden, nu nog 70. In de andere richting staat een bord 90km/uur en mag je dus 
nu nog 90/uur rijden, ook al is dat een gewone tweevaks weg.  Hoe ik dit  zou 
moeten mappen weet ik niet.  Ik vrees dat het nog jaren zal duren voor die 
onduidelijkheid weg is.  Dus vandaar de vraag: welke instructies volgt OSM.



Guy Vanvuchelen



Van: Brecht Van Maldergem [mailto:brecht.van.malder...@be-mobile.com]
Verzonden: donderdag 15 juni 2017 15:55
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] 90->70 in Vlaanderen



Heren,


Bij deze concreet plan van aanpak even schetsen, om de situatie recht te zetten;

Wat ik nu op korte termijn kan doen;

*   90-90: Filteren waar 90 gebleven is, en hiervoor vragen om de 
aanpassingen terug te draaien.
*   70-50: Filteren waar 70 naar 50 gegaan is, en deze verifiëren in 
hoeverre dit gecorrigeerd geweest is, en -al dan niet- terugdraaien waar nodig.

Uitgangspunt is dan dat enkel indien er geen recentere edits geweest zijn, de 
maxspeed teruggezet wordt, zoniet gaan we er van uit dat de recentste edit de 
correcte is.

Dat zou volgens mij al een groot stuk van de problemen moeten verhelpen.

Mvg,

Brecht





Van: joost schouppe []
Verzonden: donderdag 1 juni 2017 18:46
Aan: Brecht Van Maldergem ; OpenStreetMap 
Belgium 
CC: Ben Abelshausen 
Onderwerp: Re: [OSM-talk-be] 90->70 in Vlaanderen



Nou, het ziet ernaar uit dat ik de fout heb gevonden. In de shapefile zitten 
nieuwe en oude snelheden. Soms is de nieuwe snelheid ongewijzigd 90 gebleven. 
Dit kaartje toont al die segmenten:



http://i.imgur.com/vbx6q6f.jpg





De WMS die aan de mapper is gegeven bevat alle segmenten die in de shapefile 
zitten, ook degene die ongewijzigd op 90 bleven. De baan van Temse naar 
Willebroek was ons schuldig voorbeeld. De ringweg in Geel is op dezelfde manier 
fout gecorrigeerd.



Er zaten ook segmenten in de WMS die in de shapefile van 70 naar 50 gaan, maar 
daar schijnt niets mee gebeurd te zijn.



Om helemaal zeker te zijn dat enkel de wegen in de screenshot verkeerd 
gecorrigeerd zijn, zou het natuurlijk fijn zijn om de data achter de wms te 
krijgen (die werkt niet goed met leaflet nog qgis, en heeft geen legende), én 
om de instructies die de mapper kreeg te weten.



Ik kan een maproulette taakje maken op basis van de query op de shapefile, maar 
ik denk dat het op basis van die screenshot al vrij gemakkelijk is om even 
alles te controleren. Anderzijds is er duidelijk nog een en ander van info in 
die shapefile die nog niét in OpenStreetMap gecorrigeerd is, dus misschien wel 
de moeite om verder te gebruiken.



---
This email has been checked for viruses by AVG.
http://www.avg.com
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] 90->70 in Vlaanderen

[Brecht Van Maldergem]

Heren,

Bij deze concreet plan van aanpak even schetsen, om de situatie recht te zetten;
Wat ik nu op korte termijn kan doen;

  *   90-90: Filteren waar 90 gebleven is, en hiervoor vragen om de 
aanpassingen terug te draaien.
  *   70-50: Filteren waar 70 naar 50 gegaan is, en deze verifiëren in hoeverre 
dit gecorrigeerd geweest is, en -al dan niet- terugdraaien waar nodig.
Uitgangspunt is dan dat enkel indien er geen recentere edits geweest zijn, de 
maxspeed teruggezet wordt, zoniet gaan we er van uit dat de recentste edit de 
correcte is.
Dat zou volgens mij al een groot stuk van de problemen moeten verhelpen.
Mvg,
Brecht


Van: joost schouppe [mailto:joost.schou...@gmail.com]
Verzonden: donderdag 1 juni 2017 18:46
Aan: Brecht Van Maldergem ; OpenStreetMap 
Belgium 
CC: Ben Abelshausen 
Onderwerp: Re: [OSM-talk-be] 90->70 in Vlaanderen

Nou, het ziet ernaar uit dat ik de fout heb gevonden. In de shapefile zitten 
nieuwe en oude snelheden. Soms is de nieuwe snelheid ongewijzigd 90 gebleven. 
Dit kaartje toont al die segmenten:

http://i.imgur.com/vbx6q6f.jpg


De WMS die aan de mapper is gegeven bevat alle segmenten die in de shapefile 
zitten, ook degene die ongewijzigd op 90 bleven. De baan van Temse naar 
Willebroek was ons schuldig voorbeeld. De ringweg in Geel is op dezelfde manier 
fout gecorrigeerd.

Er zaten ook segmenten in de WMS die in de shapefile van 70 naar 50 gaan, maar 
daar schijnt niets mee gebeurd te zijn.

Om helemaal zeker te zijn dat enkel de wegen in de screenshot verkeerd 
gecorrigeerd zijn, zou het natuurlijk fijn zijn om de data achter de wms te 
krijgen (die werkt niet goed met leaflet nog qgis, en heeft geen legende), én 
om de instructies die de mapper kreeg te weten.

Ik kan een maproulette taakje maken op basis van de query op de shapefile, maar 
ik denk dat het op basis van die screenshot al vrij gemakkelijk is om even 
alles te controleren. Anderzijds is er duidelijk nog een en ander van info in 
die shapefile die nog niét in OpenStreetMap gecorrigeerd is, dus misschien wel 
de moeite om verder te gebruiken.
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-cz] WeeklyOSM CZ 358

[Marián Kyral]

-- Původní e-mail --
Od: Pavel Machek 
Komu: OpenStreetMap Czech Republic 
Datum: 15. 6. 2017 14:28:40
Předmět: Re: [Talk-cz] WeeklyOSM CZ 358
"On Tue 2017-06-13 07:42:37, Tom Ka wrote:
> Ahoj, je dostupné vydání 358 týdeníku WeeklyOSM:
>
> http://www.weeklyosm.eu/cz/archives/9118
>
> * Prušánky revival!
> * Pontonový most jako hraniční přechod.
> * OSM Note číslo 1 milion.
> * Emoji ve jménu tagů.

Ve jmenu tagu? Ja tam vidim emoji v hodnote.

name=Hospoda u sileneho emotikonu :-)

je jeste prijatelne, ale

vyska;-)=10m

mi moc rozume neprijde :-(.
Pavel
"



Tak v originále je: "finally emojis can be used in name tags :-)", takže to
asi bude spíše v hodnotě tagů "name=*". Opravím.




Nicméně osobně mi to přijde jako naprostá hovadina i v tom jménu.








Marián



"

--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/
blog.html
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
"___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] WeeklyOSM CZ 358

[Tom Ka]

Jo, blbej preklad, opravim. Diky za report.

Bye

Dne 15. června 2017 14:26 Pavel Machek  napsal(a):
> On Tue 2017-06-13 07:42:37, Tom Ka wrote:
>> Ahoj, je dostupné vydání 358 týdeníku WeeklyOSM:
>>
>> http://www.weeklyosm.eu/cz/archives/9118
>>
>> * Prušánky revival!
>> * Pontonový most jako hraniční přechod.
>> * OSM Note číslo 1 milion.
>> * Emoji ve jménu tagů.
>
> Ve jmenu tagu? Ja tam vidim emoji v hodnote.
>
> name=Hospoda u sileneho emotikonu :-)
>
> je jeste prijatelne, ale
>
> vyska;-)=10m
>
> mi moc rozume neprijde :-(.
> Pavel
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>

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

Re: [Talk-cz] WeeklyOSM CZ 358

[Pavel Machek]

On Tue 2017-06-13 07:42:37, Tom Ka wrote:
> Ahoj, je dostupné vydání 358 týdeníku WeeklyOSM:
> 
> http://www.weeklyosm.eu/cz/archives/9118
> 
> * Prušánky revival!
> * Pontonový most jako hraniční přechod.
> * OSM Note číslo 1 milion.
> * Emoji ve jménu tagů.

Ve jmenu tagu? Ja tam vidim emoji v hodnote.

name=Hospoda u sileneho emotikonu :-)

je jeste prijatelne, ale

vyska;-)=10m

mi moc rozume neprijde :-(.
Pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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

Wochennotiz Nr. 360 06.06.2017–12.06.2017

[Wochennotizteam]

Hallo,

die Wochennotiz Nr. 360 mit vielen wichtigen Neuigkeiten aus der 
OpenStreetMap-Welt ist da:

http://blog.openstreetmap.de/blog/2017/06/wochennotiz-nr-360/

Viel Spaß beim Lesen!
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Nutzung von building:part durch Mentz GmbH

[Tobias Knerr]

Hallo zusammen,

mir ist aufgefallen, dass Mentz beim Bahnhofsmapping eine inkompatible
Interpretation des Schlüssels building:part gewählt hat. Dieser kommt
bei Mentz für Indoor-Elemente wie Aufzüge, die nicht unbedingt einen
Einfluss auf die äußere Form eines Gebäudes haben, oder auch für
Tunnel[1] zum Einsatz. Auch Stockwerke werden in der Mentz-eigenen
Dokumentation[2] als Einsatzmöglichkeit erwähnt.

Das widerspricht allerdings klar der etablierten Bedeutung dieses
Schlüssels, der ja aus Simple 3D Buildings stammt. Um den bestehenden
Standard nicht zu gefährden, sollte hier ein anderes Tagging gefunden
werden. Daher würde ich hoffen, dass Mentz bereit ist, eine andere
Lösung zu wählen und ihre eingetragenen Daten entsprechend zu korrigieren.

Ich hatte das bereits vor zwei Wochen im Wiki angesprochen, aber keine
Reaktion erhalten:
http://wiki.openstreetmap.org/wiki/Talk:MENTZ_GmbH/Modellierungsvorschl%C3%A4ge_Indoor#Problematische_Nutzung_von_building:part

Gruß,
Tobias

[1] Beispiel: http://www.openstreetmap.org/relation/7103998
[2] http://wiki.osm.org/DE:MENTZ_GmbH/Modellierungsvorschläge_Indoor



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

Re: [Talk-es] Propuesta de Importación de Catastro: Municipios en las direcciones

[Javier Sánchez Portero]

El 15 de junio de 2017, 11:34, dcapillae  escribió:

> Me parece bien prescindir de ese dato si su procesamiento genera demasiadas
> dificultades. Definiendo bien los límites de los municipios, no hace falta
> replicar la información con "is_in". Y si un municipio no cuenta con sus
> límites bien mapeados, lo que debemos hacer es procurar mapearlos antes de
> añadir cualquier dirección que corresponda a ese municipio.
>

La información del conjunto de datos de zonas catastrales (opción -z,
fichero rustic_zoning.geojson) se puede usar para obtener el límite del
municipio.
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Propuesta de Importación de Catastro (¡¡¡¡NO SE PUEDE SUBIR NADA !!!).

[Javier Sánchez Portero]

El 15 de junio de 2017, 11:22, Alejandro S. 
escribió:

>
> Respondiendo a Matías, hablo de la etiqueta building:min_level[0] no de la
> etiqueta building_levels. Y entiendo de [2] que no está reflejada.
>
> Según entiendo de esa definición se está usando el modelo "ISNPIRE 2D
> extended BU" pero en la página que indican[1] en la web de del catastro no
> aparece referenciado ese modelo "extended", ya empezamos mal...
>
>
> [0]: https://wiki.openstreetmap.org/wiki/Key:building:min_level
> [1]: http://inspire.ec.europa.eu/schemas/
> [2]: http://www.catastro.minhap.gob.es/webinspire/documentos/Conj
> untos%20de%20datos.pdf
>

Tienes razón. Sólo tenemos la información de building:levels y
building:levels:underground, pero falta building:min_level. Esto afecta
principalmente a los balcones, que están 'plantados' a nivel del suelo.
Tampoco tenemos una información que nos distinga los balcones y permita
hacer algo con ellos (eliminarlos, por ejemplo). La única solución que veo
en este momento es que como en cualquier caso hay que revisar edificio por
edificio para comprobar errores de Catastro que pueden ocurrir
(principalmente edificios mal situados o que no existen), esa podría ser
una cuestión más a revisar.


> http://datos.gob.es/sites/default/files/manual_descriptivo_shapefile.pdf
>
>
>> Entiendo que para los polígonos adyacentes se esta optando por la
>> solución de usar áreas adyacentes que comparten los nodos. ¿Es esta la
>> estructura de datos que queremos utilizar?
>>
>
> No entiendo muy bien a que te refieres
>

A la hora de reflejar polígonos adyacentes, se puede utilizar áreas que
comparten los nodos (sistema que usa el programa ahora) o multipolígonos
que compartan las vías que separan unas áreas de otras, aquí puedes ver un
ejemplo[3]

[3]: http://www.openstreetmap.org/#map=19/41.64392/-0.88465

Ah vale. Yo voto por la opción actual, compartir nodos y repetir segmentos.
Lo de dibujar segmentos únicos y emplear múltiples relaciones me atrajo
hace años pero creo que es mucho más difícil de comprender y mantener.
Cuando quieres hacer un cambio es un follón y es muy fácil que se roma si
le mete mano un "newby". Creo que generaríamos demasiadas relaciones y
tendríamos rechazo en la lista imports.
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-GB] Mapping archaeology in towns

[Andy Townsend]

On 15/06/2017 11:24, Derick Rethans wrote:

On Thu, 15 Jun 2017, Neil Matthews wrote:


...

Maybe other large historic towns have good solutions; Londinium, Eboracum?

I've always understood that OpenStreetMap maps what is *currently*
there. Visible, and verifyable.
That's pretty much the case in York - for example if you zoom out from 
http://www.openstreetmap.org/way/145367452 (a corner of the old Roman 
wall) you can see that only the still-existing part of that wall is 
mapped (this is separate to the new medieaval wall which is mostly still 
complete and mapped separately to the west).

Things that used to be there (dismantled railways, no longer visible old
forts and castles, etc.), should not be on OSM. OHM is the place for
that.


That's certainly where I've added stuff in the past - unfortunately a 
server crash meant that everything that I added to OHM was lost. The 
server's back now, so second time lucky I guess...


Depending on what the original mapper was trying to do, OHM might not be 
the best option - if they're trying to create a map highlighting 
historic sites then some sort of GIS package (or even JOSM) might be a 
better idea.


Best Regards,

Andy



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

Re: [Talk-es] Propuesta de Importación de Catastro: Municipios en las direcciones

[dcapillae]

Me parece bien prescindir de ese dato si su procesamiento genera demasiadas
dificultades. Definiendo bien los límites de los municipios, no hace falta
replicar la información con "is_in". Y si un municipio no cuenta con sus
límites bien mapeados, lo que debemos hacer es procurar mapearlos antes de
añadir cualquier dirección que corresponda a ese municipio.



-
Daniel Capilla
OSM user: dcapillae 
--
View this message in context: 
http://gis.19327.n8.nabble.com/Propuesta-de-Importacion-de-Catastro-Municipios-en-las-direcciones-tp5897989p5897995.html
Sent from the Spain mailing list archive at Nabble.com.

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

Re: [Talk-GB] Mapping archaeology in towns

[Derick Rethans]

On Thu, 15 Jun 2017, Neil Matthews wrote:

> I've recently noticed a lot of "historic" edits in Bath by user SNLA
> (https://www.openstreetmap.org/user/SNLA).
> 
> There's been some discussion on the changeset
> https://www.openstreetmap.org/changeset/49401905
> 
> What's the prevailing thought process on mapping mostly obliterated
> historic buildings - abuse the layer tag to push them underground,
> restrict them to OHM rather than OSM, or just delete them. One problem
> seems to be they are joining other contemporary features and modifying
> them when rectifying ruined buildings, etc. I always find Bath "a bit
> fiddly" so it's not surprising. The other issue would be where
> underlying data is from, in terms of copyright.
> 
> Maybe other large historic towns have good solutions; Londinium, Eboracum?

I've always understood that OpenStreetMap maps what is *currently* 
there. Visible, and verifyable.

Things that used to be there (dismantled railways, no longer visible old 
forts and castles, etc.), should not be on OSM. OHM is the place for 
that.

cheers,
Derick

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

Re: [Talk-es] Propuesta de Importación de Catastro (¡¡¡¡NO SE PUEDE SUBIR NADA !!!).

[Alejandro S.]

Atentamente,
  Alejandro Suárez

2017-06-15 10:37 GMT+02:00 Javier Sánchez Portero :

> Hola.
>
> Contesto entre lineas
>
> El 14 de junio de 2017, 13:58, Alejandro S. 
> escribió:
>
>> ¿El Atom tiene tanta información como la base de datos del Catastro en su
>> formato shp? ¿Está reflejada en el Atom la información correspondiente a
>> building:min_level? Si no es así, ¿queremos importar esta información
>> parcial en lugar de la general? ¿podemos combinar información de ambos
>> repositorios para quedarnos con lo mejor de cada uno?
>>
>
> La información del servicio Atom no es tan detallada como la de los
> shapefiles pero casi. Creo que es más que suficiente. Falta si el edificio
> está en construcción, la definición de algunas partes como escaleras o
> balcones, pero la forma de los edificios y el número de pisos es igual.
>
> http://www.catastro.minhap.gob.es/webinspire/documentos/
> Conjuntos%20de%20datos.pdf
>

Respondiendo a Matías, hablo de la etiqueta building:min_level[0] no de la
etiqueta building_levels. Y entiendo de [2] que no está reflejada.

Según entiendo de esa definición se está usando el modelo "ISNPIRE 2D
extended BU" pero en la página que indican[1] en la web de del catastro no
aparece referenciado ese modelo "extended", ya empezamos mal...


[0]: https://wiki.openstreetmap.org/wiki/Key:building:min_level
[1]: http://inspire.ec.europa.eu/schemas/
[2]: http://www.catastro.minhap.gob.es/webinspire/documentos/
Conjuntos%20de%20datos.pdf



> http://datos.gob.es/sites/default/files/manual_descriptivo_shapefile.pdf
>
>
>> Entiendo que para los polígonos adyacentes se esta optando por la
>> solución de usar áreas adyacentes que comparten los nodos. ¿Es esta la
>> estructura de datos que queremos utilizar?
>>
>
> No entiendo muy bien a que te refieres
>

A la hora de reflejar polígonos adyacentes, se puede utilizar áreas que
comparten los nodos (sistema que usa el programa ahora) o multipolígonos
que compartan las vías que separan unas áreas de otras, aquí puedes ver un
ejemplo[3]

[3]: http://www.openstreetmap.org/#map=19/41.64392/-0.88465


>
>
>>
>> ¿Se está comprobando que no se generan nodos superpuestos en geometrías
>> adyacentes?
>>
>>
> Cuando se genera el archivo OSM, los nodos que tienen las mismas
> coordenadas se introducen una sola vez, con una referencia única. Las
> distintas vías 'padres' del nodo usan la misma referencia. Aun así todavía
> salen algunos nodos duplicados (pocos) al validar en JOSM en municipios con
> mucha información (pendiente de revisar).
>
> Más información sobre temas parecidos en
> https://wiki.openstreetmap.org/wiki/ES:Catastro_espa%C3%
> B1ol/Importaci%C3%B3n_de_edificios/Conversi%C3%B3n_de_datos/Programa
>
>
Genial que se haya tenido en cuenta, muy buen labor de documentación, solo
hay que ser conscientes de que este programa va a procesar grandes
conjuntos de datos y tiene que ser mínimamente eficiente, que no pase como
con cat2osm...


> El 15 de junio de 2017, 7:49, Matías h 
> escribió:
>
>>
>>- En el archivo correspondiente a las direcciones, el código postal
>>aparece como 6900 cuando en realidad es 06900.
>>
>> Corregido en la última versión.
>
>>
>>- addr:street = CL SANTIAGO y addr:city = LLERENA. Aparecen en
>>mayúsuculas.
>>
>>


> Lo de los municipios es una cuestión abierta y para la que se piden
> opiniones, voy a abrir un hilo para tratarlo.
>
> Lo de corregir los nombres de las calles (que vienen en mayúsculas y con
> varios errores) es una cuestión que estoy trabajando para definir e
> implementar. Se agraden colaboradores, especialmente para Catalán,
> Gallego... y otros.
>

Con el tema de las direcciones hay que tener cuidado, ya que ha sitios
donde ya hay mucha información de ese tipo introducida o importada y hay
que dar facilidad a la conflación de los datos existentes.

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

[Talk-es] Propuesta de Importación de Catastro: Municipios en las direcciones

[Javier Sánchez Portero]

Se agradecen opiniones respecto a

https://wiki.openstreetmap.org/wiki/ES_talk:Catastro_espa%C3%B1ol/Importaci%C3%B3n_de_edificios/Conversi%C3%B3n_de_datos#.C2.BFQu.C3.A9_hacer_con_los_municipios.3F
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-es] Propuesta de Importación de Catastro (¡¡¡¡NO SE PUEDE SUBIR NADA !!!).

[Javier Sánchez Portero]

Hola.

Contesto entre lineas

El 14 de junio de 2017, 13:58, Alejandro S. 
escribió:

> ¿El Atom tiene tanta información como la base de datos del Catastro en su
> formato shp? ¿Está reflejada en el Atom la información correspondiente a
> building:min_level? Si no es así, ¿queremos importar esta información
> parcial en lugar de la general? ¿podemos combinar información de ambos
> repositorios para quedarnos con lo mejor de cada uno?
>

La información del servicio Atom no es tan detallada como la de los
shapefiles pero casi. Creo que es más que suficiente. Falta si el edificio
está en construcción, la definición de algunas partes como escaleras o
balcones, pero la forma de los edificios y el número de pisos es igual.

http://www.catastro.minhap.gob.es/webinspire/documentos/Conjuntos%20de%20datos.pdf
http://datos.gob.es/sites/default/files/manual_descriptivo_shapefile.pdf


> Entiendo que para los polígonos adyacentes se esta optando por la solución
> de usar áreas adyacentes que comparten los nodos. ¿Es esta la estructura de
> datos que queremos utilizar?
>

No entiendo muy bien a que te refieres


>
> ¿Se está comprobando que no se generan nodos superpuestos en geometrías
> adyacentes?
>
>
Cuando se genera el archivo OSM, los nodos que tienen las mismas
coordenadas se introducen una sola vez, con una referencia única. Las
distintas vías 'padres' del nodo usan la misma referencia. Aun así todavía
salen algunos nodos duplicados (pocos) al validar en JOSM en municipios con
mucha información (pendiente de revisar).

Más información sobre temas parecidos en
https://wiki.openstreetmap.org/wiki/ES:Catastro_espa%C3%B1ol/Importaci%C3%B3n_de_edificios/Conversi%C3%B3n_de_datos/Programa

El 15 de junio de 2017, 7:49, Matías h  escribió:

>
>- En el archivo correspondiente a las direcciones, el código postal
>aparece como 6900 cuando en realidad es 06900.
>
> Corregido en la última versión.

>
>- addr:street = CL SANTIAGO y addr:city = LLERENA. Aparecen en
>mayúsuculas.
>
> Lo de los municipios es una cuestión abierta y para la que se piden
opiniones, voy a abrir un hilo para tratarlo.

Lo de corregir los nombres de las calles (que vienen en mayúsculas y con
varios errores) es una cuestión que estoy trabajando para definir e
implementar. Se agraden colaboradores, especialmente para Catalán,
Gallego... y otros.
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [OSM-talk-fr] Carte des groupes locaux

[Julien Lepiller]

Hello,

quand on accède au site en https depuis firefox, la carte umap est 
bloquée car il s'agit de « mixed content ». Le mieux serait d'inclure la 
version sécurisée (https://umap.osm.fr/...), ou au moins la version 
utilisant le même protocole (//umap.osm.fr/...) qui chargera la version 
http si on visite le site en http et https si on le visite en https.


« Blocked loading mixed active content 
“http://umap.openstreetmap.fr/…”[Learn More] »


qui renvoi là : 
https://developer.mozilla.org/fr/docs/S%C3%A9curit%C3%A9/MixedContent


J'ai la même erreur pour fonts.googleapis.com, mais là je m'en fiche, 
c'est bloqué chez moi de toute façon :p


Amicalement,
Julien

Le 2017-06-14 20:28, Antoine Riche a écrit :

Ça y est, la carte est en ligne (merci Donat) sur
http://openstreetmap.fr/calendrier avec 9 groupes locaux ... et un
grand vide dans le sud-ouest. Vous pouvez encore remplir le tableur
https://framacalc.org/osm-groupes-locaux utilisé pour créer la carte :
faites-moi signe car je vais arrêter de le surveiller.

Les comptes listés dans le panneau "A propos" sont éditeurs de la
carte, il en manque 2 par rapport au tableur car leur compte est
différent entre uMap et OSM : gendy54 est éditeur mais n'apparaît pas
sur le panneau (quel compte OSM ?), Dlareg est un compte OSM mais pas
uMap. Pas très grave car la carte a déjà 6 éditeurs identifiés, ce qui
élimine le "Bus factor ". Si
vous trouvez que ça encombre votre catalogue de cartes je peux vous
retirer de la liste.

Antoine.


Le 14/06/2017 à 11:03, Nicolas Moyroud a écrit :
Super idée Antoine merci. Et c'est rempli pour le groupe de 
Montpellier !


Nicolas

Le 12/06/2017 à 12:25, Guillaume Allegre a écrit :

Le 2017-06-12, Antoine Riche a écrit :
Pourquoi pas mais avant de faire compliqué je souhaite faire simple 
et

remplacer au plus vite cette carte qui n'a rien à voir.

Excellente initiative, merci Antoine.

J'ai ajouté Grenoble.






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





---
L'absence de virus dans ce courrier électronique a été vérifiée par le
logiciel antivirus Avast.
https://www.avast.com/antivirus

___
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-se] Vad betyder egentligen landuse=residential?

[Ture Pålsson]

On 2017-06-15 08:53, Joakim Fors wrote:

[...]
Jag skulle rekommendera att du forskar lite i historiken på objektet. Kan vara 
någon väldigt gammal polygon som funnits innan detaljerade flygbilder och som 
sen ackumulerat en mängd mer eller mindre relevanta taggar under tiden. Utan 
att öht ha kollat på datan så skulle jag iaf gissa att ma[...]


De verkar ha ritats för att bära postnummerinfo från början. Jag tog 
helt enkelt bort landuse-taggen från dem 
(http://www.openstreetmap.org/changeset/49551592). Det kommer nog att 
göra att en hel del yta som tidigare var "bebyggelsefärgad" blir vit 
fläck i stället.


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

Re: [Talk-it] Idranti

[Alberto]

> Ciao, molto bene. Per me è persino più importante il diametro degli attacchi, 
> anche per l'eventuale integrazione del database con quello dei
> servizi di emergenza. Il diametro degli attacchi è inoltre facilmente 
> desumibile tramite misura, e spesso il suo valore è punzonato direttamente
 > sull'idrante. Anche dal mio punto di vista è utile la proposta.

La proposta sta avendo sviluppi sulla mailing list di tagging, perché sono 
venuto a conoscenza dell'uso dei tag fire_hydrant:coupling_type e 
fire_hydrant:couplings, usati in OsmHydrant ma non documentati nel wiki.
Ora stiamo cercando di raffinare questi tag e poi documenterei tutto sul wiki.
Segnalo comunque che il diametro punzonato sull'idrante (esempio DN80) è il 
diametro della condotta sotterranea che alimenta l'idrante (quindi va nel tag 
fire_hydrant:diameter=80) e non è il diametro degli attacchi esterni.
Alberto


---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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

Re: [Talk-se] Vad betyder egentligen landuse=residential?

[Joakim Fors]

> On 15 Jun 2017, at 08:10, Ture Pålsson  wrote:
> 
> 
> Jag noterade just att det ser väldigt konstigt ut när jag renderar kartor i 
> närheten av Vallentuna:
> 
> 
> 
> (och då syftar jag alltså på den stora bebyggelse-polygonen som går ut i 
> vattnet, inte den tveksamma etikettplaceringen! :-) ).
> 
> Det visade sig bero på att det ligger ett par stora landuse=residential där, 
> som i princip följer kommungränserna. Min första tanke var att radera dem, 
> eftersom någon annan verkar ha ritat mer detaljerat landuse ovanpå, men sedan 
> såg jag att de är taggade med addr:taggar, som ju kanske tillför relevant 
> information. Så vad är rätt, här? Dressera min renderare att hantera det 
> här (antagligen genom att alltid rita vatten överst i stället för att, som 
> nu, rita "minst överst"? (Mapniks rendering ser ju vettig ut). Radera ytorna? 
> Tagga dem med något annat?


Jag skulle rekommendera att du forskar lite i historiken på objektet. Kan vara 
någon väldigt gammal polygon som funnits innan detaljerade flygbilder och som 
sen ackumulerat en mängd mer eller mindre relevanta taggar under tiden. Utan 
att öht ha kollat på datan så skulle jag iaf gissa att man kan ta bort landuse= 
taggen från objektet om det redan finns mer detaljerade landuse-objekt som 
överlappar/ersätter. Hur det är med addr: taggarna får man nog kolla nogare och 
se om de hör hemma på just den polygonen eller om de kan överföras till mer 
precisa platser och objekt.

/Joakim


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

Re: [Talk-es] Propuesta de Importación de Catastro (¡¡¡¡NO SE PUEDE SUBIR NADA !!!).

[Matías h]

Buen día.

Respondiendo a Alejandro en alguna de las cuestiones. Comparando el mismo
casco urbano en versiones .shp con cat2osm2 y el Atom correspondiente.


   - Si está reflejada la información correpondiente a building:levels.


   - Por lo que llevo comprobado, no se generan nodos superpuesto en
   geometrías adyacentes.


Fallos detectados:

   - En el archivo correspondiente a las direcciones, el código postal
   aparece como 6900 cuando en realidad es 06900.


   - addr:street = CL SANTIAGO y addr:city = LLERENA. Aparecen en
   mayúsuculas.

Salud.

El 14 de junio de 2017, 14:58, Alejandro S. 
escribió:

> Hola,
>
> Genial que se siga desarrollando este tema sobre el que tantas vueltas se
> ha dado.
>
> Sin haberlo probado, me surgen algunas cuestiones, a raíz de problemas
> encontrados en anteriores intentonas:
>
> ¿El Atom tiene tanta información como la base de datos del Catastro en su
> formato shp? ¿Está reflejada en el Atom la información correspondiente a
> building:min_level? Si no es así, ¿queremos importar esta información
> parcial en lugar de la general? ¿podemos combinar información de ambos
> repositorios para quedarnos con lo mejor de cada uno?
>
> Entiendo que para los polígonos adyacentes se esta optando por la solución
> de usar áreas adyacentes que comparten los nodos. ¿Es esta la estructura de
> datos que queremos utilizar?
>
> ¿Se está comprobando que no se generan nodos superpuestos en geometrías
> adyacentes?
>
> Vamos comentando.
>
> Saludos,
>   Alejandro Suárez
>
> 2017-06-14 14:36 GMT+02:00 Matías h :
>
>> Hola. Buenas y calurosas tardes.
>>
>> Tal y como señalo en el título del hilo y para que quede claro :).
>>
>> *¡¡¡ *
>>
>> *NO SE PUEDE IMPORTAR TODAVÍA !!!.*
>> Estamos empezando el proceso para intentar nuevamente una posible
>> importación de los datos de catastro.
>>
>> Javier Sánchez ha creado una herramienta para hacer la conversión de
>> datos y como todo software en principio necesitamos hacer el conveniente
>> testeo.
>>
>>- *CatAtom2Osm*. https://github.com/javiersanp/CatAtom2Osm
>>
>>
>>
>>- *Procedimiento de Conversión.* http://wiki.openstreetmap.org/
>>wiki/ES:Catastro_espa%C3%B1ol/Importaci%C3%B3n_de_edificios/
>>Conversi%C3%B3n_de_datos
>>
>> 
>>.
>>
>>
>>
>>- *Discusiones y acuerdos. *http://wiki.openstreetmap.org/
>>wiki/ES_talk:Catastro_espa%C3%B1ol/Importaci%C3%B3n_de_edifi
>>cios/Conversi%C3%B3n_de_datos
>>
>> 
>>
>>
>> En definitiva, aunque utilicemos los canales más rápidos como son
>> Telegram y/o Riot, la discusión y tratamiento que vayamos a hacer con los
>> datos de catastro es mejor hacerlo por la lista y/o por la wiki en el
>> enlace que he puesto arriba.
>>
>> El proceso no ha hecho más que empezar, así que paciencia y colaboración
>> :)
>>
>> Saludos.
>>
>>
>>
>> ___
>> 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