Re: [OSM-ja] 12/14 京都！街歩き！マッピングパーティ：第15回 南禅寺
山下です。皆さんこんにちわ。 京都を街歩きして、楽しみながら 自由な地図である OpenStreetMap を創り上げていくマッピングパーティ！ 12 月の京都！街歩き！マッピングパーティは、 今度の週末に、絶景かな！で有名な三門のある京都五山 別格 南禅寺 イベントの詳細と参加申し込みは connpass にて https://openstreetmap-kyoto.connpass.com/event/11/ 皆様の参加をお待ちしています！ 2019年11月14日(木) 22:08 yasunari yamashita : > > 京都！街歩き！マッピングパーティ世話役の山下です。 > 皆さんこんにちわ。 > > 京都を街歩きして、楽しみながら 自由な地図である OpenStreetMap を創り上げていくマッピングパーティ！ > > 12 月の京都！街歩き！マッピングパーティは、 > 絶景かな！で有名な三門のある京都五山 別格 南禅寺 > > イベントの詳細と参加申し込みは connpass にて > https://openstreetmap-kyoto.connpass.com/event/11/ > > 皆様の参加をお待ちしています！ > -- > 山下康成＠京都府向日市 -- 山下康成＠京都府向日市 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych ? names of international objects
EO Eble mi havas solvon pri la etikedo “name” por kontinentoj (escepte por Antarkto), rigardu al la listo de landoj kaj ĝiaj oficialaj lingvoj, aldonu Interlingvaon, kaj elektu 5 (aŭ pli) de ili: PL Chyba mam rozwiązanie etykiety „name” dla kontynentów (z wyjątkiem Antarktydy), spojrzeć na listę krajów i ich języków oficjalnych, dodać Interlingwę i wybrać 5 bądź więcej z nich): EN I think I have the tag "name" solution for the continents (except Antarctica), look at the list of countries and their official languages, add Interlingua and choose 5 or more of them): Europa / Europe / Evropa / Ευρώπη / Европа Asia / Азия / ایشیا / एशिया / এশিয়া / 亚洲 Afelika / Africa / Afrika / Afrique / أفريقيا / አፍሪቃ America del Nord / América del Norte / Amerik dinò / Amérique du Nord / North America <>___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-es] Uso de landuse=residential
-Los landuse diferentes dentro de las zonas residenciales las puedes marcar igualmente. Una cosa no quita a la otra. -El problema de donde están los límites lo veo igual si se separa en trozos pequeños o en uno grande. Al final en donde hay dudas, se tiene duda de las 2 maneras. Mirando la wiki he visto un etiquetado secundario que no conocía: https://wiki.openstreetmap.org/wiki/Key%3Aresidential El sáb., 7 dic. 2019 a las 23:50, Diego Cruz () escribió: > ¡Buenas! > > Yo estoy de acuerdo en general con lo que decís, aunque a mí no me parece > tan mala idea limitar el residential a las manzanas de viviendas. Me parece > que es más preciso, por los siguientes motivos: > - las vías públicas en realidad son otro tipo de terreno; > - hay manzanas dentro de una población que tienen usos no residenciales y > que ahora figuran como residenciales por estar dentro de una población; > - me parece complicado decidir dónde están los límites de una población si > consideramos que la población es un solo polígono residencial. Alrededor de > una población suele haber descampados, edificios de granjas e industrias, > casas con huertas y otras zonas grises que deberían tener sus propios > landuse y no estar incluidos en el polígono de la población, que al final > termina siendo algo aproximado. > > Dicho esto, sé que la gran mayoría de las poblaciones de España están > marcadas con un único landuse residential, así que cambiarlo sería un > enorme trabajo que entiendo que no apetezca a nadie. Sin embargo, creo que > habría que ser más precisos con los landuses, e incluso incluir más tipos. > > Un saludo > Diego > > El sáb., 7 dic. 2019 12:07, Jorge Sanz Sanfructuoso > escribió: > >> Tengo un pensamiento similar a lo comentado. >> >> Nunca pero nunca unir los landuse a las vías de las calles y cosas >> parecidas. Esto es igual que los edificios que pasa lo mismo. A veces te >> encuentras gente que lo une a las vías de las calles y es también >> incorrecto. No llega hasta mitad de la calle, no estamos representando la >> realidad. >> >> Hay en algunos casos que compartirá nodos con otros landuse y en otros >> casos no. No va a ser un si o no rotundo pero hay en muchos casos que sí >> debe compartir nodos. Tendremos casos que el bosque se mezcla con las casas >> ( nodos no compartidos de los dos landuse) y en casos que nada mas acabar >> la población empezara el bosque (nodos compartidos). Por poner ejemplo >> >> De acuerdo en el tema de los nombres. No tienen nombres en general. Solo >> cuando son cosas aisladas como urbanizaciones o polígonos industriales. Que >> esa area especifica tenga un nombre especifico. Como se ha comentado una >> ciudad no es solo la area residencial. >> >> El tema de usarlo en las manzanas lo veo mal utilizado. Por una parte >> existe etiquetado especifico para indicar manzanas: >> https://wiki.openstreetmap.org/wiki/ES:Tag:place%3Dcity_block >> Por otra lo que es residential ya esta representado por el area grande, >> en este caso las areas pequeñas siguen indicando lo mismo. Es repetitivo. >> >> >> El vie., 6 dic. 2019 a las 19:53, Roberto geb () >> escribió: >> >>> Estoy de acuerdo en no compartir nodos con otros elementos (no seamos >>> vagos que para las modificaciones da mucho más trabajo y las zonas no >>> tienen que ser tan precisas como las calles), y voy más allá: ni siquiera >>> con otros landuse y menos aún con límites administrativos. Pongo ejemplos: >>> un biosque que se urbaniza y en el que hay call es y casas dispersas sigue >>> siendo un bosque y también es una zona residencial; y cuando los >>> contructores deciden construir a ambos lados de una frontera administrativa >>> sigue siendo una úncia zona residencial independientesmente de las >>> fronteras políticas. >>> >>> El vie., 6 dic. 2019 a las 18:46, Diego García () >>> escribió: >>> Buenas tardes. Yo sí le meto bastante tiempo a mapear coberturas y usos del suelo, y coincido contigo. - Límites compartidos: no debería ser jamás de los jamases, sino que debería tener cárcel. No os imagináis los problemas que da eso cuando viene detrás otro editor añadiendo o corrigiendo cosas. Sólo tienen que compartir nodos con otros usos del suelo. Lo contrario queda mal estéticamente y no tiene sentido sobre el mapa. Un camino que comparte nodos con un bosque... ¿qué ocurre si ajustamos la geometría del camino porque está hecho unos zorros? ¿estamos diciendo que se ha movido la línea del bosque? El camino está dentro o fuera, lo cruza o va paralelo al borde, pero no debe compartir nodos con el bosque. Y con landuse residential ocurre lo mismo. *Excepción a todo esto*: los límites administrativos, que sí pueden compartir nodos con polígonos de usos del suelo y coberturas, tanto en el mapa como en la realidad. Puede haber más excepciones, pero ahora mismo no se me ocurren. - Respecto al dibujo del área: cuando me encuentro con que no hay
Re: [Talk-es] Uso de landuse=residential
¡Buenas! Yo estoy de acuerdo en general con lo que decís, aunque a mí no me parece tan mala idea limitar el residential a las manzanas de viviendas. Me parece que es más preciso, por los siguientes motivos: - las vías públicas en realidad son otro tipo de terreno; - hay manzanas dentro de una población que tienen usos no residenciales y que ahora figuran como residenciales por estar dentro de una población; - me parece complicado decidir dónde están los límites de una población si consideramos que la población es un solo polígono residencial. Alrededor de una población suele haber descampados, edificios de granjas e industrias, casas con huertas y otras zonas grises que deberían tener sus propios landuse y no estar incluidos en el polígono de la población, que al final termina siendo algo aproximado. Dicho esto, sé que la gran mayoría de las poblaciones de España están marcadas con un único landuse residential, así que cambiarlo sería un enorme trabajo que entiendo que no apetezca a nadie. Sin embargo, creo que habría que ser más precisos con los landuses, e incluso incluir más tipos. Un saludo Diego El sáb., 7 dic. 2019 12:07, Jorge Sanz Sanfructuoso escribió: > Tengo un pensamiento similar a lo comentado. > > Nunca pero nunca unir los landuse a las vías de las calles y cosas > parecidas. Esto es igual que los edificios que pasa lo mismo. A veces te > encuentras gente que lo une a las vías de las calles y es también > incorrecto. No llega hasta mitad de la calle, no estamos representando la > realidad. > > Hay en algunos casos que compartirá nodos con otros landuse y en otros > casos no. No va a ser un si o no rotundo pero hay en muchos casos que sí > debe compartir nodos. Tendremos casos que el bosque se mezcla con las casas > ( nodos no compartidos de los dos landuse) y en casos que nada mas acabar > la población empezara el bosque (nodos compartidos). Por poner ejemplo > > De acuerdo en el tema de los nombres. No tienen nombres en general. Solo > cuando son cosas aisladas como urbanizaciones o polígonos industriales. Que > esa area especifica tenga un nombre especifico. Como se ha comentado una > ciudad no es solo la area residencial. > > El tema de usarlo en las manzanas lo veo mal utilizado. Por una parte > existe etiquetado especifico para indicar manzanas: > https://wiki.openstreetmap.org/wiki/ES:Tag:place%3Dcity_block > Por otra lo que es residential ya esta representado por el area grande, en > este caso las areas pequeñas siguen indicando lo mismo. Es repetitivo. > > > El vie., 6 dic. 2019 a las 19:53, Roberto geb () > escribió: > >> Estoy de acuerdo en no compartir nodos con otros elementos (no seamos >> vagos que para las modificaciones da mucho más trabajo y las zonas no >> tienen que ser tan precisas como las calles), y voy más allá: ni siquiera >> con otros landuse y menos aún con límites administrativos. Pongo ejemplos: >> un biosque que se urbaniza y en el que hay call es y casas dispersas sigue >> siendo un bosque y también es una zona residencial; y cuando los >> contructores deciden construir a ambos lados de una frontera administrativa >> sigue siendo una úncia zona residencial independientesmente de las >> fronteras políticas. >> >> El vie., 6 dic. 2019 a las 18:46, Diego García () >> escribió: >> >>> Buenas tardes. >>> >>> Yo sí le meto bastante tiempo a mapear coberturas y usos del suelo, y >>> coincido contigo. >>> >>> - Límites compartidos: no debería ser jamás de los jamases, sino que >>> debería tener cárcel. No os imagináis los problemas que da eso cuando viene >>> detrás otro editor añadiendo o corrigiendo cosas. Sólo tienen que compartir >>> nodos con otros usos del suelo. Lo contrario queda mal estéticamente y no >>> tiene sentido sobre el mapa. Un camino que comparte nodos con un bosque... >>> ¿qué ocurre si ajustamos la geometría del camino porque está hecho unos >>> zorros? ¿estamos diciendo que se ha movido la línea del bosque? El camino >>> está dentro o fuera, lo cruza o va paralelo al borde, pero no debe >>> compartir nodos con el bosque. Y con landuse residential ocurre lo mismo. >>> *Excepción >>> a todo esto*: los límites administrativos, que sí pueden compartir >>> nodos con polígonos de usos del suelo y coberturas, tanto en el mapa como >>> en la realidad. Puede haber más excepciones, pero ahora mismo no se me >>> ocurren. >>> - Respecto al dibujo del área: cuando me encuentro con que no hay nada >>> hecho, yo suelo empezar por seguir la línea del catastro. Da una idea muy >>> buena de por dónde van los tiros, y lo deja casi terminado. A partir de >>> ahí, a dibujar casitas y, cuando ya las he terminadoo, o incluso al mismo >>> tiempo, refino los límites del polígono con lo que me he encontrado. >>> Estamos mapeando la realidad, no perdamos eso de vista. Por mucho que el >>> catastro diga que una zona es residencial, si no hay absolutamente nada en >>> ella (ni edificios ni gente viviendo), no es landuse residential. Y >>> viceversa. >>> - El landuse
Re: [Talk-se] Skapa rad av likadana hus?
Lättaste är nog att använda plugin building tools för att göra snygga och enkla byggnader, men just att justera dem enligt ditt önskemål finns vad jag vet ingen bra metod för. Tänk på att om du har en byggnad markerad medan du ritar nästa med building tools behålls samma vinkel på byggnaden, vilket gör det lättare att hålla dem raka. Du kan också markera alla noder längs linjen som ska vara rak och trycka på L för att räta ut den. Gör samma sak med den nedre linjen. Använd sedan Q för att göra husen vinkelräta igen så blir det så bra som möjligt. /Andreas Skickat från min iPhone > 7 dec. 2019 kl. 19:23 skrev Lennart Romberg : > > Om man har ritat ett hus och gjort x kopior, kan man få dem utlagda i rad med > samma avstånd (på samma sätt som "distribuera noder" men för hela area-objekt? > Har läst igenom listan över josm-plugins men hittar inget som ser ut att göra > det jag vill. (Och jag har hittat många rad- och kedjehus med lite > oregelbunden placering, så tyder på att inget verktyg finns?). > > / Lennart > > ___ > Talk-se mailing list > Talk-se@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
[Talk-at] Tagging von Wohnstraßen / Begegnungszonen in Österreich - Versuch eines Konsens
Hallo liebe Mapper und Mapperinnen, im Forum ist vor einiger Zeit wieder die Diskussion um das Tagging von Wohnstraßen vs. Begegnungszonen in Österreich aufgekommen. Nachdem es bis zuletzt keinen Konsens gegeben habe möchte ich einen neuen Versuch mit euch einen zu finden. Könnt ihr Rückmeldung (im Forum oder hier) geben? https://forum.openstreetmap.org/viewtopic.php?pid=770375#p770375 Liebe Grüße, Markus / evod -- hier noch mein Forumeintrag für alle die nicht registriert sind: -- OK - Unabhängig vom Thema ob jede Begegnungszone highway=living_street sein darf oder ob auch andere highway-Werte sinnvoll sind gibt es jedenfalls den Fakt, dass sowohl Wohnstraßen als auch Begegnungszonen als highway=living_street gemappt sind. Ich würde gerne mit euch einen österreichischen Best Practice definieren um das so zu mappen, dass auch die Unterschiede eindeutig zu mappen sind. Mein Vorschlag (adaptiert nach Rückmeldung von Kevin Kofler und Luzandro): # Wohnstraße: > highway=living_street > traffic_sign=AT:§53.9c > maxspeed=walk Falls es eine Einbahn ist (die laut StVO immer für den Radverkehr geöffnet ist, egal ob mit Zusatzschild oder nicht) > oneway=yes > oneway:bicycle=no # Begegnungszone: > highway=living_street (oder anderes..) > traffic_sign=AT:§53.9e > maxspeed=20 (oder 30) > source:maxspeed=AT:Begegnungszone:20 (oder :30) - optional, etwas redundant Falls es eine Einbahn ist: > oneway=yes Nur falls die Einbahn mit der entsprechenden Beschilderung für Radfahrer geöffnet ist: > oneway:bicycle=no # Diskussionspunkte: - sollen wir auch für die Wohnstraße ein traffic_sign verwenden? Das wäre dann AT:§53:9c (kommt bisher kein einziges mal vor, war historisch auch nicht nötig, würde die zwei Straßen aber eindeutig unterscheiden) - Welcher Wert soll für die maxspeed einer Wohnstraße angegeben werden? maxspeed=AT:walk? Oder das laut taginfo weit häufigere maxspeed=walk? Oder soll kein Wert gemapt werden (derzeit oft der Fall) - traffic_sign: wenn ich mir https://taginfo.openstreetmap.org/keys/ … ign#values ansehe sind die Unterparagraphen für AT:* meist mit Doppelpunkt getrennt, nicht mit Punkt. Das würde heißen traffic_sign=AT:§53:9e statt traffic_sign=AT:§53.9e (letzterer Wert wird im Moment bei Begegnungszonen häufiger verwendet - das sollten wir jedenfalls vereinheitlichen) - andere Punkte die euch auffallen? ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[OSM-talk-fr] Présentation
Bonjour aux abonné(e)s à la liste Talk-fr, Comme recommandé dans le mail de bienvenue je me présente. Enseignant à Digne-les-Bains, dans les Alpes de Haute Provence, président actuel de l'Association Linux Alpes (Groupe d'utilisateurs de logiciels libres). Linux Alpes anime depuis peu un groupe de contributeurs OpenStreetMap. Nous sommes en effet une petite dizaine de contributeurs actifs en contact dans la ville. À titre personnel je contribue à l'occasion sur mes lieux de vacances, et en particulier à Valjouffrey (Isère). J'utilise ID et JOSM. Sur le plan technique j'ai encore de nombreuses interrogations, une question en appelant une autre, etc :) Quelques liens : Association Linux Alpes : http://www.linux-alpes.org/ Digne-les-Bains sur Wiki OSM : https://wiki.openstreetmap.org/wiki/Digne-les-Bains Liste de discussion osmdi...@linux-alpes.org : https://ml.linux-alpes.org/cgi-bin/mailman/listinfo/osmdigne Au plaisir de vous lire et de participer. Librement, Arnaud Champollion ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[Talk-se] Skapa rad av likadana hus?
Om man har ritat ett hus och gjort x kopior, kan man få dem utlagda i rad med samma avstånd (på samma sätt som "distribuera noder" men för hela area-objekt? Har läst igenom listan över josm-plugins men hittar inget som ser ut att göra det jag vill. (Och jag har hittat många rad- och kedjehus med lite oregelbunden placering, så tyder på att inget verktyg finns?). / Lennart ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [Talk-cat] Importació centres docents a Catalunya
Hola, ok, he fet les modificacions, no es molt complicat. Aqui estan els arxius i el nou OSM: https://drive.google.com/open?id=1etBzdv3Dni3Dv_Vcfd_6huvuB9yme5hm He posat les traduccions de paraules i frases totes al fitxer de configuracio de forma que es poden afegir o modificar segons sigui necessari. # Terms and abreviations to be translated translations: operator:type: Públic: public Privat: private operator: Alt. Ens Públ.: Altres ens Públics Alt. est. no UE: Atres estats no Unió Europea Alt. estats UE: Atres estats Unió Europea Alt. Titularit.: Atres titularitats Altres Depart.: Altres Departaments Associacions: Associacions Cooperatives: Cooperatives Corp. Locals: Corporacions locals Dep.Ensenyament: Departament d'Ensenyament Església Catòl.: Església Catòlica Fundacions: Fundacions Jurídica Estra.: Jurídica estrangera Ordes i Cong.: Ordes i Congregacions Person.Fís. Es.: Persones Físiques Persones Físiq.: Persones Físiques Soc. Civils: Societats civils Soc. Mercantils: Societats mercantils word_replacements: addr:street: C.: Carrer Av.: Avinguda Ctra.: Carretera Pl.: Plaça pça.: Plaça Pça.: Plaça Pg.: Passeig Pss: Passeig Rbla.: Rambla Rda.: Ronda Trav.: Travessera Ptge.: Passatge pge.: Passatge urb.: Urbanització Urb.: Urbanització Prol.: Prolongació name: Esc.: Escola Cons.: Consevatori Cent.: "Centre " Prof: "Professional " Mús.: Música C.Educ.: "Centre d'Educació " Sup.: "Superior " Inst.: Institut inf.: infants Respecte als centres propers el que podria fer es agruparlos en paquests de p.ex 100 centres (clustering) , per proximitat basat en les coordenades. I fer un arxiu OSM per cada grup. A partir d'aixo tambe es podria treure el poligon quadrat (bbox) que conte cada grup (max lat, max lon, min lat, min lon). Pero no serien quadrats alineats ni res, molts es solaparien per algun canto a llocs com barcelona, etc. No se si serviria. O potser amb els osm de cada grup es suficient per repartir la feina, per que de fet l'altre script de madrid fa el contrari, a partir dels quadrats calcula aquests osm petits. On Sat, Dec 7, 2019 at 1:25 PM Lanxana . wrote: > Bon dia! > > En primer lloc, molt bona feina, Víctor, ets un crack! Moltes gràcies per > preparar l'script. > > Fins avui no he pogut mirar-m'ho amb calma, al intentar carregar el fitxer > *.osm a JOSM dona un error en unes coordenades, que al fitxer origen estan > malament. És una correcció manual que ja documentaré a la wiki i ho > comunicaré també al Departament d'Ensenyament perquè ho corregeixin a la > seva base. És l'Institut de Navarcles, codi 08059524, on la longitud s'ha > de canviar a 1.91130 (aprox., al dataset agafa el mateix valor que la UTM > Y, fins i tot a la columna amb la nova georeferència) > > Respecte a generar el fitxer GEOJSON, el propi JOSM deixa exportar en > aquest format, i des de QGIS puc fer els polígons per al gestor de tasques > (al menys aquesta és la teoria). Estic investigant com aconseguir polígons > que tinguin una quantitat similar de centres propers entre ells, sinó ho > faria de manera manual i aproximada. > > Respecte al script, volia saber si es poden incloure uns petits canvis, si > no es pogués ho documentaria per a que es faci la revisió manual abans de > validar cada centre: > > - el tag url no cal que aparegui en cada centre, el reservaríem per al > changeset. En canvi, els de source i source:date està bé que hi siguin > perquè és informació directa que un pot necessitar quan consulti aquell > centre en concret. > > - el tag operator:type agafa el valor de la taula, que està en català, i > hauria de quedar en anglès: > > Nom naturalesa operator:type > Públic public > Privat private > > - el tag operator també agafar el valor de la taula, que conté > abreviatures i s'haurien de substituir pels noms complets: > > Nom titularitat operator > Alt. Ens Públ. Altres ens Públics > Alt. est. no UE Atres estats no Unió Europea > Alt. estats UE Atres estats Unió Europea > Alt. Titularit. Atres titularitats > Altres Depart. Altres Departaments > Associacions Associacions > Cooperatives Cooperatives > Corp. Locals Corporacions locals > Dep.Ensenyament Departament d'Ensenyament > Església Catòl. Església Catòlica > Fundacions Fundacions > Jurídica Estra. Jurídica estrangera > Ordes i Cong. Ordes i Congregacions > Person.Fís. Es. Persones Físiques > Persones Físiq. Persones Físiques > Soc. Civils Societats civils > Soc. Mercantils Societats mercantils > > - passa el mateix amb el tag name, en aquest cas hi ha moltíssimes > variables i no sé fins a quin punt es poden automatitzar els canvis (si es > pogués a partir d'una taula, la tinc creada i te la podria passar) > > - igual amb el tag addr:street, però com que les adreces s'hauran de > revisar manualment sí o sí, es optatiu fer el canvi de C. per Carrer, Av. > per Avinguda, etc. amb l'script > > Un cop més, moltes gràcies per la feina feta! > ___ > Talk-cat mailing list > Talk-cat@openstreetmap.org >
[OSM-talk-fr] Remplacer ref:ERDF:gdo par ref:FR:Enedis / ref:FR:gdo
Salut à tous, La motivation de Stéphane sur ref:INSEE m'a motivé pour proposer un autre changement sur une clé de référence. Il sera pour ma part moins important en volume concerné. Il porterait sur le remplacement automatique de ref:ERDF:gdo en ref:FR:Enedis ou ref:FR:gdo sur 2700 objets. https://wiki.openstreetmap.org/wiki/FR:Key:ref:ERDF:gdo La justification est de deux ordres : - ERDF n'existe plus - La référence est propre à la France et ne comporte pas FR. Je trouve que ce serait une bonne chose => ref:FR:Enedis pourrait convenir Nous utilisons ref:ERDF:gdo pour documenter les réseaux électriques mais le Guide Des Ouvrages est partagé avec les gaziers de GRDF. Ainsi ref:FR:gdo permettrait aussi de documenter les affleurant gaziers N'hésitez pas à donner votre avis sur cette proposition, en tenant compte de la volumétrie d'usage : https://taginfo.openstreetmap.org/keys/?key=ref%3AERDF%3Agdo Ce peut aussi être l'occasion de nettoyer un peu les données, parce que beaucoup de ces refs sont aussi dans ref=* et pas dans ref:ERDF:gdo actuellement. Bonne après-midi François ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [Talk-cat] Importació centres docents a Catalunya
Bon dia! En primer lloc, molt bona feina, Víctor, ets un crack! Moltes gràcies per preparar l'script. Fins avui no he pogut mirar-m'ho amb calma, al intentar carregar el fitxer *.osm a JOSM dona un error en unes coordenades, que al fitxer origen estan malament. És una correcció manual que ja documentaré a la wiki i ho comunicaré també al Departament d'Ensenyament perquè ho corregeixin a la seva base. És l'Institut de Navarcles, codi 08059524, on la longitud s'ha de canviar a 1.91130 (aprox., al dataset agafa el mateix valor que la UTM Y, fins i tot a la columna amb la nova georeferència) Respecte a generar el fitxer GEOJSON, el propi JOSM deixa exportar en aquest format, i des de QGIS puc fer els polígons per al gestor de tasques (al menys aquesta és la teoria). Estic investigant com aconseguir polígons que tinguin una quantitat similar de centres propers entre ells, sinó ho faria de manera manual i aproximada. Respecte al script, volia saber si es poden incloure uns petits canvis, si no es pogués ho documentaria per a que es faci la revisió manual abans de validar cada centre: - el tag url no cal que aparegui en cada centre, el reservaríem per al changeset. En canvi, els de source i source:date està bé que hi siguin perquè és informació directa que un pot necessitar quan consulti aquell centre en concret. - el tag operator:type agafa el valor de la taula, que està en català, i hauria de quedar en anglès: Nom naturalesa operator:type Públic public Privat private - el tag operator també agafar el valor de la taula, que conté abreviatures i s'haurien de substituir pels noms complets: Nom titularitat operator Alt. Ens Públ. Altres ens Públics Alt. est. no UE Atres estats no Unió Europea Alt. estats UE Atres estats Unió Europea Alt. Titularit. Atres titularitats Altres Depart. Altres Departaments Associacions Associacions Cooperatives Cooperatives Corp. Locals Corporacions locals Dep.Ensenyament Departament d'Ensenyament Església Catòl. Església Catòlica Fundacions Fundacions Jurídica Estra. Jurídica estrangera Ordes i Cong. Ordes i Congregacions Person.Fís. Es. Persones Físiques Persones Físiq. Persones Físiques Soc. Civils Societats civils Soc. Mercantils Societats mercantils - passa el mateix amb el tag name, en aquest cas hi ha moltíssimes variables i no sé fins a quin punt es poden automatitzar els canvis (si es pogués a partir d'una taula, la tinc creada i te la podria passar) - igual amb el tag addr:street, però com que les adreces s'hauran de revisar manualment sí o sí, es optatiu fer el canvi de C. per Carrer, Av. per Avinguda, etc. amb l'script Un cop més, moltes gràcies per la feina feta! ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [OSM-talk] Relevance of the “name” tag in places where there is no obvious associated language
I personally am not a fan of using 8 different names in one name tag (though some countries that have multiple equal languages do favour that nationally). The example here "Baltijas jūra / Baltijos jūra / Itämeri / Läänemeri / Morze Bałtyckie / Östersjön / Østersøen / Ostsee / Балтийское море" seems a bit clumsy. As a side question: how many places are actually affected by this, in an order of magnitude? I would expect most seas and oceans, some englobing territories like continents (although we discussed before that continents doesn’t make much sense in OSM), multilingual political entities (Europe, Mercosul, etc.), and I guess stateless Islands (typically around Antarctica). I guess it’s more than an hundred, but is it much more than a thousand? The reason I’m asking is that there may actually be a relatively reasonable number of tiles affected by the issue. I understand that it would be quite a heavy technical challenge to have to deal with several versions of similar tiles, but at least it may actually not take that much additional space. (Also, it might put things into perspective to have an idea of how many places we are discussing here ☺) Regards, Martin. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych ? names of international objects
On 12/7/19 02:54, Martin Koppenhoefer wrote: sent from a phone On 6. Dec 2019, at 15:16, pangoSE wrote: I believe that we should deprecate all wikipedia links as they are just potentially obsolete cruft that can be inferred from the wikidata item. (I am also an editor of Wikidata) If you really want the Wikipedia link displayed fix your editor to fetch the local wikipedia link (if any) for your local language in addition to the label and description. I know that people are assuming that a wikipedia article in language x has approximately the same content as another one in language y that is linked to it, but this is not the case. There are often significant differences, even if many articles are translations from the English version. Wikidata is another thing. It all started with one wikidata object for every article, but as the project grows and people edit it (yes, not only bots are editing wikidata), their objects get split and refined (subgroups of objects). A common example are settlements. In wikipedia, political and socio-geographic entities are often covered in the same article (or they are combined in one language and split in another). In wikidata (and even more in OpenStreetMap), these tend to get split over several objects. Wikipedia tends to aggregate several aspects of a thing into one article, wikidata tends to separating the concepts. If someone adds a wikipedia link for something, you can see by the language which specific article she has read and linked (confirmed). It does not automatically imply that all wikipedia articles in other languages would also fit for the OpenStreetMap object that has gotten the tag. Even less for wikidata (which usually only deals with part of an article, which is not necessarily the one which fits for the object). Just have a look, it happens all the time, another typical case for issues are buildings and things inside the buildings (museums, governments, whatever). Maybe it is less of an issue with natural places (mountains, seas, etc), but in the cultural world it is almost ubiquitous. Cheers Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk Good morning Martin, Here is, for example, the article for the Louvre museum in Englsh: https://en.wikipedia.org/wiki/Louvre . On the left part of this page there is the link "Wikidata item", which leads to this wikidata page: https://www.wikidata.org/wiki/Q19675 On the wikidata page there are links to the Wikipedia articles of this museum in dozens of languages. This particular museum is of an interest to the large number of people from many countries for numerous reasons (tourists, researches, students, etc.). I assume that the absolute majority of these people will not read the article in English or in French, but rather in their mother tongue. Usually any significant Wikipedia article has got its respective wikidata item. If it does not have it, it could be created easily. So instead of adding a Wikipedia article of a museum in a specific language, the wikida item with the links to this articles in all available languages could be added. Then in a map editor or on a map web page, a visitor could be shown the link to the article in her/his language of choice immediately. So that the visitor could go to the Wikipedia article directly. But not first to the Wikipedia article in a foreign language and then search manually for the link to the article in his mother tongue on the HTML page. Or even better, he could be presented with a drop-down list of this Wikipedia article in all available language versions with the article in his language of choice preselected. The Wikidata is the structured database, so its contents can be accesses in a complex programmatic manner. While the Wikipedia article is an HTML page, so basically it is the final destination for a program. Only human can read it and go father from it manually. Best regards, Oleksiy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-es] Uso de landuse=residential
Tengo un pensamiento similar a lo comentado. Nunca pero nunca unir los landuse a las vías de las calles y cosas parecidas. Esto es igual que los edificios que pasa lo mismo. A veces te encuentras gente que lo une a las vías de las calles y es también incorrecto. No llega hasta mitad de la calle, no estamos representando la realidad. Hay en algunos casos que compartirá nodos con otros landuse y en otros casos no. No va a ser un si o no rotundo pero hay en muchos casos que sí debe compartir nodos. Tendremos casos que el bosque se mezcla con las casas ( nodos no compartidos de los dos landuse) y en casos que nada mas acabar la población empezara el bosque (nodos compartidos). Por poner ejemplo De acuerdo en el tema de los nombres. No tienen nombres en general. Solo cuando son cosas aisladas como urbanizaciones o polígonos industriales. Que esa area especifica tenga un nombre especifico. Como se ha comentado una ciudad no es solo la area residencial. El tema de usarlo en las manzanas lo veo mal utilizado. Por una parte existe etiquetado especifico para indicar manzanas: https://wiki.openstreetmap.org/wiki/ES:Tag:place%3Dcity_block Por otra lo que es residential ya esta representado por el area grande, en este caso las areas pequeñas siguen indicando lo mismo. Es repetitivo. El vie., 6 dic. 2019 a las 19:53, Roberto geb () escribió: > Estoy de acuerdo en no compartir nodos con otros elementos (no seamos > vagos que para las modificaciones da mucho más trabajo y las zonas no > tienen que ser tan precisas como las calles), y voy más allá: ni siquiera > con otros landuse y menos aún con límites administrativos. Pongo ejemplos: > un biosque que se urbaniza y en el que hay call es y casas dispersas sigue > siendo un bosque y también es una zona residencial; y cuando los > contructores deciden construir a ambos lados de una frontera administrativa > sigue siendo una úncia zona residencial independientesmente de las > fronteras políticas. > > El vie., 6 dic. 2019 a las 18:46, Diego García () > escribió: > >> Buenas tardes. >> >> Yo sí le meto bastante tiempo a mapear coberturas y usos del suelo, y >> coincido contigo. >> >> - Límites compartidos: no debería ser jamás de los jamases, sino que >> debería tener cárcel. No os imagináis los problemas que da eso cuando viene >> detrás otro editor añadiendo o corrigiendo cosas. Sólo tienen que compartir >> nodos con otros usos del suelo. Lo contrario queda mal estéticamente y no >> tiene sentido sobre el mapa. Un camino que comparte nodos con un bosque... >> ¿qué ocurre si ajustamos la geometría del camino porque está hecho unos >> zorros? ¿estamos diciendo que se ha movido la línea del bosque? El camino >> está dentro o fuera, lo cruza o va paralelo al borde, pero no debe >> compartir nodos con el bosque. Y con landuse residential ocurre lo mismo. >> *Excepción >> a todo esto*: los límites administrativos, que sí pueden compartir nodos >> con polígonos de usos del suelo y coberturas, tanto en el mapa como en la >> realidad. Puede haber más excepciones, pero ahora mismo no se me ocurren. >> - Respecto al dibujo del área: cuando me encuentro con que no hay nada >> hecho, yo suelo empezar por seguir la línea del catastro. Da una idea muy >> buena de por dónde van los tiros, y lo deja casi terminado. A partir de >> ahí, a dibujar casitas y, cuando ya las he terminadoo, o incluso al mismo >> tiempo, refino los límites del polígono con lo que me he encontrado. >> Estamos mapeando la realidad, no perdamos eso de vista. Por mucho que el >> catastro diga que una zona es residencial, si no hay absolutamente nada en >> ella (ni edificios ni gente viviendo), no es landuse residential. Y >> viceversa. >> - El landuse residential debería abarcar toda la población. ¿Se puede >> dibujar uno por manzana? Pues sí, se puede, pero no tiene sentido alguno: >> ¿hay alguna diferencia entre una manzana y la siguiente? Si lo hacemos >> estamos complicando el mapa sin aportar información, y corremos el riesgo >> de compartir nodos del landuse con otro elementos sin necesidad. >> - Añado para que quede claro: las landuse residential no deben llevar la >> etiqueta name, a excepción de urbanizaciones, barrios, etc, separados del >> núcleo principal, cuando sí tengan un name. Si no tienen name, dejamos el >> teclado en paz y no se pone, que a veces parece que hay obsesión con poner >> name a todo. El name de una localidad va siempre en el place. Cuando >> dibujas una landuse residential lo que haces es declarar que esa zona está >> destinada a habitación, nada más. ¿Es que el polígono industrial que hay >> junto al área residencial no forma parte de la población? Si pones name al >> landuse residential es eso exactamente lo que estás diciendo. >> >> En resumen: landuse no debe compartir nodos con otros elementos (salvo >> otros landuse y límites administrativos), debería abarcar toda el área >> poblada (al margen de lo que diga el catastro), y no lleva name (salvo >> núcleos separados del
Re: [OSM-talk-fr] JOSM : comment tracer un cercle de rayon donné autour d'un point
Le 06/12/2019 à 21:48, Yves P. a écrit : Le raccourcis shift+o permet de transformer une ligne représentant le diamètre en un cercle. Je restais sur le commentaire du menu /« Créer un cercle à partir de 3 noeuds sélectionnés » / / / Si on sélectionne 1 seul noeud ou plus de 3, le message d’erreur est clair 3 : /« Sélectionnez exactement deux ou trois noeuds ou un chemin avec exactement deux ou trois noeuds »/. Ce n’est pas tout à fait ce que j’ai besoin (je pensais qu’un greffon faisait ça), mais ça simplifie beaucoup l’édition. Merci orhygine Même s'il n'est pas fait pour ça, tu as le greffon https://wiki.openstreetmap.org/wiki/JOSM/Plugins/RoundaboutExpander Maj+D tu crée le centre Ctrl+Maj+R tu indique le diamètre Ctrl+Maj+R tu corrige le centre, les attributs. Leni ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
