Re: [Talk-hr] Fwd:Vaši podaci i Openstreetmap projekt
Kratka novost. Ne koristimo tag maxaxleload već railway:track_class (time su osigurane vrijednost opterećenja po osovini i po dužnom metru) Također hrpa drugih tagova korisnih u mapiranju pruga (na njemačkom) http://wiki.openstreetmap.org/wiki/DE:OpenRailwayMap/Erweitertes_Tagging ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Mozilla Location Service
On Tue, Oct 29, 2013 at 10:40:29AM +0100, Gordan Krešić wrote: Mozilla pokreće javni i besplatni geolokacijski servis kao pandan Googleovom: https://location.services.mozilla.com/ Cool! Nego, po cemu se razlikuje od http://www.openbmap.org/ (osim sto ce vjerojatno biti kao default location service u firefoxu, pretpostavljem)? I da li se moze podesiti android da koristi to umjesto googleovog lokatora (coarse location tj. kad nema GPSa i kao assist GPSu)? Ili da li ima neku aplikaciju koja na androidu moze izvuci trentne koordinate na osnovu toga? -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
[Talk-hr] Fwd: [HOT] Typhoon Haiyan - Locating Villages and Connecting Roads
Original Message Subject: [HOT] Typhoon Haiyan - Locating Villages and Connecting Roads Date: Sat, 09 Nov 2013 11:32:27 -0600 From: Andrew Buck andrew.r.b...@gmail.com To: hot h...@openstreetmap.org I just recieved a request from the American Red Cross to make a pass over the wider area surrounding Tacloban to locate all small villages and try to connect them to the road network if they are not already done. They are still in the early planning stages of their response and do not have detailed information for us yet on exactly where their efforts will be focused but they think that no matter what the exact response ends up being, this data will likely be of use in planning/executing that response. I have created a task manager job with big tiles over a pretty wide area around our current area of interest. Remember that this is just to locate the villages and trace a landuse=residential around them and draw in the main connecting roads, you do not need to trace all the details in the villages at this time (although for small clusters of just a few houses I often just do this right away anyway since it goes so fast, but this is up to you). http://tasks.hotosm.org/job/339 Also, on a related issue, this response has reached a level of activity that I think we should consider formal activation. We now have at least this one outstanding request from an aid organization and I expect there will be others forthcoming. -AndrewBuck ___ HOT mailing list h...@openstreetmap.org https://lists.openstreetmap.org/listinfo/hot ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [talk-ph] [HOT] Typhoon Haiyan Mapping Progress
Hi, According to Al Jazeera, the death toll could be very high, sadly. And several millions of people have been affected. I'd like to remind that an often-mentioned weakness of OSM is the uneven quality of the coverage, and that it is not because you have a hammer that everything is a nail. So, while Tacloban was indeed hit very badly, and a detailed building map there is undoubtedly useful, it might also be useful if some of the mappers who wish to contribute took a broader view, to map, for example, some of the roads and villages that are visible on (sometimes recent) high resolution Bing imagery (http://osmph.github.io/Imagery_Coverage_Map/), but sometimes still unmapped in OSM. (Not to mention the rivers). GNS (http://wiki.openstreetmap.org/wiki/GNS) can also be a good source for names, even if it sometimes includes old versions of duplicated nodes with inaccurate location. High resolution imagery can be useful to tell which is right in these cases. Best wishes, Jean-Guilhem ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] [HOT] Typhoon Haiyan Mapping Progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I agree that wider coverage will be needed and I had hoped that by now we would have a better indication of where to map as well. My reason for staying with Tacloban for so long was largely due to lack of knowing where else to shift focus to (although I did allude to this a bit by suggesting the other villages on the coast northeast of Tacloban), more importantly due to a second fact... When we map an area, it is only really useful for us to map areas that the aid organizations we work with will be responding to. For the aid organizations that don't know about, or don't know how to use, our map; then no matter how good the coverage is, it doesn't help them. This is the main reason I chose to focus on Tacloban. It is badly hit (as were many other places as you rightly point out) but it is also a provincial capital, and it is the largest town in the immediate area. Because of this I figured that most of the international response would likely be directed there, and since it is mostly the international orgs that we tend to work with I figured the map data would be most useful there. Now, that being said I want to make it clear that the explanation above is not necessarily an argument for continuing to focus entirely on Tacloban, just merely an explanation of why I hadn't directed people elsewhere yet. I agree that we will need to spread out our efforts at some point, and that point may be approaching, the question is where to focus next. As I mentioned previously, I think the villages along the coast to the northeast will be hard hit (and due to their proximity to Tacloban will likely receive international aid). There are also villages along the coast to the south of Tacloban that will have been hit hard as well since the eye passed directly over them. The eye track will likely have done the most damage, or the area to the north of the eye track since the storm rotates counterclockwise as it moves westward. If anyone has better suggestions of where to spread out to I am certainly open to them. Like I said I am not saying we need to stay at Tacloban (and the surrounding area) just explaining why I was continuing focus there. I know the storm affected a lot to the west as well but I figured this would be trickier to map for two reasons. 1) it is a larger area with not such and obvious target for international aid, and 2) the wind speeds were lower to the west due to the storm being disrupted by the islands. As for the idea of mapping the area affected by the earthquake to the south, my understanding (and this could be wrong) was that most of what we could do remotely has already been done when the earthquake hit. So that is all of my reasoning at the current time for our current focus. I hope to begin hearing more concrete info from aid orgs today so I might redirect people when I hear from them, but for now my advice would be to try to continue with Tacloban (especially the low lying areas) and simultaneously spread out into the surrounding villages until/unless we get something concrete from an aid org. - -AndrewBuck On 11/09/2013 05:25 AM, Jean-Guilhem Cailton wrote: Hi, According to Al Jazeera, the death toll could be very high, sadly. And several millions of people have been affected. I'd like to remind that an often-mentioned weakness of OSM is the uneven quality of the coverage, and that it is not because you have a hammer that everything is a nail. So, while Tacloban was indeed hit very badly, and a detailed building map there is undoubtedly useful, it might also be useful if some of the mappers who wish to contribute took a broader view, to map, for example, some of the roads and villages that are visible on (sometimes recent) high resolution Bing imagery (http://osmph.github.io/Imagery_Coverage_Map/), but sometimes still unmapped in OSM. (Not to mention the rivers). GNS (http://wiki.openstreetmap.org/wiki/GNS) can also be a good source for names, even if it sometimes includes old versions of duplicated nodes with inaccurate location. High resolution imagery can be useful to tell which is right in these cases. Best wishes, Jean-Guilhem -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSfjttAAoJEK7RwIfxHSXbuyAQAJ7RN1Tqh04GWL0Gb03Tb+nQ Z4sIRt4Z3wBdOte8MjB3B+W8zGYtUw3kwfbb3DV8tcdKpEiHzjc2+GrjLgoLzZCe TvxHqFN5Q6srENG180WbZtA8gMESLV5xbeOSt5NU9xnqo24yggWSlAc7FoH2SOSp 3aMNyrALeW03y406TUH4DwCIBmkwLMWZufdkzOnbwou0Ebd2CcYERepm3f+4ifQM XI9o8jJt5fspYksaiePmRpMrS8Gn7UznYhzhOsPBbjGlP4wFbazNOsuwE2phBBss wTX9awNSDqjv6EzebEzDN36I8hSeQEYxnsNrLWmaj/+xydxOfchxZlDKXhJm42Qe zP0c+HakmZPORnmYCms1FHwjGzH5SKgApK3Vpaa+A/T8z+wqEaWmimhV/mX48aQx I/pFTnwto+Df35htKYwU1U9xQ7BB+W1FizYqdkc84HaTyvcQkdfPM5YXzokmxLQz QbP1quYE+M1sESfiZGqIrV2K1AL+NrrBbr1C6r6J9ICtj8swQZpoyvWcg3LR+UqF 5prd7disNuZ6CPHQkLn+ChdPtC6A4gfXqAFEm2g54Pg5Q5t43Qg0DAVPl4bME5Y5
Re: [talk-ph] [HOT] Typhoon Haiyan Mapping Progress
Hello everyone, There are 2 additional HOT Tasks that have been created: 1. http://tasks.hotosm.org/job/339 - Mapping villages in Samar and Leyte (just the residential areas and roads, no need for buildings) 2. http://tasks.hotosm.org/job/340 - Mapping in detail selected areas that are known to have been highly affected by the typhoon On Sat, Nov 9, 2013 at 9:41 PM, Andrew Buck andrew.r.b...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I agree that wider coverage will be needed and I had hoped that by now we would have a better indication of where to map as well. My reason for staying with Tacloban for so long was largely due to lack of knowing where else to shift focus to (although I did allude to this a bit by suggesting the other villages on the coast northeast of Tacloban), more importantly due to a second fact... When we map an area, it is only really useful for us to map areas that the aid organizations we work with will be responding to. For the aid organizations that don't know about, or don't know how to use, our map; then no matter how good the coverage is, it doesn't help them. This is the main reason I chose to focus on Tacloban. It is badly hit (as were many other places as you rightly point out) but it is also a provincial capital, and it is the largest town in the immediate area. Because of this I figured that most of the international response would likely be directed there, and since it is mostly the international orgs that we tend to work with I figured the map data would be most useful there. Now, that being said I want to make it clear that the explanation above is not necessarily an argument for continuing to focus entirely on Tacloban, just merely an explanation of why I hadn't directed people elsewhere yet. I agree that we will need to spread out our efforts at some point, and that point may be approaching, the question is where to focus next. As I mentioned previously, I think the villages along the coast to the northeast will be hard hit (and due to their proximity to Tacloban will likely receive international aid). There are also villages along the coast to the south of Tacloban that will have been hit hard as well since the eye passed directly over them. The eye track will likely have done the most damage, or the area to the north of the eye track since the storm rotates counterclockwise as it moves westward. If anyone has better suggestions of where to spread out to I am certainly open to them. Like I said I am not saying we need to stay at Tacloban (and the surrounding area) just explaining why I was continuing focus there. I know the storm affected a lot to the west as well but I figured this would be trickier to map for two reasons. 1) it is a larger area with not such and obvious target for international aid, and 2) the wind speeds were lower to the west due to the storm being disrupted by the islands. As for the idea of mapping the area affected by the earthquake to the south, my understanding (and this could be wrong) was that most of what we could do remotely has already been done when the earthquake hit. So that is all of my reasoning at the current time for our current focus. I hope to begin hearing more concrete info from aid orgs today so I might redirect people when I hear from them, but for now my advice would be to try to continue with Tacloban (especially the low lying areas) and simultaneously spread out into the surrounding villages until/unless we get something concrete from an aid org. - -AndrewBuck On 11/09/2013 05:25 AM, Jean-Guilhem Cailton wrote: Hi, According to Al Jazeera, the death toll could be very high, sadly. And several millions of people have been affected. I'd like to remind that an often-mentioned weakness of OSM is the uneven quality of the coverage, and that it is not because you have a hammer that everything is a nail. So, while Tacloban was indeed hit very badly, and a detailed building map there is undoubtedly useful, it might also be useful if some of the mappers who wish to contribute took a broader view, to map, for example, some of the roads and villages that are visible on (sometimes recent) high resolution Bing imagery (http://osmph.github.io/Imagery_Coverage_Map/), but sometimes still unmapped in OSM. (Not to mention the rivers). GNS (http://wiki.openstreetmap.org/wiki/GNS) can also be a good source for names, even if it sometimes includes old versions of duplicated nodes with inaccurate location. High resolution imagery can be useful to tell which is right in these cases. Best wishes, Jean-Guilhem -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSfjttAAoJEK7RwIfxHSXbuyAQAJ7RN1Tqh04GWL0Gb03Tb+nQ Z4sIRt4Z3wBdOte8MjB3B+W8zGYtUw3kwfbb3DV8tcdKpEiHzjc2+GrjLgoLzZCe
Re: [talk-ph] [HOT] Typhoon Haiyan Mapping Progress
In response to the active map ups on Yolanda crisis areas, I will be updating the Garmin Routable maps based on OSM daily until needed. This is in case an up-to-date GPS offline map may be needed by our field relief volunteers. http://www.s1expeditions.com/p/openstreetmaps.html Ervin Malicdem for Schadow1 Expeditions - A Filipino must not be a stranger to his own motherland. http://www.s1expeditions.com On Nov 10, 2013 12:08 PM, Eugene Alvin Villar sea...@gmail.com wrote: Hello everyone, There are 2 additional HOT Tasks that have been created: 1. http://tasks.hotosm.org/job/339 - Mapping villages in Samar and Leyte (just the residential areas and roads, no need for buildings) 2. http://tasks.hotosm.org/job/340 - Mapping in detail selected areas that are known to have been highly affected by the typhoon On Sat, Nov 9, 2013 at 9:41 PM, Andrew Buck andrew.r.b...@gmail.comwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I agree that wider coverage will be needed and I had hoped that by now we would have a better indication of where to map as well. My reason for staying with Tacloban for so long was largely due to lack of knowing where else to shift focus to (although I did allude to this a bit by suggesting the other villages on the coast northeast of Tacloban), more importantly due to a second fact... When we map an area, it is only really useful for us to map areas that the aid organizations we work with will be responding to. For the aid organizations that don't know about, or don't know how to use, our map; then no matter how good the coverage is, it doesn't help them. This is the main reason I chose to focus on Tacloban. It is badly hit (as were many other places as you rightly point out) but it is also a provincial capital, and it is the largest town in the immediate area. Because of this I figured that most of the international response would likely be directed there, and since it is mostly the international orgs that we tend to work with I figured the map data would be most useful there. Now, that being said I want to make it clear that the explanation above is not necessarily an argument for continuing to focus entirely on Tacloban, just merely an explanation of why I hadn't directed people elsewhere yet. I agree that we will need to spread out our efforts at some point, and that point may be approaching, the question is where to focus next. As I mentioned previously, I think the villages along the coast to the northeast will be hard hit (and due to their proximity to Tacloban will likely receive international aid). There are also villages along the coast to the south of Tacloban that will have been hit hard as well since the eye passed directly over them. The eye track will likely have done the most damage, or the area to the north of the eye track since the storm rotates counterclockwise as it moves westward. If anyone has better suggestions of where to spread out to I am certainly open to them. Like I said I am not saying we need to stay at Tacloban (and the surrounding area) just explaining why I was continuing focus there. I know the storm affected a lot to the west as well but I figured this would be trickier to map for two reasons. 1) it is a larger area with not such and obvious target for international aid, and 2) the wind speeds were lower to the west due to the storm being disrupted by the islands. As for the idea of mapping the area affected by the earthquake to the south, my understanding (and this could be wrong) was that most of what we could do remotely has already been done when the earthquake hit. So that is all of my reasoning at the current time for our current focus. I hope to begin hearing more concrete info from aid orgs today so I might redirect people when I hear from them, but for now my advice would be to try to continue with Tacloban (especially the low lying areas) and simultaneously spread out into the surrounding villages until/unless we get something concrete from an aid org. - -AndrewBuck On 11/09/2013 05:25 AM, Jean-Guilhem Cailton wrote: Hi, According to Al Jazeera, the death toll could be very high, sadly. And several millions of people have been affected. I'd like to remind that an often-mentioned weakness of OSM is the uneven quality of the coverage, and that it is not because you have a hammer that everything is a nail. So, while Tacloban was indeed hit very badly, and a detailed building map there is undoubtedly useful, it might also be useful if some of the mappers who wish to contribute took a broader view, to map, for example, some of the roads and villages that are visible on (sometimes recent) high resolution Bing imagery (http://osmph.github.io/Imagery_Coverage_Map/), but sometimes still unmapped in OSM. (Not to mention the rivers). GNS (http://wiki.openstreetmap.org/wiki/GNS) can also be a good source for names, even if it
Re: [OSM-talk-be] Cartopartie Tournai (Belgique) samedi 09 novembre
Bonjour Nicolas, Nous essayons effectivement de prendre des photos. Pendant 2 jours, nous avions 6 stagiaires de Belgique et de Lille qui ont découvert le fonctionnement et le potentiel d'OSM, potentiel technique mais aussi social et territorial. Aujourd'hui normalement NoTélé, la tv locale doit venir faire un reportage. Nous publierons aussi les contenus sur le site : http://criemouscron.be/cooptic/wakka.php?wiki=CartoCollective . Tu trouveras les liens ensuite vers les photos avant après. Ce qui est dommage, vue de Bretagne, c'est le cadastre non numérisé et pas de fond orthophoto librement réutilisables pour cartographier plus efficacement et plus rapidement. J'ai vu tes centres d'investissement, si tu peux faire quelque chose ce serait super ! Cela fait trois fois cette année que j'interviens en Belgique dans des lieux différents et j'y prends goût. J'ai fait une petite liste de discussion, pas pour contourner l'officielle talk-be mais pour leur proposer un petit groupe de départ, en français pour commencer à échanger entre eux. Nous parlons bien sûr de talk-be qui pour certains sera un second palier. je pense que l'équipe de Cooptic.be est elle très motivée pour être un lieu de formation et relais en belgique. Et c'est avec plaisir que nous posterons les infos sur votre prochain site. Belle initiative en tous cas ! Merci pour les encouragements et à très bientôt. On vous tient au courant des résultats. Le 08/11/13 10:02, Nicolas Pettiaux a écrit : Le 08/11/13 08:46, Louis-Julien de la Bouëre a écrit : Bonjour Louis-Julien, Merci beaucoup pour l'information et bravo. Serai-t-il possible de faire une petit reportage vidéo, peut-être accompagné d'un écrit et de photos, précisant ce que vous aurez fait pendant la journée, comment vous l'aurez fait, quelles sont les impressions des participants, si ils sont prêts à poursuivre indépendamment de l'activité voire à transmettre le message et inviter leurs connaissances à contribuer à OSM ... Ce serait chouette à rajouter dans le futur proche au site osm.be que Ben fait; Merci et plein de souhaits d'une très bonne activité, Cordialement, Nicolas-- Nicolas Pettiaux - gsm +32 496 24 55 01 - nico...@pettiaux.be lepacte.be - 2013.rmll.info - euroscipy.org -- Louis-Julien de la Bouëre Association Tiriad ljbou...@tiriad.org www.tiriad.org Portable : 06 58 79 80 56 Twitter : @assotiriad Skype : tiloul29 attachment: ljbouere.vcf___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] AGIV Crab Import : gebruik van meerdere lagen
Die bedenking maakte ik me gisteren ook. In het geval van Urbis hebben we bestanden ter beschikking gesteld met een hele gemeente tegelijk en dan zit je met 2 lagen, maar als je die straat per straat binnenkrijgt via remote control, kan je ze toch meteen in je actieve laag binnenhalen? Wat je wel zou kunnen doen, is gebruik maken van de todoplugin, om te zorgen dat je ze allemaal behandeld hebt voordat je gaat doorsturen naar de server. Jo Op 9 november 2013 07:55 schreef Marc Gemis marc.ge...@gmail.com: Om nog even terug te komen op het gebruik van 2 lagen bij de import van Crab data. Wat is het nut als we toch de volledige laag in 1 keer copieren naar de laag met osm gegevens ? Ik begrijp het nut als je maar een deel van de import laag zou copieren (zoals bij bushaltes of beschermde monumenten), maar niet als alles in 1 keer overgenomen wordt m ___ 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-be] AGIV Crab Import : gebruik van meerdere lagen
Wat je ook kan doen is lagen samenvoegen (merge). Jo Op 9 november 2013 10:04 schreef Jo winfi...@gmail.com: Die bedenking maakte ik me gisteren ook. In het geval van Urbis hebben we bestanden ter beschikking gesteld met een hele gemeente tegelijk en dan zit je met 2 lagen, maar als je die straat per straat binnenkrijgt via remote control, kan je ze toch meteen in je actieve laag binnenhalen? Wat je wel zou kunnen doen, is gebruik maken van de todoplugin, om te zorgen dat je ze allemaal behandeld hebt voordat je gaat doorsturen naar de server. Jo Op 9 november 2013 07:55 schreef Marc Gemis marc.ge...@gmail.com: Om nog even terug te komen op het gebruik van 2 lagen bij de import van Crab data. Wat is het nut als we toch de volledige laag in 1 keer copieren naar de laag met osm gegevens ? Ik begrijp het nut als je maar een deel van de import laag zou copieren (zoals bij bushaltes of beschermde monumenten), maar niet als alles in 1 keer overgenomen wordt m ___ 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
[OSM-talk-be] AGIV datasets, gemeente grezen
Beste, Ik zie dat AGIV tegenwoordig meer data ter download beschikbaar stelt. Voor de volledige catalogus zie: https://download.agiv.be/Catalogus Als die waar geen slotje voor staat zijn te downloaden. Ze zijn blijkbaar ook allemaal onder de zelfde licentie als CRAB, het document dat er bij met de gebruiksvoorwaarde heeft dezelfde tekst als bij CRAB. Het gaat vooral om luchtfoto's, maar bv ook gemeentegrenzen: https://download.agiv.be/Producten/Detail?id=10title=Voorlopig_referentiebestand_gemeentegrenzen Ik heb eens effe die shapefiles gedownload, en die geven heel schoon de gemeente grezen, beter als die dat we nu hebben. Ben, kun je eens horen of we al die dingen echt kunnen gebruiken? Is dat iets dat we willen importeren? Er staan blijkbaar zowel gemeentes, arrodisementen, provincies als het gewest in. Kurt ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] Es weihnachtet wieder sehr ...
Hello Pieren I am (as you) not very interested in Christmas trees, but I got a little offended by the tone of your answer to the OP. Please stay mellow, even when some Germans (was it necessary to stress the nationality?) map Christmas trees in your country. Pieren pier...@gmail.com wrote on Fri, 8 Nov 2013 14:06:48 +0100: Good point. Since it is not verifiable 92% of the time, it has nothing to do in OSM. Just of curiosity: Can you point to me to the place where a consensus about this has been documented? We have several features in the database which are either - temporary and reoccurring OR - temporary and not reoccurring and thus - not verifiable (never) OR - verifiable, but verifiable less than 100% of the time Those features should all be deleted? Or is it a bit more nuanced than that? Nils ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Pipeline proposal vs PODS
Hi, As suggested on the talk page of the PipelineExtension proposal, it should be built according to the PODS data model. http://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension http://www.pods.org PODS is a geographical data model to help data exchange between companies who operate pipelines. It would be great that OSM can provide compatible data. But it seems to be a bit complex to deal with PODS and I'm not so familiar with it. Is someone knowledgeable about it and would like to help us ? Thanks. *François Lacombe* francois dot lacombe At telecom-bretagne dot eu http://www.infos-reseaux.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planet History file available
Thanks! here the file https://dl.dropboxusercontent.com/u/1969597/matera.osh.gz and here the sequence of command used wget https://dl.dropboxusercontent.com/u/1969597/matera.osh.gz cat history.style EOF node,way osm_user text node,way osm_uidint8 node,way osm_versionint8 node,way osm_timestamp text EOF createdb osmhistorydb echo CREATE EXTENSION postgis;CREATE EXTENSION hstore;CREATE EXTENSION btree_gist | psql osmhistorydb osm2pgsql -d osmhistorydb -m -x -k -S history.style matera.osh.gz and here the error from osm2pgsql Sharing dense sparse Node-cache: cache=800MB, maxblocks=102400*8192, allocation method=3 Mid: Ram, scale=100 Reading in file: matera.osh.gz osm2pgsql: parse-xml2.c:103: StartElement: Assertion `xlon' failed. Aborted (core dumped) the file history.style contains this configuration and the file is here On Thu, Nov 7, 2013 at 9:02 AM, Jochen Topf joc...@remote.org wrote: I don't know either. We need more information to help you debug this. For starters the actual command lines you used and the files you created. Jochen On Wed, Nov 06, 2013 at 12:28:28PM +0100, Maurizio Napolitano wrote: Date: Wed, 6 Nov 2013 12:28:28 +0100 From: Maurizio Napolitano napoo...@gmail.com To: Jochen Topf joc...@remote.org Cc: OSM Talk talk@openstreetmap.org Subject: Re: [OSM-talk] Planet History file available Hi Jochen I used your file without problem with osm-history-splitter and also osm-history-import With this tools i created an extraction of a region. Now i used it also with osm2pgsql with this syntax osm2pgsql -d osmh -u -m -x -k -S history.style file.osh the file history.style contains this configuration node,way osm_user text node,way osm_uidint8 node,way osm_versionint8 node,way osm_timestamp text The import fails with this message Reading in file: /home/napo/Desktop/file.osh osm2pgsql: parse-xml2.c:101: StartElement: Assertion `xlon' failed. Aborted (core dumped) I don't know if this is my fault or from the file Thanks On Mon, Nov 4, 2013 at 9:25 AM, Jochen Topf joc...@remote.org wrote: Due to popular demand I have made a planet file with full history available at http://data.openstreetmapdata.com/planet-history-2013-11-02.osh.pbf The file has about 37 GB, it's MD5 is 22169f0f997391b090df546769eb2357. This was generated from the last official history and all the daily diffs until two days ago. THIS IS NOT AN OFFICIAL HISTORY FILE. I haven't tested it or verified that my code that generates this is doing the right thing, so no guarantees. (On the other hand there is not much to it, really, just collect all the objects in the planet and change files and put them in the right order.) Apply reasonable caution when using it. If there is demand I can make a osm.bz2 version available, too. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Maurizio Napo Napolitano http://de.straba.us -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 -- Maurizio Napo Napolitano http://de.straba.us ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planet History file available
I don't think you can just use a history file with osm2pgsql. The history file contains deleted objects and objects in several versions. You have to use the history renderer: https://github.com/MaZderMind/osm-history-renderer Jochen On Sat, Nov 09, 2013 at 03:33:58PM +0100, Maurizio Napolitano wrote: Date: Sat, 9 Nov 2013 15:33:58 +0100 From: Maurizio Napolitano napoo...@gmail.com To: Jochen Topf joc...@remote.org Cc: OSM Talk talk@openstreetmap.org Subject: Re: [OSM-talk] Planet History file available Thanks! here the file https://dl.dropboxusercontent.com/u/1969597/matera.osh.gz and here the sequence of command used wget https://dl.dropboxusercontent.com/u/1969597/matera.osh.gz cat history.style EOF node,way osm_user text node,way osm_uidint8 node,way osm_versionint8 node,way osm_timestamp text EOF createdb osmhistorydb echo CREATE EXTENSION postgis;CREATE EXTENSION hstore;CREATE EXTENSION btree_gist | psql osmhistorydb osm2pgsql -d osmhistorydb -m -x -k -S history.style matera.osh.gz and here the error from osm2pgsql Sharing dense sparse Node-cache: cache=800MB, maxblocks=102400*8192, allocation method=3 Mid: Ram, scale=100 Reading in file: matera.osh.gz osm2pgsql: parse-xml2.c:103: StartElement: Assertion `xlon' failed. Aborted (core dumped) the file history.style contains this configuration and the file is here On Thu, Nov 7, 2013 at 9:02 AM, Jochen Topf joc...@remote.org wrote: I don't know either. We need more information to help you debug this. For starters the actual command lines you used and the files you created. Jochen On Wed, Nov 06, 2013 at 12:28:28PM +0100, Maurizio Napolitano wrote: Date: Wed, 6 Nov 2013 12:28:28 +0100 From: Maurizio Napolitano napoo...@gmail.com To: Jochen Topf joc...@remote.org Cc: OSM Talk talk@openstreetmap.org Subject: Re: [OSM-talk] Planet History file available Hi Jochen I used your file without problem with osm-history-splitter and also osm-history-import With this tools i created an extraction of a region. Now i used it also with osm2pgsql with this syntax osm2pgsql -d osmh -u -m -x -k -S history.style file.osh the file history.style contains this configuration node,way osm_user text node,way osm_uidint8 node,way osm_versionint8 node,way osm_timestamp text The import fails with this message Reading in file: /home/napo/Desktop/file.osh osm2pgsql: parse-xml2.c:101: StartElement: Assertion `xlon' failed. Aborted (core dumped) I don't know if this is my fault or from the file Thanks On Mon, Nov 4, 2013 at 9:25 AM, Jochen Topf joc...@remote.org wrote: Due to popular demand I have made a planet file with full history available at http://data.openstreetmapdata.com/planet-history-2013-11-02.osh.pbf The file has about 37 GB, it's MD5 is 22169f0f997391b090df546769eb2357. This was generated from the last official history and all the daily diffs until two days ago. THIS IS NOT AN OFFICIAL HISTORY FILE. I haven't tested it or verified that my code that generates this is doing the right thing, so no guarantees. (On the other hand there is not much to it, really, just collect all the objects in the planet and change files and put them in the right order.) Apply reasonable caution when using it. If there is demand I can make a osm.bz2 version available, too. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Maurizio Napo Napolitano http://de.straba.us -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 -- Maurizio Napo Napolitano http://de.straba.us -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Admin boundaries - data consumers
Hi All, A few days ago there was a thread about the pros/cons of moving admin boundaries to a new database. I'm not going to give my opinion on this as the thread has now fizzled out, but I will suggest that decisions like this should involve as many of our end data users as possible (we have moved beyond a small isolated project). One such user is mySoicety. Check out the video of their MapIt Global talk at http://lanyrd.com/2013/sotm/scpkhg/ to see how they use boundaries from OSM. Perhaps some way of tracking our data consumers would be useful. Or maybe we need a way for them to say which tags they are interested in so that they can receive mail just about these. Regards, Rob ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin boundaries - data consumers
On Sat, Nov 09, 2013 at 03:25:35PM +, Rob Nickerson wrote: A few days ago there was a thread about the pros/cons of moving admin boundaries to a new database. I'm not going to give my opinion on this as the thread has now fizzled out, but I will suggest that decisions like this should involve as many of our end data users as possible (we have moved beyond a small isolated project). One such user is mySoicety. Check out the video of their MapIt Global talk at http://lanyrd.com/2013/sotm/scpkhg/ to see how they use boundaries from OSM. Perhaps some way of tracking our data consumers would be useful. Or maybe we need a way for them to say which tags they are interested in so that they can receive mail just about these. That's the wrong way around. If you are using OSM data it is your job to keep abreast of developments in OSM. A volunteer project like OSM can't keep track of all their customers the way a commercial company might. That's not to say that we should change things willy-nilly, we should announce changes beforehand etc. But we do that on our mailing lists etc. And yes, that puts a lot of burden on the users of OSM data, but they get it for free, so there. (Of course there are companies who will do this job for you, ie follow OSM development while maintaining stable data formats etc. to their customers.) Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin boundaries - data consumers
That does come across as a little arrogant, Jochen. The mappers and the data consumers need each other; neither can flourish without the other. A symbiotic model would be more accurate. As you say, we shouldn't change things willy-nilly, but to say bluntly it's your problem to all data consumers and to express such a dismissive attitude towards their feedback is misrepresenting the relationship somewhat. Colin On 2013-11-09 18:25, Jochen Topf wrote: On Sat, Nov 09, 2013 at 03:25:35PM +, Rob Nickerson wrote: A few days ago there was a thread about the pros/cons of moving admin boundaries to a new database. I'm not going to give my opinion on this as the thread has now fizzled out, but I will suggest that decisions like this should involve as many of our end data users as possible (we have moved beyond a small isolated project). One such user is mySoicety. Check out the video of their MapIt Global talk at http://lanyrd.com/2013/sotm/scpkhg/ [1] to see how they use boundaries from OSM. Perhaps some way of tracking our data consumers would be useful. Or maybe we need a way for them to say which tags they are interested in so that they can receive mail just about these. That's the wrong way around. If you are using OSM data it is your job to keep abreast of developments in OSM. A volunteer project like OSM can't keep track of all their customers the way a commercial company might. That's not to say that we should change things willy-nilly, we should announce changes beforehand etc. But we do that on our mailing lists etc. And yes, that puts a lot of burden on the users of OSM data, but they get it for free, so there. (Of course there are companies who will do this job for you, ie follow OSM development while maintaining stable data formats etc. to their customers.) Jochen Links: -- [1] http://lanyrd.com/2013/sotm/scpkhg/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin boundaries - data consumers
On 2013-11-09 15:25, Rob Nickerson wrote: Hi All, A few days ago there was a thread about the pros/cons of moving admin boundaries to a new database. I'm not going to give my opinion on this as the thread has now fizzled out, but I will suggest that decisions like this should involve as many of our end data users as possible (we have moved beyond a small isolated project). One such user is mySoicety. Check out the video of their MapIt Global talk at http://lanyrd.com/2013/sotm/scpkhg/ to see how they use boundaries from OSM. Note MySociety do not use boundaries from OSM for the UK for their projects. Instead they just use boundaries from OS OpenData. I think this is an example of where a separate database makes sense. ie with the complete, up to date OS OpenData boundaries, in a format compatible with OSM. Yes, some of the OS OpenData boundaries have been added to OSM. But they are very incomplete/inconsistent, and often accidentally edited or broken etc. And probably out of date if the official boundaries have changed anywhere. So generally not as useful or reliable as just using the OS OpenData. Craig ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin boundaries - data consumers
On Nov 9, 2013 5:39 PM, Jochen Topf joc...@remote.org wrote; On Sat, Nov 09, 2013 at 03:25:35PM +, Rob Nickerson wrote: Perhaps some way of tracking our data consumers would be useful. Or maybe we need a way for them to say which tags they are interested in so that they can receive mail just about these. That's the wrong way around. If you are using OSM data it is your job to keep abreast of developments in OSM. A volunteer project like OSM can't keep track of all their customers the way a commercial company might. That's not to say that we should change things willy-nilly, we should announce changes beforehand etc. But we do that on our mailing lists etc. And yes, that puts a lot of burden on the users of OSM data, but they get it for free, so there. At the moment it is indeed not that easy for data consumers to keep track of changes. The tagging mailing list had quite high traffic, and most posts there are not directly relevant for data consumers. I have been thinking about how we can improve this situation. Would it be an idea to create a separate mailing list that just serves to announce changes in the tagging scheme? That way we can separate the discussion on creating tagging schemes (which data consumers can ignore if they wish) from the announcements of new schemes. Typically changes correspond to accepted proposals on the tagging mailing list. We could add to the procedure of proposing tags that the proposer should make an announcement to this list when hits proposal is accepted. -- Matthijs ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin boundaries - data consumers
I am sorry if I came across as arrogant or dismissive. This is absolutely not my intention. Actually I think we are in violent agreement here, mappers and data consumers must talk and help each other. And where we do that is on our mailing lists, forums, etc. What I was arguing against is somehow feeling responsible for data users who take our data, never talk to us and then think it is our job to tell them when something changes. That is how I understood Rob's argument and that isn't something I feel we have to do. If, to keep with Rob's example, MySociety wants to know about boundary tagging changes in OSM, they can get this info by participating in the OSM community and I'd welcome their input as a user of the data. But they have to be active themselves in at least a small way, it is not our job to somehow keep track of what they are using from OSM and tell them if something changes that they would want to know about. Jochen On Sat, Nov 09, 2013 at 06:55:53PM +0100, Colin Smale wrote: Date: Sat, 09 Nov 2013 18:55:53 +0100 From: Colin Smale colin.sm...@xs4all.nl To: talk@openstreetmap.org Subject: Re: [OSM-talk] Admin boundaries - data consumers That does come across as a little arrogant, Jochen. The mappers and the data consumers need each other; neither can flourish without the other. A symbiotic model would be more accurate. As you say, we shouldn't change things willy-nilly, but to say bluntly it's your problem to all data consumers and to express such a dismissive attitude towards their feedback is misrepresenting the relationship somewhat. Colin On 2013-11-09 18:25, Jochen Topf wrote: On Sat, Nov 09, 2013 at 03:25:35PM +, Rob Nickerson wrote: A few days ago there was a thread about the pros/cons of moving admin boundaries to a new database. I'm not going to give my opinion on this as the thread has now fizzled out, but I will suggest that decisions like this should involve as many of our end data users as possible (we have moved beyond a small isolated project). One such user is mySoicety. Check out the video of their MapIt Global talk at http://lanyrd.com/2013/sotm/scpkhg/ [1] to see how they use boundaries from OSM. Perhaps some way of tracking our data consumers would be useful. Or maybe we need a way for them to say which tags they are interested in so that they can receive mail just about these. That's the wrong way around. If you are using OSM data it is your job to keep abreast of developments in OSM. A volunteer project like OSM can't keep track of all their customers the way a commercial company might. That's not to say that we should change things willy-nilly, we should announce changes beforehand etc. But we do that on our mailing lists etc. And yes, that puts a lot of burden on the users of OSM data, but they get it for free, so there. (Of course there are companies who will do this job for you, ie follow OSM development while maintaining stable data formats etc. to their customers.) Jochen Links: -- [1] http://lanyrd.com/2013/sotm/scpkhg/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin boundaries - data consumers
On Sat, Nov 09, 2013 at 07:28:16PM +, Matthijs Melissen wrote: On Nov 9, 2013 5:39 PM, Jochen Topf joc...@remote.org wrote; On Sat, Nov 09, 2013 at 03:25:35PM +, Rob Nickerson wrote: Perhaps some way of tracking our data consumers would be useful. Or maybe we need a way for them to say which tags they are interested in so that they can receive mail just about these. That's the wrong way around. If you are using OSM data it is your job to keep abreast of developments in OSM. A volunteer project like OSM can't keep track of all their customers the way a commercial company might. That's not to say that we should change things willy-nilly, we should announce changes beforehand etc. But we do that on our mailing lists etc. And yes, that puts a lot of burden on the users of OSM data, but they get it for free, so there. At the moment it is indeed not that easy for data consumers to keep track of changes. The tagging mailing list had quite high traffic, and most posts there are not directly relevant for data consumers. I have been thinking about how we can improve this situation. Would it be an idea to create a separate mailing list that just serves to announce changes in the tagging scheme? That way we can separate the discussion on creating tagging schemes (which data consumers can ignore if they wish) from the announcements of new schemes. Typically changes correspond to accepted proposals on the tagging mailing list. We could add to the procedure of proposing tags that the proposer should make an announcement to this list when hits proposal is accepted. Unfortunately the tagging discussions and voting doesn't actually matter that much. It is not important what some people think or have agreed on what tags should or should not be used in what situations. What is important to data users is how the tags are *actually* used in the database. And I don't see that much correlation between actual use and this proposal procedure. A change in an editor configuration might have more impact than a vote in the proposal process. This situation isn't great, but it is what we have. Data users have to familiarize themselves with what's there. They have to read wiki pages, look at taginfo, look at discussions on mailing lists and they have to try out different interpretations of the data and find out what works for them. There is no shortcut to this process. There are many ways of making this easier, one is writing better wiki documentation, one is finding better ways of putting these information into taginfo. But highlighting results from a proposal process that doesn't matter all that much, isn't one of them. (btw I would welcome some university research on whether my assertions above are actually true. I'd love to have some data that tells us how tagging in the actual database is driven by tagging proposals, or editor choices, or people just inventing tags they like, or local fashions etc.) Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin boundaries - data consumers
Jochen Topf said: I am sorry if I came across as arrogant or dismissive. This is absolutely not my intention. No offence taken. As you say, we are in agreement here, mappers and data consumers must talk and help each other. What I was arguing against is somehow feeling responsible for data users who take our data, never talk to us and then think it is our job to tell them when something changes. That is how I understood Rob's argument Perhaps I misled you as I agree 100% that the relationship has to be two way. I'm just wondering aloud how we can improve out side of that conversation / relationship. As we all know the mailing lists can be quite unfriendly to external parties. It's an interesting question as we need to balance providing data consumers with advanced notice of big changes and still be able to act quickly. My experience with developing tagging schemas is that it helps to slow the process down, giving everyone time to consider the tag and provide comments. I would have liked more involvement from someone who actually uses the data (in this case a Routing service provider) but as you say they have to be willing to join the conversation too. We cannot slow things down too much :-) Best, Rob ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Planet History file available
yes, I know but it worked until the last edition of history file. In any case it's better if I switch my code to the osm-history-importer made by peter. thanks On Sat, Nov 9, 2013 at 3:50 PM, Jochen Topf joc...@remote.org wrote: I don't think you can just use a history file with osm2pgsql. The history file contains deleted objects and objects in several versions. You have to use the history renderer: https://github.com/MaZderMind/osm-history-renderer Jochen On Sat, Nov 09, 2013 at 03:33:58PM +0100, Maurizio Napolitano wrote: Date: Sat, 9 Nov 2013 15:33:58 +0100 From: Maurizio Napolitano napoo...@gmail.com To: Jochen Topf joc...@remote.org Cc: OSM Talk talk@openstreetmap.org Subject: Re: [OSM-talk] Planet History file available Thanks! here the file https://dl.dropboxusercontent.com/u/1969597/matera.osh.gz and here the sequence of command used wget https://dl.dropboxusercontent.com/u/1969597/matera.osh.gz cat history.style EOF node,way osm_user text node,way osm_uidint8 node,way osm_versionint8 node,way osm_timestamp text EOF createdb osmhistorydb echo CREATE EXTENSION postgis;CREATE EXTENSION hstore;CREATE EXTENSION btree_gist | psql osmhistorydb osm2pgsql -d osmhistorydb -m -x -k -S history.style matera.osh.gz and here the error from osm2pgsql Sharing dense sparse Node-cache: cache=800MB, maxblocks=102400*8192, allocation method=3 Mid: Ram, scale=100 Reading in file: matera.osh.gz osm2pgsql: parse-xml2.c:103: StartElement: Assertion `xlon' failed. Aborted (core dumped) the file history.style contains this configuration and the file is here On Thu, Nov 7, 2013 at 9:02 AM, Jochen Topf joc...@remote.org wrote: I don't know either. We need more information to help you debug this. For starters the actual command lines you used and the files you created. Jochen On Wed, Nov 06, 2013 at 12:28:28PM +0100, Maurizio Napolitano wrote: Date: Wed, 6 Nov 2013 12:28:28 +0100 From: Maurizio Napolitano napoo...@gmail.com To: Jochen Topf joc...@remote.org Cc: OSM Talk talk@openstreetmap.org Subject: Re: [OSM-talk] Planet History file available Hi Jochen I used your file without problem with osm-history-splitter and also osm-history-import With this tools i created an extraction of a region. Now i used it also with osm2pgsql with this syntax osm2pgsql -d osmh -u -m -x -k -S history.style file.osh the file history.style contains this configuration node,way osm_user text node,way osm_uidint8 node,way osm_versionint8 node,way osm_timestamp text The import fails with this message Reading in file: /home/napo/Desktop/file.osh osm2pgsql: parse-xml2.c:101: StartElement: Assertion `xlon' failed. Aborted (core dumped) I don't know if this is my fault or from the file Thanks On Mon, Nov 4, 2013 at 9:25 AM, Jochen Topf joc...@remote.org wrote: Due to popular demand I have made a planet file with full history available at http://data.openstreetmapdata.com/planet-history-2013-11-02.osh.pbf The file has about 37 GB, it's MD5 is 22169f0f997391b090df546769eb2357. This was generated from the last official history and all the daily diffs until two days ago. THIS IS NOT AN OFFICIAL HISTORY FILE. I haven't tested it or verified that my code that generates this is doing the right thing, so no guarantees. (On the other hand there is not much to it, really, just collect all the objects in the planet and change files and put them in the right order.) Apply reasonable caution when using it. If there is demand I can make a osm.bz2 version available, too. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Maurizio Napo Napolitano http://de.straba.us -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 -- Maurizio Napo Napolitano http://de.straba.us -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-721-388298 -- Maurizio Napo Napolitano http://de.straba.us ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Admin boundaries - data consumers
On Sun, 10 Nov 2013 02:59:19 Craig Wallace wrote: Note MySociety do not use boundaries from OSM for the UK for their projects. Instead they just use boundaries from OS OpenData. I think this is an example of where a separate database makes sense. ie with the complete, up to date OS OpenData boundaries, in a format compatible with OSM. In my opinion this is an example where OSM data is broken and should be fixed. Andrew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Orchard vs farmland
Ah, esqueci de dizer que lavoura sazonal também é um nome dado pelo LABGEO. 2013/11/9 Fernando Trebien fernando.treb...@gmail.com Pessoal, O Augusto e eu estamos estudando como importar o mapa de vegetação do LABGEO na região de Porto Alegre e ele sugeriu importar as regiões marcadas pelo LABGEO como lavoura perene como landuse=orchard. Reli a definição no wiki (http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dorchard) e me parece que essa tradução é mais adequada do que a atual, pomar (que se restringe a árvores frutíferas). Da mesma forma, lavoura sazonal (onde é necessário replantar a cada ciclo) poderia ser uma tradução melhor para landuse=farmland ( http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dfarmland). O que acham? Alteramos a tradução? -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Orchard vs farmland
Deixar lavoura perene (ou permanente ou outro termo qualquer) não pode levar a classificar uma plantação de seringueira, por exemplo, como orchard? (Enquanto deveria ser restrito para plantações alimentícias) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Orchard vs farmland
Pra deixar mais claro: não pode levar a classificar plantações permanentes de plantas não-frutíferas como orchard? ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Orchard vs farmland
Lavoura fica melhor para farmland ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Áreas protegidas
Acabei de fazer uma importação de unidades de conservação. Os dados vêm do arquivo LIM_UNIDADE_CONSERVACAO_NAO_SNUC_A.shp da base cartográfica escala 250 mil do IBGE, ou seja, são informações que (suponho) o MMA e o ICMBio não coleta. Esses dados parecem bem piores que os dados do ICMBio que eu pretendo processar em breve. Em algumas dados que particularmente ruins, eu adicionei um comentário na tag fixme. Sinta-se à vontade para fazer alterações ou deletar algo que pareça não fazer sentido. A maioria das unidades ficam no sudeste, em particular há várias no entorno de Belo Horizonte. Um caso que eu vou deixar para o pessoal da região da divisa SP/MS/PR decidir é a tal da Reserva Estadual Pontal do Paranapanema, que parece só existir em teoria (a área contém apenas fazendas): http://www.openstreetmap.org/browse/relation/3317528 Para referência, esses são os chageset: http://www.openstreetmap.org/browse/changeset/18808365 http://www.openstreetmap.org/browse/changeset/18808320 http://www.openstreetmap.org/browse/changeset/18807980 Pretendo documentar a importação na wiki em breve. On Sun, 2013-11-03 at 09:35 -0500, Augusto Stoffel wrote: Há algum tempo eu falei em importar parques nacionais e outras áreas protegidas. Adicionei algumas unidades de conservação e uma terra indígena ao mapa (dados da base 250 mil do IBGE): http://www.openstreetmap.org/browse/relation/3300492 http://www.openstreetmap.org/browse/relation/3300496 http://www.openstreetmap.org/browse/way/243992224 http://www.openstreetmap.org/browse/way/244469951 Teríamos que decidir se a qualidade desses dados é suficiente para os nosso propósitos, e se as tags estão a contento (de acordo com https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area ). O principal refinamento a ser feito após a importação seria substituir os traçados que acompanham a orla de um rio ou oceano pelos traçados já existentes no OSM, usando uma relação (mas deixe as áreas acima como estão por enquanto para que os outros possam ver o original). Isso é algo que eu deixaria para as pessoas interessadas fazerem na redondeza das suas regiões. Adicionei a tag leisure=nature_reserve tanto aos parques quanto à terra indígena porque por ora o estilo padrão do OSM não renderiza a tag boundary=protected_area (e isso parece ser um bug aberto há anos). Quando isso for resolvido, aquelas tags podem ser removidas. Por fim, queria mencionar que eu estou tentando obter permissão para usar os dados do Ministério do Meio Ambiente e da FUNAI, que parecem ser um pouco mais completos que os do IGBE. Assim, talvez demore um pouco para eu começar a importação. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Áreas protegidas
Oi Augusto, Olhei por altos e me não encontrei nenhum problema. Acho apenas que essas duas reservas poderiam ser combinadas com elementos que já existiam no mapa: http://www.openstreetmap.org/browse/relation/3317529 http://www.openstreetmap.org/browse/relation/3317477 Apesar de ter marcado seus changesets com type=import, eu ainda assim recomendaria (fortemente) que você criasse um usuário específico para fazer importações de dados. É mais fácil rastreá-las depois fazendo dessa forma. O MMA e o ICMBio têm licenças restritas? Vindo através do IBGE, provavelmente jamais saberemos se os dados são provenientes delas ou não. Não nos isentaria de uma eventual reversão (acho), mas também acho extremamente improvável, dada a forma com que o IBGE respondeu nas nossas comunicações com eles. 2013/11/9 Augusto Stoffel arstof...@yahoo.com.br Acabei de fazer uma importação de unidades de conservação. Os dados vêm do arquivo LIM_UNIDADE_CONSERVACAO_NAO_SNUC_A.shp da base cartográfica escala 250 mil do IBGE, ou seja, são informações que (suponho) o MMA e o ICMBio não coleta. Esses dados parecem bem piores que os dados do ICMBio que eu pretendo processar em breve. Em algumas dados que particularmente ruins, eu adicionei um comentário na tag fixme. Sinta-se à vontade para fazer alterações ou deletar algo que pareça não fazer sentido. A maioria das unidades ficam no sudeste, em particular há várias no entorno de Belo Horizonte. Um caso que eu vou deixar para o pessoal da região da divisa SP/MS/PR decidir é a tal da Reserva Estadual Pontal do Paranapanema, que parece só existir em teoria (a área contém apenas fazendas): http://www.openstreetmap.org/browse/relation/3317528 Para referência, esses são os chageset: http://www.openstreetmap.org/browse/changeset/18808365 http://www.openstreetmap.org/browse/changeset/18808320 http://www.openstreetmap.org/browse/changeset/18807980 Pretendo documentar a importação na wiki em breve. On Sun, 2013-11-03 at 09:35 -0500, Augusto Stoffel wrote: Há algum tempo eu falei em importar parques nacionais e outras áreas protegidas. Adicionei algumas unidades de conservação e uma terra indígena ao mapa (dados da base 250 mil do IBGE): http://www.openstreetmap.org/browse/relation/3300492 http://www.openstreetmap.org/browse/relation/3300496 http://www.openstreetmap.org/browse/way/243992224 http://www.openstreetmap.org/browse/way/244469951 Teríamos que decidir se a qualidade desses dados é suficiente para os nosso propósitos, e se as tags estão a contento (de acordo com https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area ). O principal refinamento a ser feito após a importação seria substituir os traçados que acompanham a orla de um rio ou oceano pelos traçados já existentes no OSM, usando uma relação (mas deixe as áreas acima como estão por enquanto para que os outros possam ver o original). Isso é algo que eu deixaria para as pessoas interessadas fazerem na redondeza das suas regiões. Adicionei a tag leisure=nature_reserve tanto aos parques quanto à terra indígena porque por ora o estilo padrão do OSM não renderiza a tag boundary=protected_area (e isso parece ser um bug aberto há anos). Quando isso for resolvido, aquelas tags podem ser removidas. Por fim, queria mencionar que eu estou tentando obter permissão para usar os dados do Ministério do Meio Ambiente e da FUNAI, que parecem ser um pouco mais completos que os do IGBE. Assim, talvez demore um pouco para eu começar a importação. ___ 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 -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] Wanderkarten von Russland
Am 08/nov/2013 um 15:40 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Das habe ich nicht gemacht. Verwendest Du kein PROCESSING RESAMPLE=BILINEAR beim hillshade? +1, es gibt da verschiedene Parameter an denen man drehen kann, zum einen beim Resamplen des shading bitmaps (nimm das Beste, wenn Du das nur einmal offline machst), und zum anderen schon vorher, wenn man beim Umwandeln der Höhen ins Shading mit mehr Farbtiefe arbeitet (mehr Bit pro Pixel im tiff), was zwar die Files ziemlich aufbläht, aber für kleinere Ausschnitte geht das schon. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Falk Verlag zeigt auch OSM Karten
Moin, ich weiß nicht sicher, ob das hier schon thematisiert wurde. Die entsprechende Recherche fällt etwas schwer, da hier auch Mitstreiter mit dem Vornamen Falk mittun. Der Falk Verlag zeigt auf seiner Website fünf verschiedene OSM Styles - davon einen eigenen. Die Styles lassen sich über das Dropdown Menü Kartenansicht abrufen. Irgendwie hätte ich das und auch den Dank dafür nicht erwartet: Falk sagt an dieser Stelle Danke! an die vielen freiwilligen Helfer, die es mit ihrer großartigen Arbeit ermöglichen, dass wir Ihnen diese freie Karte anbieten können. http://www.falk.de/n-4665-OpenStreetMap_%28OSM%29 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RadioOSM: Wochennotiz Nr. 164
Peter Körner osm-li...@mazdermind.de wrote: Wir spalten grade den Blog vom Podcast ab, da der Podcast langsam erwachsen wird. Durch den Umzug sind jetzt alle bisherigen Links auf die Podcasts tot. Vielleicht kann man da was machen. Beispiel: http://blog.openstreetmap.de/2013/10/osmde023-und-benutzt-endlich-mal-das-verdammte-wiki/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Falk Verlag zeigt auch OSM Karten
Hallo, vor allen Dingen sollte man anbei noch erwähnen, dass der Stil von Falk in meinen Augen sehr gelungen ist. Leider ist der Datenbestand aber schon ein paar Monate alt. Gruß André ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Falk Verlag zeigt auch OSM Karten
On Saturday 09 November 2013, Tirkon wrote: Moin, ich weiß nicht sicher, ob das hier schon thematisiert wurde. Die entsprechende Recherche fällt etwas schwer, da hier auch Mitstreiter mit dem Vornamen Falk mittun. Der Falk Verlag zeigt auf seiner Website fünf verschiedene OSM Styles - davon einen eigenen. Die Styles lassen sich über das Dropdown Menü Kartenansicht abrufen. Irgendwie hätte ich das und auch den Dank dafür nicht erwartet: Ich hab die Karte, die dort unter dem Namen 'Falk OSM' gezeigt wird, schon mal im Juli in einem Thread zum Kompass-Verlag erwähnt. Die geht wohl zurück auf: http://hubermedia.de/ecmaps-bekommt-weltweites-kartenupdate/ Was vor allem auch interessant daran ist, dass dort auch eine ganze Reihe anderer offener Datenquellen eingegangen sind, es aber nur für OSM credits gibt. Es wäre also im Grunde ganz nett, wenn die auch für die übrigen Quellen ein paar nette Worte finden würden, vermutlich wissen die Leute von Falk aber im Detail garnicht, was da alles drin ist... Was das Alter der Daten betrifft ist 'Falk OSM' wohl vom letzten Jahr. Die 'Openstreetmap'-Karte scheint eine bunte Mischung verschiedener Zeitpunkte zu sein. -- Christoph Hormann http://www.imagico.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
Il 09 novembre 2013 08:31, Aury88 spacedrive...@gmail.com ha scritto:
ho ancora qualche dubbio sulla differenza tra ricalcare una mappa e il
posizionare i singoli punti. cosa intendi per sistematica?
Sistematica vuol dire che segue una certa procedura sempre uguale.
Come dici tu non sempre comunque si sfrutta il centraggio per posizionare
josm per poi mettere il punto in base alle immagini del terreno. io mi
sono
fidato delle coordinate prese da wikipedia, per esempio, per il
posizionamento dell'isolotto/scoglio La Canna [1] che sulle mappe di
bing
non è visibile mentre sulle mappe di google è abbastanza evidente. sono
abbastanza sicuro che le coordinate inserite su wikipedia siano prese da
google (ma potrebbero comunque essere prese da un GPS; wikipedia non c'era
la fonte delle coordinate purtroppo)
Mi hai dato una grande idea, si potrebbe proporre su Wikipedia di
aggiungere al template {{coord}} un parametro (opzionale, per non rompere i
template esistenti) che è appunto la fonte delle coordinate.
Per altro dato che Wikidata ora ha il tipo di dato Coordinate e su
Wikidata c'è sempre la possibilità di aggiungere ad ogni statement la fonte.
Inoltre la cosa darebbe la possibilità di sensibilizzare tutti rispetto al
problema.
Per quanto riguarda l'applicare un piccolo errore alle coordinate non
saprei se basta per evitare il copyviol...non penso sia comunque lecito o
non si sarebbero posti il problema di importare in automatico tutte le
coordinate da wikipedia (sarebbe bastato applicare a tutte un errore
random
di qualche centesimo di secondo)...
quindi non saprei come rispondere alla tua domanda sullo spostare in
maniera
automatica le coordinate ;forse alla fine non l'hanno fatto per questioni
etiche, inerenti l'inserimento di informazioni volutamente sbagliate, e
non
per altre legate al copyright...bho!
Infatti, inoltre la questione è che se si inserisce a mano un punto IMHO
non è più possibile capire se il contributo fondamentale al dato è stato
dato da (l'intelligenza del) l'utente o dal dato originale.
Se invece si aggiunge uno scostamento casuale in modo automatico allora i
dati nuovo sono sicuramente derivati da quelli di partenza.
Ciao,
C
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Standardizzazione toponimi bilingui della Sardegna ed adattamento al modello altoadesino
Forse il punto è proprio questo, che io (e penso tanti altri) normalmente *non* voglio vedere una mappa con tutti i nomi in una lingua, ma una mappa dove ogni posto porta il suo nome ufficiale. Questo vale particolarmente in Europa, dove un confine di stato non è mai lontano. Se poi desidero vedere tutto nella mia lingua, o in inglese, mi va bene, se c'è quest'opzione, in particolare per parti del mondo, che non utilizzano l'alfabeto latino. Ma questo deve essere un'opzione, non lo standard. 2013/11/8 andria osm andria_...@tiscali.it Il 08/11/2013 19:09, Alessandro Barbieri ha scritto: Un' altro tag per indicare la lingua parlata nel posto (con le % magari) e far fare al renderer il lavoro di mostrare la/le lingue basandosi su criteri oggettivi. ma secondo me la cosa è molto semplice e neanche dispendiosa. ad esempio con mapbox, che ricordo usa solo ed esclusivamente dati osm, posso scegliere tra diverse lingue. Qui visualizzo il pianeta con i nomi delle città in francese: https://a.tiles.mapbox.com/v3/andria.g7pd12dh/page.html?secure=1#7/17.868975338932746/103.65600585937499 ___ 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] Standardizzazione toponimi bilingui della Sardegna ed adattamento al modello altoadesino
Il 09/nov/2013 11:14 Volker Schmidt vosc...@gmail.com ha scritto: Forse il punto è proprio questo, che io (e penso tanti altri) normalmente non voglio vedere una mappa con tutti i nomi in una lingua, ma una mappa dove ogni posto porta il suo nome ufficiale. Volker, il punto è proprio questo: qual è il nome ufficiale? All'inizio di questo thread si diceva di dover usare uno/due/tre nomi nel campo name. A me sembra un'assurdità. Ciao /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Standardizzazione toponimi bilingui della Sardegna ed adattamento al modello altoadesino
On 2013-11-09 at 11:30:23 +0100, Francesco Pelullo wrote: Volker, il punto è proprio questo: qual è il nome ufficiale? non è banale stabilirlo, ma in generale dei buoni candidati sono quanto dichiarato dal comune stesso, oppure il nome presente negli elenchi del ministero dell'Interno (ovviamente, non sempre coincidono) All'inizio di questo thread si diceva di dover usare uno/due/tre nomi nel campo name. A me sembra un'assurdità. capita che il nome ufficiale sia in due lingue (non so se esistano anche casi con tre lingue), in quel caso non usarle entrambe sarebbe l'assurdità -- Elena ``of Valhalla'' ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Standardizzazione toponimi bilingui della Sardegna ed adattamento al modello altoadesino
On 11/09/2013 11:36 AM, Volker Schmidt wrote: All'inizio di questo thread si diceva di dover usare uno/due/tre nomi nel campo name. A me sembra un'assurdità. Invece in una zona bi-lingue o trilingue a me sembra completamente normale Volker anche a me sembra normale:-) :-) :-) :-) :-) :-) :-) ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
per me non c'è dubbio che siamo lavorando sistematicamente, però concordo che non siamo copiando coordinate, ma mappando con aiuto delle indicazioni date da wikipedia. Penso che va bene la nostra procedura. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
Il 09 novembre 2013 10:33, Cristian Consonni kikkocrist...@gmail.com
ha scritto:
Il 09 novembre 2013 08:31, Aury88 spacedrive...@gmail.com ha scritto:
sono abbastanza sicuro che le coordinate inserite su wikipedia siano prese da
google (ma potrebbero comunque essere prese da un GPS; wikipedia non c'era
la fonte delle coordinate purtroppo)
Mi hai dato una grande idea, si potrebbe proporre su Wikipedia di aggiungere
al template {{coord}} un parametro (opzionale, per non rompere i template
esistenti) che è appunto la fonte delle coordinate.
Per altro dato che Wikidata ora ha il tipo di dato Coordinate e su
Wikidata c'è sempre la possibilità di aggiungere ad ogni statement la fonte.
Inoltre la cosa darebbe la possibilità di sensibilizzare tutti rispetto al
problema.
Ecco qua:
https://it.wikipedia.org/wiki/Discussioni_template:Coord#Aggiunta_di_un_parametro_.22fonte.22_al_template
C
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: R: R: Dati stazioni elettriche di Terna
Grazie delle segnalazioni. Ho corretto il wiki. Per la trasformazione di sub_station in substation pensavo di fare una query e una correzione massiva. Saluti Fabrizio Il giorno 08 novembre 2013 17:23, bredy bredy...@yahoo.it ha scritto: leggendo la pagina Piemonte/Stazioni_elettriche http://wiki.openstreetmap.org/wiki/Piemonte/Stazioni_elettriche ho notato che sono ancora riportati i tag ormai deprecati station e sub_station. Sarebbe il caso di aggiornare. -- View this message in context: http://gis.19327.n5.nabble.com/Dati-stazioni-elettriche-di-Terna-tp5784343p5784681.html Sent from the Italy General mailing list archive at Nabble.com. ___ 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] R: R: R: Dati stazioni elettriche di Terna
Credo che questo lavoro sia da fare per piccole aree conosciute o se le hai fatte tu in quanto l'uso precedente è stato un po' ambiguo in passato, almeno così ho letto. Una risposta più precisa dagli esperti in materia, altrimenti lo avrebbero fatto a livello superiore. Vedrò se riesco avere notizie da chi ha scritto la proposta approvata. Da: Fabrizio Tambussa ftambu...@gmail.com A: openstreetmap list - italiano talk-it@openstreetmap.org Inviato: Sabato 9 Novembre 2013 18:24 Oggetto: Re: [Talk-it] R: R: R: Dati stazioni elettriche di Terna Grazie delle segnalazioni. Ho corretto il wiki. Per la trasformazione di sub_station in substation pensavo di fare una query e una correzione massiva. Saluti Fabrizio Il giorno 08 novembre 2013 17:23, bredy bredy...@yahoo.it ha scritto: leggendo la pagina Piemonte/Stazioni_elettriche http://wiki.openstreetmap.org/wiki/Piemonte/Stazioni_elettriche ho notato che sono ancora riportati i tag ormai deprecati station e sub_station. Sarebbe il caso di aggiornare. -- View this message in context: http://gis.19327.n5.nabble.com/Dati-stazioni-elettriche-di-Terna-tp5784343p5784681.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Alcuni articoli Wikipedia mappabili in OSM
Aury, io quando inserisco il tag wikipedia a qualche elemento verifico la correttezza delle coordinate riportate facendo un riscontro con le ortofoto del PCN, di solito uso il PCN 2008 Lazio+Umbria e trovo una perfetta corrispondenza tra gli oggetti della mappa e la veduta aerea, mentre in qualche caso ho trovato le coordinate riportate in wikipedia completamente errate. Nel caso dell'isolotto La Canna dato che possiamo ricarcare le foto del PCN tu a quelle coordinate puoi inserire un'isolotto di circa 40 m. di diametro, ma non conoscendone il nome ricaveresti il nome da wikipedia, non le coordinate. Oltretutto se le ortofoto del PCN sono precise come quelle del PCN 2008 Lazio+Umbria secondo me quello non è l'isolotto La Canna ma lo Scoglio di Montenassari e La Canna si trova più a ovest, per cui le coordinate di wikipedia potrebbero essere errate. Ciao, Marcello P.S. Sono alcuni giorni che i layer WMS con le ortofoto del PCN sono lentissimi a caricarsi, succede solo a me o è un problema comune? Il 09/11/2013 08:31, Aury88 ha scritto: ok! grazie per il chiarimento, ho ancora qualche dubbio sulla differenza tra ricalcare una mappa e il posizionare i singoli punti. cosa intendi per sistematica? Come dici tu non sempre comunque si sfrutta il centraggio per posizionare josm per poi mettere il punto in base alle immagini del terreno. io mi sono fidato delle coordinate prese da wikipedia, per esempio, per il posizionamento dell'isolotto/scoglio La Canna [1] che sulle mappe di bing non è visibile mentre sulle mappe di google è abbastanza evidente. sono abbastanza sicuro che le coordinate inserite su wikipedia siano prese da google (ma potrebbero comunque essere prese da un GPS; wikipedia non c'era la fonte delle coordinate purtroppo) e io, nonostante questo, ho fatto in modo che il punto inserito su osm fosse grosso modo alle stesse coordinate...quindi in questo caso il mio unico riferimento sono state le coordinate su wikipedia. quello che ho fatto è lecito? ...io, non conoscendo bene la materia legale rispetto i limiti di cosa sia copyviol e cosa non lo sia, mi sono sentito un po' in colpa per aver inserito quello scoglio e sono giorni che mi scervello se toglierlo o meno :.( Per quanto riguarda l'applicare un piccolo errore alle coordinate non saprei se basta per evitare il copyviol...non penso sia comunque lecito o non si sarebbero posti il problema di importare in automatico tutte le coordinate da wikipedia (sarebbe bastato applicare a tutte un errore random di qualche centesimo di secondo)... quindi non saprei come rispondere alla tua domanda sullo spostare in maniera automatica le coordinate ;forse alla fine non l'hanno fatto per questioni etiche, inerenti l'inserimento di informazioni volutamente sbagliate, e non per altre legate al copyright...bho! Ps: la mia non vuole essere assolutamente una critica a wikipedia (con cui collaboro felicemente da anni) o al suo utilizzo in osm... i miei sono solo dei dubbi dovuti alla mia totale ignoranza in materia Fino ad oggi non i sono posto il problema, fiducioso del fatto che tutte le informazioni su wikipedia, salvo altra segnalazione, dovrebbero essere sotto un copyright che permettere il loro utilizzo in osm, quindi se non ci sono stati problemi ad inserirli in wikipedia non dovrebbero essercene neanche per il loro inserimento in osm...lo so! un ragionamento probabilmente da ignorante ma mi permette di dormire abbastanza serenamente la notte XD [1] http://www.openstreetmap.org/browse/node/2524087908 saluti, Aury - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Alcuni-articoli-Wikipedia-mappabili-in-OSM-tp5779830p5784730.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Standardizzazione toponimi bilingui della Sardegna ed adattamento al modello altoadesino
Mi sono preso un pò di tempo per affrontare il problema dal punto di vista informatico e umano con un pò di calma :-) La conclusione è che la situazione attuale alla fine dei conti è la migliore in quanto permette una tagging atomico per ogni lingua (name:*) pur prevedendo un tag name che potrebbe non essere atomico (atomico = 1 valore in 1 lingua) ma che permette di sapere cosa c'è on the ground. Analisi informatica : Se faccio un rendering per lingua vedrò comunque vuoti di informazione: per esempio in Africa i cartelli stradali non sono in italiano. Un rendering con più lingue con una scaletta di preferenza non è assolutamente gestibile con le risorse attuali e un rendering distribuito mi sembra pericoloso (fake tile) Un rendering a livelli richiede un eccessivo lavoro lato server per comporre l'immagine oltre al problema di spazio su disco La composizione dell'immagine lato client ha problemi relativi a come i singoli browser implementano le specifiche css, spazio dei nomi, svg oltre al fatto che il client potrebbe essere un catorcio con poche risorse e quindi il lasso di tempo fra la ricezione dei dati e la rappresentazione a video potrebbe essere snervante. Analisi OSM: Esiste la regola generale di non mappare per il renderingEsiste la regola di mappare per quello che esiste sul territorio (on the ground) Conclusione: Continuiamo a mappare su name:* i valori nelle singole lingue e su name quello che c'è scritto sulla cartellonistica stradale. In questo modo chi vuole farsi la mappa solo italiano / solo inglese / solo quello che vuole... può farlo. Nel sito principale continuiamo a vedere quello che c'è on the ground. In effetti se una persona vede sul cartello 2/3 lingue è corretto che le veda anche su OSM. In questi casi inserirei anche i singoli dati su name:* . Per quanto riguarda l'obiezione dei navigatori o di altri strumenti che potrebbero avere problemi di visualizzazione (io stesso devo aver sollevato questo problema in passato) è pur vero che i navigatori si preparano le mappe e quindi in fase di elaborazione possono preferire il tag name:* a name : in sostanza il problema non si pone. Per quanto riguarda gli editor che supportano solo name e non name:* (possibile incongruenza di dati), chi mappa zone bi o trilingue userà un editor differente (Josm, iD, Vespucci non hanno di questi problemi). ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Mappatura a Castelfranco Veneto
Ciao a tutti, vi comunico con piacere che il comune di Castelfranco Veneto ha dato il patrocinio all'attività di mappatura sul territorio comunale (email dell'ufficio urbanistica, arriverà la comunicazione scritta a breve). In settimana distribuirò le locandine alle scuole e conto di tenere il primo appuntamento per mercoledi 18 dicembre 2013 in Patronato Pio X. Ulteriori dettagli a breve sulla lista veneta. Stefano Fraccaro ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mappatura a Castelfranco Veneto
Il 10/11/2013 07:01, Stefano Fraccaro ha scritto: Ciao a tutti, vi comunico con piacere che il comune di Castelfranco Veneto ha dato il patrocinio all'attività di mappatura sul territorio comunale (email dell'ufficio urbanistica, arriverà la comunicazione scritta a breve). In settimana distribuirò le locandine alle scuole e conto di tenere il primo appuntamento per mercoledi 18 dicembre 2013 in Patronato Pio X. Ulteriori dettagli a breve sulla lista veneta. Stefano Fraccaro ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it A Castelfranco Veneto, oltre al Data, hanno anche molto Brain Open. Contagiateci tutti :-) , col vostro entusiasmo. Mario Pichetti. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-at] Anfänger Treffen in Linz
hehe, dachte ich hab mal was von Wissensturm und OSM gelesen. Ich hab da aber keine Beziehungen dazu. Was ich vorschlagen kann: Strandgut in Alt Urfahr: https://www.facebook.com/pages/Strandgut-Verein-f%C3%BCr-bildende-Kunst-Kleinkunst-und-Literatur/245676698905098?fref=ts Nettes Vereinslokal mit Bar. WLAN kann besorgt werden. Platz für 20 Personsonen / 10 Tische für Notebook Ablage, sonst gibts so noch paar Sitzplätze. Bei dem letzten im Wiki eingetragenen Treffen waren 19 Leute Anwesend, sollte sich also ausgehen. Am Donnerstag ist dort immer Bar Betrieb, da könnten wir dann so ab 18 Uhr uns treffen. Im laufe des Abends kanns dann sein, das andere Leute auftauchen, da kann es dann schon ein bisschen lauter werden. Bar und Meetingraum sind 2 Räume, jedoch keine Tür. Wenn wir also durchgehend eine eher ruhige Atmosphäre brauchen, dann wär wohl etwas anderes geeigneter. Nächster dort freie Termin wär der 5.12.2013 18.00 Uhr Der Grazer Stammtisch verwendet eine Pad Software http://pad.okfn.org/ , ich persönlich finde https://hackpad.com/ ganz nett. Damit könnten wir dann mal die Interessanten Punkte zusammenfassen, die wir dann Besprechen wollen. Was meint Ihr dazu? Grüße Robert Am 06.11.2013 07:10, schrieb Lukas Bischof: Wissensturm? Mal anfragen, die Infrastruktur dort ist auf jeden Fall wirklich gut. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Antw: Re: Anfänger Treffen in Linz
fein, habe mir 05.12.2013, 18:00 h im Strandgut vorgemerkt! lg Berhard / Dromedar61 streetbot o...@jaxfab.net 09.11.13 12.23 Uhr hehe, dachte ich hab mal was von Wissensturm und OSM gelesen. Ich hab da aber keine Beziehungen dazu. Was ich vorschlagen kann: Strandgut in Alt Urfahr: https://www.facebook.com/pages/Strandgut-Verein-f%C3%BCr-bildende-Kunst-Kleinkunst-und-Literatur/245676698905098?fref=ts Nettes Vereinslokal mit Bar. WLAN kann besorgt werden. Platz für 20 Personsonen / 10 Tische für Notebook Ablage, sonst gibts so noch paar Sitzplätze. Bei dem letzten im Wiki eingetragenen Treffen waren 19 Leute Anwesend, sollte sich also ausgehen. Am Donnerstag ist dort immer Bar Betrieb, da könnten wir dann so ab 18 Uhr uns treffen. Im laufe des Abends kanns dann sein, das andere Leute auftauchen, da kann es dann schon ein bisschen lauter werden. Bar und Meetingraum sind 2 Räume, jedoch keine Tür. Wenn wir also durchgehend eine eher ruhige Atmosphäre brauchen, dann wär wohl etwas anderes geeigneter. Nächster dort freie Termin wär der 5.12.2013 18.00 Uhr Der Grazer Stammtisch verwendet eine Pad Software http://pad.okfn.org/ , ich persönlich finde https://hackpad.com/ ganz nett. Damit könnten wir dann mal die Interessanten Punkte zusammenfassen, die wir dann Besprechen wollen. Was meint Ihr dazu? Grüße Robert Am 06.11.2013 07:10, schrieb Lukas Bischof: Wissensturm? Mal anfragen, die Infrastruktur dort ist auf jeden Fall wirklich gut. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-pt] Portuguese flyer? (needs YOUR review!)(now really)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Olá amigos, sorry that it took so long, but I was very busy the past week. Now I managed to update the flyer with local text and thanks to Frederik we also have PT maps: https://gobblin.se/u/kellogs/collection/osm-pt-flyer-draft/ Compare folding with this one: http://wiki.openstreetmap.org/wiki/File:OSM_flyer_2013.jpg So whats todo: - -spell checking? - -makes layout/formating sense? - -are the maps areas ok to you? Then I will have to check the layout with test printing, so the single pages look ok (spacing, ...). I also can share the files at OSM SVN, but unfortunatly everybody needs a extra account to modify, so maybe it's easier if you post me your suggestions via the ML and I will try to fix it :) kind regards, Matthias Am 26.10.2013 00:40, schrieb Topo Lusitania Lusitania: Olá Abaixo a tradução do folheto em inglês que pode ser visto aqui: http://blog.gravitystorm.co.uk/ e que anexamos em png A equipa TopoLusitania Atenção os diversos parágrafos não estão por ordem Please note paragraphs are not in order for leaflet OpenStreetMap Criando o mapa-Mundi livre e gratuito Este folheto, criado por . Peça este folheto a .. ... O Mapa acima mostra Lisboa desenhada com os dados OpenStreetMap, tal como o mapa na página ao lado ou o Globo na página da frente, todos foran criados com o software OpenStreetMap. Muitos projectos com software Open-Source foram criados especialmente para o OpenStreetMap Adira ao OpenStreetMap já hoje! O nosso projecto e documentação pode ser encontrado em WWW.OPENSTREETMAP.ORG. O registo é rápido, fácil e grátis. Temos um WIKI com informações do projecto, tópicos e listas de correio próprias de cada país, assim como um sistema de Perguntas e Respostas se ficar encravado Os dados do OpenStreetMap são publicados sob a Licença 1.0 Base de dados aberta. Qualquer pessoa pode partilhar,adaptar e criar obras a partir dos nosso dados, livremente desde que dê os créditos aos contribuidores OpenStreetMap e partilhe qualquer base de dados adaptada sob a mesma licença http://www.openstreetmap.org/copyright Como funciona o OpenStreetMap? Você pode obter dados para os mapas do OpenStreetMap de várias formas. Um aparelho GPS e notas escritas são as ferramentas tradicionais. Os trajectos GPS (tracks) são uma gravação das ruas e caminhos que percorreu nesse dia. Pode usar um computador portátil ou uma máquina fotográfica para gravar os detalhes que viu durante o seu percurso. Mappers (Mapeadores) ( o nosso nome para topógrafos voluntários como você) podem também fazer frquentemente um excelente uso das nossas imagens aéreas. Um editor desenvolvido especialmente para o OpenStreetMap mostrar-lhe-á as nossas imagens aéreas bem como os trajectos de GPS que foram recebidos, e também os dados já existentes no OSM. A geometria das ruas, o contorno dos edificios, florestas ou lagos podem ser desenhados a partir das imagens aéreas, mas informações como números de portas, nomes das ruas, ou pontos de interesse faltam em tais imagens. Este tipo de dados pode apenas ser acrescentado se você conhecer bem o local - ou se o for visitar de propósito. Depois, os seus dados são enviados para a base de dados central do projecto e o mapa final é criado. Pouco tempo depois, as alterações estão visiveis para todos! Porquê um mapa-mundi livre e gratuito? Why a Free Wiki World Map Na internet existe uma imensidão de plantas de cidades e mapas gratis. Mas a maior parte são apenas para uso pessoal e não podem ser usados noutras publicações. Por exemplo, nós (OSM) não os poderiamos usar num folheto como este. Muiyas vezes estes mapas não são actuais, são imcompletos e os seus erros são corrigidos muito lentamente, quando o são. Um ponto importante é o de que você só pode usar imagens de mapas, mas não tem acesso aos dados apartir dos quais eles foram criados. Você precisa desses dados se quiser criar os seus próprios mapas, ou usar os mapas em aparelhos diferentes, por exemplo para navegação ao ar livre. OpenStreetMap é um projecto comunitário à escala mundial, com pessoas como você e eu, recolhendo dados geográficos algumas vezes em equipa outras sózinhos. Com os nossos próprios dados e o nosso próprio software, temos a liberdade de usar os dados para qualquer fim. Como na Wikipedia, qualquer um pode participar, e centenas de milhares como nós já estão a mapear. Junte-se a nós, já hoje! On Saturday, October 26, 2013 12:25 AM, f.dos.san...@free.fr f.dos.san...@free.fr wrote: I've updated the wiki. I think the tone is good, very directed to the reader, as in OSM needs you ! Surely it will bring a reaction on the reader :-) I'm ok too with the word open-source, some other word need probably a bit more thinking, for example the word notas looks too much as a translation from english (I think as
Re: [Talk-pt] Portuguese flyer? (needs YOUR review!)(now really)
Por essa razão, os utilizadores do OSM voluntariam-se para recolher dados por conta própria. Com esses dados e software livre, . (podes usar o GPS do telemóvel se tiveres) ... sobre imagens aéreas, mostrando também os dados previamente adicionados por outros. Regards, ___ Talk-pt mailing list Talk-pt@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-pt
[OSM-talk-fr] Symboles dans rendu FR
Salut, Je verrais bien un petit symbole pour tourism=chalet qui manque sur le rendu. Il existe dans Mapnik. http://tile.openstreetmap.fr/?zoom=20lat=3.62455lon=-53.21164layers=B00 De même pour les œuvres d'art (pas rendues non plus dans Mapnik). http://tile.openstreetmap.fr/?zoom=20lat=4.9089lon=-52.28115layers=B00 Le totem sous le Parking élèves 2 roues n'apparaît pas. Le débat est ouvert ? Je fais un ticket ? @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap vs Wikipedia
En fait non: on peut donner aussi une information dans Wikipedia. (...) Bon, eh bien disons que sur ce point précis qui concerne une tâche identique (ie : quoi faire après avoir vu sur le terrain qu'une information est fausse) : - Dans Wikipedia, en tant que simple utilisateur et non journaliste, il faut que je crée une ressource documentaire (photos datées dans Common, donc), pour défendre la position que l'affirmation du journaliste n'est plus pertinente. Il faudra aussi trouver les formes pour garder un aspect historique, quand bien même l'information de départ manque de contexte historique elle aussi (on ne sait pas depuis combien de temps ce panneau était le dernier panneau Stop de Paris, etc). - Dans OSM, je me connecte et j'ôte le panneau. Ca s'excitera ensuite si quelqu'un le remet de nouveau, etc. Mais j'ai rien à prouver par défaut en tant que contributeur sous prétexte qu'un journaliste a écrit quelque chose il y a plusieurs années sur un media autre que Wikipédia. Et en pratique, des dizaines de milliers de personnes passent devant le non-panneau chaque jour, et il est toujours dans Wikipedia ;) Il aurait été intéressant de voir s'il aurait disparu aussi lentement d'OSM s'il y avait été (et je rappelle qu'il peut réapparaître, ici ou sur l'éventuelle future nouvelle sortie). Ceci dit, je pourrais aussi donner des cas ou Wikipedia sembe plus a jour qu'OSM sur des infos de voirie (les suivi de travaux en particulier). -- View this message in context: http://gis.19327.n5.nabble.com/OpenStreetMap-vs-Wikipedia-tp5782320p5784796.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-ja] 公園内の広場のタグ付け
こんばんわ。横浜のあまのです。 久々に現調してきました(笑) 本題。 公園によくある、広場はどうタグ付けしていいのか？ ここでいう広場とは、屋外の土の地面だけの場所で ボール遊びができたり、若干の人が集まれたりすることができ 周囲にベンチがポツポツおいてあったり、端に藤棚やバーゴラが あったりするようなところです。 Playgroundかとも思ったのですが、遊具は無い。 これだけで一つの小さな公園となっている場合ならParkで大括り すればいいけど、大きな公園の中にこういう広場が多数ある場合は どうすればいいのでしょう？ 今まで、何となく曖昧模糊にしていたのですが、さすがに困って しまいました。ご例示・ご教示いただければ幸いです。 天野 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 公園内の広場のタグ付け
東です。 空き地とか広場って適切なタグ付けに結構悩みますよね。 普段は何となく近そうなものを選んでいます。 私自身は公園内のエリアは普段は細分化せず leisure=park だけで描いています。 野球場があるような大きな運動公園はそこだけ leisure=pitch sport=baseball と描いたりしています。 汎用的なグラウンドなら sport=multi かな。 イギリスにはレクリエーショングラウンドと呼ばれる広場がよくあるようですが、 この用語自体はイギリス固有のもののようです。 http://wiki.openstreetmap.org/wiki/JA:Tag:landuse%3Drecreation_ground 2013/11/09 Ryosuke Amano r-am...@dp.u-netsurf.ne.jp: こんばんわ。横浜のあまのです。 久々に現調してきました(笑) 本題。 公園によくある、広場はどうタグ付けしていいのか？ ここでいう広場とは、屋外の土の地面だけの場所で ボール遊びができたり、若干の人が集まれたりすることができ 周囲にベンチがポツポツおいてあったり、端に藤棚やバーゴラが あったりするようなところです。 Playgroundかとも思ったのですが、遊具は無い。 これだけで一つの小さな公園となっている場合ならParkで大括り すればいいけど、大きな公園の中にこういう広場が多数ある場合は どうすればいいのでしょう？ 今まで、何となく曖昧模糊にしていたのですが、さすがに困って しまいました。ご例示・ご教示いただければ幸いです。 天野 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] フィリピンのマッピング
東です。 フィリピンを襲った台風被害の支援用にHOTのタスクが２つ立ち上がっています。 被害が大きそうな気配があり、よろしければマッピング支援を。 １．最初の上陸エリア http://tasks.hotosm.org/job/338 住宅などを細かく描いています。 ２．被害の大きそうなエリア http://tasks.hotosm.org/job/339 住居エリアを識別する作業を行っています。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] osm.jp のレンダリング好評でした(KOF)
としです． KOF で osm.jp のレンダリングが話に登りまして，好評でした． 殆どは広島から来られた丸市さんに教えていただいたのですが， 交差点の名前が出てくる（これはかなりありがたい）のと， 建物が立体的(※)に描かていているのが良いです． ※：これは後で知りましたが，タグのLEVELに関わらず立体的に描いているようですね． 私自身，日本のOSM地図においては，osm.jp のレンダリングを推したいです！． ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] フィリピンのマッピング
いいだです。 現地からの情報により、緊急度の高い地域の要請があったようです。 道路のネットワーク、および建物を描いて欲しい、とのこと。 http://tasks.hotosm.org/job/340 Bingの画質があまりよくないので、 OrbViewなど他のソースも探しているようなのですが、あまり使えるものが無い、とのこと。 2013年11月10日 8:49 Shu Higashi higa...@gmail.com: 東です。 フィリピンを襲った台風被害の支援用にHOTのタスクが２つ立ち上がっています。 被害が大きそうな気配があり、よろしければマッピング支援を。 １．最初の上陸エリア http://tasks.hotosm.org/job/338 住宅などを細かく描いています。 ２．被害の大きそうなエリア http://tasks.hotosm.org/job/339 住居エリアを識別する作業を行っています。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSM-ja] i-gotu GT-900Pro でGPSログ取ってみました．
としです． KOFで腕時計型のGPSロガー i-gotu GT-900Pro が販売されていたので， 購入して自作GPSロガーと測り比べをしてみました． 結論としては，i-gotu GT-900Pro のGPXログには精度が記録されないものの， 位置精度はLCD画面を見ると2mまで良い時があるので，マッピングする時の メインGPSロガーとして使えると思いました． ＃私個人は，あくまで自作GPSロガーがメインですが（汗 このあたりの事を，Wikiページに書きつつあります． https://wiki.openstreetmap.org/wiki/User:Tosihisa/GPS_comparison ではこれにて． ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
[OSRM-talk] Questions on OSRM normalized file format
Hi all, I'm currently the lead developer for pgRouting and I'm interested in being able to create a local instance of OSRM that can be accessed via pgRouting. This all seems pretty straight forward to prototype up. At the moment, I have a few questions on OSRM normalized file format. I want to be able to write a utility program for postgresql to prep and dump a pgRouting topology to an OSRM normalized file. Looking at the edge section: It appears that edges can be entered as undirected (ie: twoway with same costs in both directions) or directed in the case of oneway streets. 1. if I have a edge with different to-from and from-to costs am I correct in assuming that the way to enter this is to split the edge and enter it as two oneway edges with the appropriate costs? 2. oneway edges must be entered where from-to is the direction of the edge, ie: the direction must be to the target node? 3. Can you expound on the rank of the speed profile? Is this still used? in the Speedprofile page it says that this is now handled as LUA scripts. Looking at the turn restrictions section: Is there a graphic that explains this better. It is a little bit hard to follow where the various items come into play. There are references to via-node, from-node, to-node, from-way, and to-way. Here is a common use case that I need to model. It is a majow road digitized as separated north and south bound lanes and intersected by a two way street digitized as a single line. e h | | | | | | a-b-c-d | | | | | | f g Traffic is allowed: ab-bc-cd - east bound cross traffic dc-cb-ba - west bound cross traffic eb-bf - one way south bound traffic gc-ch - one way north bound traffic ab-bc-ch - east bound onto north bound ab-bf - east bound onto south bound dc-ch - west bound onto north bound dc-cb-bf - west bound onto south bound eb-ba - south bound onto west bound gc-cd - north bound onto east bound U-Turns are not allowed: eb-bc-ch - south bound u-turn to north bound gc-cb-bf - north bound u-turn to south bound and more obviously any turn the wrong way down a oneway edge. Any help in understanding this would be greatly appreciated. Thanks, -Steve ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Questions on OSRM normalized file format
Hi Stephen, Back in April I wrote a wiki page detailing the internal processing flow and data structures, did you see it? https://github.com/DennisOSRM/Project-OSRM/wiki/Processing-Flow Maybe there is some useful info there. Dennis can probably tell you what has changed since April. Best regards, Emil On 09 Nov 2013, at 17:38 , Stephen Woodbridge wood...@swoodbridge.com wrote: Hi all, I'm currently the lead developer for pgRouting and I'm interested in being able to create a local instance of OSRM that can be accessed via pgRouting. This all seems pretty straight forward to prototype up. At the moment, I have a few questions on OSRM normalized file format. I want to be able to write a utility program for postgresql to prep and dump a pgRouting topology to an OSRM normalized file. Looking at the edge section: It appears that edges can be entered as undirected (ie: twoway with same costs in both directions) or directed in the case of oneway streets. 1. if I have a edge with different to-from and from-to costs am I correct in assuming that the way to enter this is to split the edge and enter it as two oneway edges with the appropriate costs? 2. oneway edges must be entered where from-to is the direction of the edge, ie: the direction must be to the target node? 3. Can you expound on the rank of the speed profile? Is this still used? in the Speedprofile page it says that this is now handled as LUA scripts. Looking at the turn restrictions section: Is there a graphic that explains this better. It is a little bit hard to follow where the various items come into play. There are references to via-node, from-node, to-node, from-way, and to-way. Here is a common use case that I need to model. It is a majow road digitized as separated north and south bound lanes and intersected by a two way street digitized as a single line. e h | | | | | | a-b-c-d | | | | | | f g Traffic is allowed: ab-bc-cd - east bound cross traffic dc-cb-ba - west bound cross traffic eb-bf - one way south bound traffic gc-ch - one way north bound traffic ab-bc-ch - east bound onto north bound ab-bf - east bound onto south bound dc-ch - west bound onto north bound dc-cb-bf - west bound onto south bound eb-ba - south bound onto west bound gc-cd - north bound onto east bound U-Turns are not allowed: eb-bc-ch - south bound u-turn to north bound gc-cb-bf - north bound u-turn to south bound and more obviously any turn the wrong way down a oneway edge. Any help in understanding this would be greatly appreciated. Thanks, -Steve ___ 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: [OSRM-talk] Questions on OSRM normalized file format
Yes, but I will read it again. I'm still trying to get up to speed on everything. Dennis, if you can answer my questions below that would be appreciated. By the way, I'm extremely pleased that you have redone this under the BSD license. I look forward to workign with you guys and integrating this into pgRouting. Thanks, -Steve On 11/9/2013 12:17 PM, Emil Tin wrote: Hi Stephen, Back in April I wrote a wiki page detailing the internal processing flow and data structures, did you see it? https://github.com/DennisOSRM/Project-OSRM/wiki/Processing-Flow Maybe there is some useful info there. Dennis can probably tell you what has changed since April. Best regards, Emil On 09 Nov 2013, at 17:38 , Stephen Woodbridge wood...@swoodbridge.com mailto:wood...@swoodbridge.com wrote: Hi all, I'm currently the lead developer for pgRouting and I'm interested in being able to create a local instance of OSRM that can be accessed via pgRouting. This all seems pretty straight forward to prototype up. At the moment, I have a few questions on OSRM normalized file format. I want to be able to write a utility program for postgresql to prep and dump a pgRouting topology to an OSRM normalized file. Looking at the edge section: It appears that edges can be entered as undirected (ie: twoway with same costs in both directions) or directed in the case of oneway streets. 1. if I have a edge with different to-from and from-to costs am I correct in assuming that the way to enter this is to split the edge and enter it as two oneway edges with the appropriate costs? 2. oneway edges must be entered where from-to is the direction of the edge, ie: the direction must be to the target node? 3. Can you expound on the rank of the speed profile? Is this still used? in the Speedprofile page it says that this is now handled as LUA scripts. Looking at the turn restrictions section: Is there a graphic that explains this better. It is a little bit hard to follow where the various items come into play. There are references to via-node, from-node, to-node, from-way, and to-way. Here is a common use case that I need to model. It is a majow road digitized as separated north and south bound lanes and intersected by a two way street digitized as a single line. e h | | | | | | a-b-c-d | | | | | | f g Traffic is allowed: ab-bc-cd - east bound cross traffic dc-cb-ba - west bound cross traffic eb-bf - one way south bound traffic gc-ch - one way north bound traffic ab-bc-ch - east bound onto north bound ab-bf - east bound onto south bound dc-ch - west bound onto north bound dc-cb-bf - west bound onto south bound eb-ba - south bound onto west bound gc-cd - north bound onto east bound U-Turns are not allowed: eb-bc-ch - south bound u-turn to north bound gc-cb-bf - north bound u-turn to south bound and more obviously any turn the wrong way down a oneway edge. Any help in understanding this would be greatly appreciated. Thanks, -Steve ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org mailto: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 ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Questions on OSRM normalized file format
OK, I have read most all the wiki pages and I'm not getting how the restrictions are being defined. So a little help getting over the mind block I seem to be having for this. Everything else seems really straight forward, so I can't imagine that the restrictions are all the complicated, but it is not clicking with any confidence in my head yet. If I have the following: ab-c | | d ab, bc, and db are all two way and there is no right turn from db to bc Then is the restriction: b, d, c, forbidden, 7F 00 00 where: b is the via-node d is the from-node c is the to-node and the records should then be sorted by EDGE[via-node, to-node] ref. Is this correct? Thanks, -Steve On 11/9/2013 2:52 PM, Stephen Woodbridge wrote: Yes, but I will read it again. I'm still trying to get up to speed on everything. Dennis, if you can answer my questions below that would be appreciated. By the way, I'm extremely pleased that you have redone this under the BSD license. I look forward to workign with you guys and integrating this into pgRouting. Thanks, -Steve On 11/9/2013 12:17 PM, Emil Tin wrote: Hi Stephen, Back in April I wrote a wiki page detailing the internal processing flow and data structures, did you see it? https://github.com/DennisOSRM/Project-OSRM/wiki/Processing-Flow Maybe there is some useful info there. Dennis can probably tell you what has changed since April. Best regards, Emil On 09 Nov 2013, at 17:38 , Stephen Woodbridge wood...@swoodbridge.com mailto:wood...@swoodbridge.com wrote: Hi all, I'm currently the lead developer for pgRouting and I'm interested in being able to create a local instance of OSRM that can be accessed via pgRouting. This all seems pretty straight forward to prototype up. At the moment, I have a few questions on OSRM normalized file format. I want to be able to write a utility program for postgresql to prep and dump a pgRouting topology to an OSRM normalized file. Looking at the edge section: It appears that edges can be entered as undirected (ie: twoway with same costs in both directions) or directed in the case of oneway streets. 1. if I have a edge with different to-from and from-to costs am I correct in assuming that the way to enter this is to split the edge and enter it as two oneway edges with the appropriate costs? 2. oneway edges must be entered where from-to is the direction of the edge, ie: the direction must be to the target node? 3. Can you expound on the rank of the speed profile? Is this still used? in the Speedprofile page it says that this is now handled as LUA scripts. Looking at the turn restrictions section: Is there a graphic that explains this better. It is a little bit hard to follow where the various items come into play. There are references to via-node, from-node, to-node, from-way, and to-way. Here is a common use case that I need to model. It is a majow road digitized as separated north and south bound lanes and intersected by a two way street digitized as a single line. e h | | | | | | a-b-c-d | | | | | | f g Traffic is allowed: ab-bc-cd - east bound cross traffic dc-cb-ba - west bound cross traffic eb-bf - one way south bound traffic gc-ch - one way north bound traffic ab-bc-ch - east bound onto north bound ab-bf - east bound onto south bound dc-ch - west bound onto north bound dc-cb-bf - west bound onto south bound eb-ba - south bound onto west bound gc-cd - north bound onto east bound U-Turns are not allowed: eb-bc-ch - south bound u-turn to north bound gc-cb-bf - north bound u-turn to south bound and more obviously any turn the wrong way down a oneway edge. Any help in understanding this would be greatly appreciated. Thanks, -Steve ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org mailto: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 ___ 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-GB] Editor backbground layers in iD
Hi Paul, I hope you are well. As you have seen my responses at [1] and [2], it will come as no surprise that I oppose this move. I have set out my reasoning below: == Reason 1: Open Historical Maps (OHM) is not an entirely separate project to OSM == I will start by providing a bit of background for those on the talk-gb list who may not be aware. The editor-imagery-index is a list of background layers that appear in the main OSM editors (for example the bing aerial imagery). It is designed to be a single list that can be used by all editors (Potlatch, JOSM, iD, etc..), that is the purpose of editor-imagery-index is to make it easer to share new background layers. In my opinion creating a second version of this list (called historic-imagery-index) was silly as it will lead to confusion (more on that later). When you created the historic-imagery-index it was because some of the background imagery that has been licensed for use in OpenStreetMap has not been approved for use in Open Historic Map (which in your view is entirely separate from OSM). My proposal to add a OHM-Approved field to the existing editor-imagery-index was rejected on the basis that: Adding project-specific stuff to another project's documents doesn't really make sense. It's kind of like saying there should be a flag in the XLSX format specifying if the document can be opened by LibreOffice. This comparison seems over the top to me. Yes, OHM is currently not an official OpenStreetMap Foundation project, but many people in our community do see it as a sister project. After all, much of what is in OSM in town centres now, will become historic data in 50 years time. As such we should make more effort to be inclusive of Open Historic Maps. == Reason 2: What is historic? Who decides? == This point stands on its own, by which I mean, ignore that Open Historic Maps even exists. The point here is that who decides what counts as Historic and of no value to current day mapping. In my opinion all the layers you have proposed to remove are of current value. They include names of hills, valleys, rivers, etc that may be difficult to survey elsewhere. They also show us where Rights of Way may exist (note that due to the odd legal situation in the UK, a right of way may exist but not have been recorded by the Local Authority on current maps). Lets look at another example. Is a 1:5000 Town Plan from 1960 historic? It has 1960 in the title, so does that mean I should add it to your historic-imagery-index? Hang on, it contains detailed building outlines, many of which will still exist. Okay then we put this 1960's map in the current editor-imagery-index. But then what about a 1950s map, a 1940's map etc.. Where is the cut off? And why does the power to decide this lie with the very few people who can accept new contributions to editor-imagery-index and historic-imagery-index? Oh and lets be clear. At the moment this is a removal as the editors only pick up those background layers listed in editor-imagery-index. == Reason 3: It damages our community == We have been working hard to build up a relationship with our Archives and Libraries here in the UK. The current relationship with National Library of Scotland (NLS) is quite good. They even spoke at State of the Map Scotland 2013 [3]. The Bartholomew Half Inch layer is a new one only just added, and I know that (NLS) are delighted that we have made it available to OSM contributors. Removal of historic layers, sends a negative message to these wider OSM community members and suggests that we do not appreciate their work. You may not like the current layers very much, but many of these Archives hold some really detailed maps (e.g. Town Plans that have only just fallen out of copyright) and we need to work with them to make those layers available (for the joint benefit of OSM and OHM). In a related note, we are aiming to attract a more diverse community to OSM. As OHM and OSM use exactly the same tools, it is not beyond belief that someone who starts in OHM can also edit in OSM. We should work together, not apart. === I hope some of this makes sense, and you can see that the drawbacks far outweigh any benefits. To answer your original question: Yes, I still use these layers when I am mapping the countryside. I tend to flick back and forth between them and believe that I can make better maps if they are all available to me. Regards, Rob [1] https://github.com/osmlab/editor-imagery-index/pull/25 [2] https://github.com/osmlab/editor-imagery-index/issues/27 [3] http://www.youtube.com/watch?v=OsTeyAuBoqE ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Editor backbground layers in iD
On 09/11/13 11:58, Rob Nickerson wrote: As you have seen my responses at [1] and [2], it will come as no surprise that I oppose this move. I have set out my reasoning below: Hi Rob, hi Paul, I'll not venture into the how of this only the what... Let's think about it from the perspective of the new mapper. Let's imagine that they've decided to add something to OSM and they've ventured into iD for the first time. There's a nice walkthrough, but if I recall it doesn't mention much about background imagery, but there's an entry on the help that says there's some imagery in addition to the default Bing layer. When the new mapper clicks the imagery button at the right they currently see ALL of the geographically available layers from https://github.com/osmlab/editor-imagery-index (currently the bottom of the menu is cut off - see https://github.com/systemed/iD/issues/1929 - but that issue is fixed pending release). Let's not kid ourselves - not all of those layers are like the others. In GB, the Bing imagery layer, Local GPX file, GPS traces and OS OpenData StreetView are likely to be the most useful, and probably in that order. A Bartholomew 1/2 inch from the Victorian era is likely to be ... less so. We need to provide new mappers with relevant information, sometimes even if that means less information. No-one's proposing restricting what mappers can choose as a background in JOSM, and the background layers in Potlatch 2 aren't going to change any time soon, but in the instance of iD that new mappers see when they select edit from the menu on osm.org it does make sense NOT to offer them an OS 7th series that isn't even available everywhere in GB as the top option in the menu. Cheers, Andy ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Editor backbground layers in iD
Hi Andy, We are mixing up two issues here. One is as to whether historic layers should be removed from the default menus (and determining what counts as historic of no value to current mapping) and the second issue of how iD presents the list. Please do not let an iD bug direct the future direction of these image indexes. ID can be improved. Damage to the community is harder to repair. Regards, Rob ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Editor backbground layers in iD
Are there any *non*-historical uses for NLS - Bartholomew Half Inch, 1897-1907; NLS - OS 1-inch 7th Series 1955-61; or OS New Popular Edition historic. Of course there are. Historical maps are a huge source of meta data for the landscape, much of which cannot be obtained in any other way. The whole purpose of making the OOC OS maps available is because they contain information that is entirely relevant for today's map. Having spent many many hours scanning and rectifying OOC OS mapping for OSM (not any other project such as OHM) I hope that my efforts and those of the others who have gone before with NPE etc have not be wasted. Of course like all sources its necessary to understand the context. When referring to old data sources you need to take a view on whether the information is still likely to be relevant or indeed if it's still present on the ground, but using old sources with modern BING and other open data means that we can enrich OSM mapping. Cheers Andy ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Editor backbground layers in iD
On 09/11/2013 13:14, Rob Nickerson wrote: We are mixing up two issues here. One is as to whether historic layers should be removed from the default menus What exactly do you mean by the default menus here? There are no default menus in OSM, only menus in different instances of different editors. Please do not let an iD bug direct the future direction of these image indexes. ID can be improved. Damage to the community is harder to repair. In what way exactly with the default instance of iD on osm.org NOT providing a victorian map that is, being polite, less relevant than e.g. Bing or OSSV damaging the community? No-one is suggesting that we make historic imagery layers unavailable and plenty of people have said that they use them - but in all cases they are likely to be not the target market for the iD edit option on osm.org or capable of using the custom option. What would absolutely be damaging to the community would be to make the default edit option on osm.org not suitable for new users until they've learnt a whole bunch of arcane unwritten stuff about the relevance of various sources. Cheers, Andy ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Historic Layers (WAS: Editor backbground layers in iD)
Andy T, By default menus I mean those background layers that appear for normal folk who just go to osm.org and click edit (be that in ID, JOSM, Potlatch). Basically those people who do not spend the time, or have the know-how to add a new layer in JOSM's menus, or add a custom URL in ID. I'm also ruling out people who set up their own instance of ID/Potlatch/whatever. As noted editor-imagery-index was designed to unify the background layers across JOSM,Potlatch,ID,etc.. By damaging the community I mean, we are essentially saying to all the people who have scanned and georectifed maps (be they individual or organisations like NLS), thanks for your work be we don't see it as relevant to OSM, we are therefore going to make it hard for community members to use your layers as they will have to fist figure out how to add the layer to their editor of choice. I know your issue (about the menus in ID) is important but I do hope you can see that we are talking about two different things here. I have changed the subject of the email to reflect this as what pnorman is proposing affects more than just ID. Regards, Rob ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] walks.io
A great website in this weeks Weekly Notice [1] (translated from German), and a great reason as to why I contribute to OSM: http://walks.io/ Best, RobJN [1] http://blog.openstreetmap.de/blog/2013/11/07/wochennotiz-nr-172/ ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-us] Ferries
Am 08/nov/2013 um 18:15 schrieb Ivan Komarov jkoma...@gmail.com: I'd vote for introducing a new tag, that is highway=ferry_link, rather than trying to use an existing one that does not describe the object correctly. There used to be and there will be disputes on this topic unless we have it fixed. Introducing a new tagging scheme will cause some issues for a while, but on the long run it would work better, I believe. +1 cheers, Martin ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Complex intersection mapping
James,
Thanks for the feedback. This is of course not good. I will make sure
we will be more careful with both the lane counts and the relations
not getting broken! I apologize. Did you fix the relations? If not I
will.
The case you highlighted - I agree this one would be just fine as a
single node. The guidance I have been giving, based on previous
discussion in this thread, was to only 'dualize' the intersection when
the dual carriageway clearly continues past the intersection. Does
that make sense? I will make sure we adhere to that guideline and not
overcomplexify situations that don't require it from a ground trouth
perspective.
Martijn
On Fri, Nov 8, 2013 at 9:47 PM, James Mast rickmastfa...@hotmail.com wrote:
Martijn (and other telenav workers),
I just happened to see some intersections in my area tweaked today. If
you're going to be changing the intersections, can you at least please
update the lane count on said ways if it's already been added at the same
time? I mean, if a way is on one side 4 lanes, and you split it into two
separate ways, odds are both of them are 2 lanes each. Yet, the lane count
on them is still 4, which can also play screwy with the routing engines.
Also, can you please update any relations that are attached to the highways?
I'm going to bring up Changeset 18789658 as an example, which is the
intersection of US-22 Business, PA-48, the Orange Belt in Monroeville, PA.
The two numbered routes were broken today (amazingly the Orange Belt
wasn't) with the change from a 1-point intersection to a 4-point
intersection. I personally think that a 1-point intersection was completely
justified for this intersection because of only two directions being divided
when exiting it. Anyways, US-22 Business now has a gap because of the new
ways for it, and PA-48 now doesn't end @ the intersection anymore because of
the divided highway from the North being extended outside the main
intersection. And, to be honest, I'm also toying with the idea of reverting
said changeset to repair the relations and make it a 1-point intersection
again, but wanted to bring it up here on the list first before doing that to
prevent an edit war.
So, if you keep doing it that way, can you please keep the collateral damage
to a minimum when it comes to lane counts and highway relations? I would
really appreciate it when stuff like that was already tagged correctly
doesn't need to be fixed again. :)
-James (rickmastfan67)
From: marti...@telenav.com
Date: Mon, 14 Oct 2013 11:42:53 -0600
To: talk-us@openstreetmap.org
CC: ste...@telenav.com; krist...@telenav.com; robe...@telenav.com;
chr...@telenav.com
Subject: [Talk-us] Complex intersection mapping
Hi all,
Here at Telenav we have been looking at complex intersections and we
have set about editing some of these intersections in a way we feel
represents the situation on the ground better than their original
state, and because of that, works better for us. We have received some
feedback on our edits so we wanted to take a step back and see what we
(as the OSM community) think is the preferred way to map these
intersections.
So what are we talking about? Intersections like this one, where one
or more dual carriageways come together at an at-grade intersection:
https://www.evernote.com/shard/s9/sh/6438c196-bb92-4f66-81dc-9b75186286ba/0e8f07ff527c6a85c0dec426b9b79f1e
One of my colleagues at Telenav has remapped this intersection as follows:
https://www.evernote.com/shard/s9/sh/3491f1fe-6afa-4571-bc43-7cb31c9c2625/9dd47d1445fdcf03d3f0bbd93b8e0f92
The main difference, and the source of some feedback we have received
over the past few days, is that the dual carriageway roads are
straightened out, creating multiple intersection nodes (4 in this
case) instead of the original single intersection node that connects
all the incoming and outgoing ways. That technique turns out to yield
more reliable and correct routing and guidance ('keep left, turn
right') through these intersections in our testing. But of course,
that cannot dictate how we map as a community, so let's discuss.
Some of the feedback we have received about these edits points to a
statement on this wiki page:
https://wiki.openstreetmap.org/wiki/TIGER_fixup#Braided_streets: 'It
is a reasonable and well-used technique to bring the ways of dual
carriageways back to a single point at intersections to facilitate and
simplify the mapping of control devices and turn restrictions.' In my
mapping across the US, my personal experience has been that this
technique is in fact used, but the 'after' technique with straightened
out ways is actually much more common. I personally prefer that
technique as well - I think it is more pleasing to the eye, represents
what is on the ground better, and is and easier to read. So my feeling
was that this mapping practice would not be disputed. It turns out I
was wrong, so I want to see what the
Re: [Talk-us] Complex intersection mapping
From: marti...@telenav.com Date: Sat, 9 Nov 2013 11:31:55 -0500 To: rickmastfa...@hotmail.com CC: ste...@telenav.com; krist...@telenav.com; robe...@telenav.com; chr...@telenav.com; talk-us@openstreetmap.org Subject: Re: [Talk-us] Complex intersection mapping James, Thanks for the feedback. This is of course not good. I will make sure we will be more careful with both the lane counts and the relations not getting broken! I apologize. Did you fix the relations? If not I will. I hadn't yet since I wanted to wait till you responded on the list first so you could see what I was talking about (Changeset 18789658). The case you highlighted - I agree this one would be just fine as a single node. That's how I'm going to repair that intersection the relations that were effected, by just reverting Changeset 18789658 to return it to the way it was before yesterday. The guidance I have been giving, based on previous discussion in this thread, was to only 'dualize' the intersection when the dual carriageway clearly continues past the intersection. Does that make sense? Yep, that does make perfect sense to me. That's how I've personally been doing it. I will make sure we adhere to that guideline and not overcomplexify situations that don't require it from a ground trouth perspective. Martijn Sounds good Martijn. Thanks again for responding back on this subject. :) I'll now go ahead and do the revert of Changeset 18789658. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US: CDPs
Paul Norman penor...@mac.com writes: From: Richard Welty [mailto:rwe...@averillpark.net] Subject: Re: [Talk-us] Admin borders in the US: CDPs the latter, i think. there are parts of the US where the CDP boundaries do contribute to the map. I think there's two different cases that need to be distinguished between. One is where there are counties or other similar administrative structures, the other is where there are not. If what you mean lines up with 1) in some areas, CDP boundaries actually have some relevance, and people know where they are and use for things. In those areas it makes sense to have them in OSM. 2) in some areas, CDP boundaries are merely for the census, not understood or known about by more than a handful of government people, and have almost no real-world relevance. In those areas the CDP boundaries shouldn't be in OSM. then it sounds good to me. I live in a type 2 area, where every bit of land is in both a city/town and a county. (I realize that in Alaska there are some areas where CDPs seem to matter.) pgpW6dhg2Imvo.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US: CDPs
On Sat, Nov 9, 2013 at 7:03 PM, Greg Troxel g...@ir.bbn.com wrote: (I realize that in Alaska there are some areas where CDPs seem to matter.) https://en.wikipedia.org/wiki/Bethesda%2C_Maryland - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Admin borders in the US: CDPs
In Baltimore County, MD, we have 0 incorporated towns with nearly 1M people. There are however plenty of informal towns that have become CDPs. I believe the Census uses ZCTAs to construct the CDPs, so they're based on ZIP Codes, which in turn are based on postal routes. I think humans tend to like boundaries in general, so it is probably natural they end up on OSM. I think that if people identify with them, and there are no other admin boundaries, then go for it. On Sat, Nov 9, 2013 at 7:17 PM, Serge Wroclawski emac...@gmail.com wrote: On Sat, Nov 9, 2013 at 7:03 PM, Greg Troxel g...@ir.bbn.com wrote: (I realize that in Alaska there are some areas where CDPs seem to matter.) https://en.wikipedia.org/wiki/Bethesda%2C_Maryland - Serge ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us -- Elliott Plack http://about.me/elliottp ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-ht] Pratique Mapping
ou patap vini , pat di wap vini monche .. 2013/11/8 ALCE, Samuel Paul alcesamuelp...@gmail.com Mwen aktyelman nan machin map vini! Sorry pou reta... On Nov 8, 2013 11:02 AM, similia joseph similiajos...@gmail.com wrote: Nap byen kontan vizit ou! Ou ka relen sou 32 21 45 93/ 33 35 06 81/ 37 48 48 08 Le 7 nov. 2013 10:21, Louino Robillard robill...@future-ht.org a écrit : Koman nou ye ? Mwne kontan paske nou toujou ap motive... mwen poko janm jwen ak nou men, anpil moun di mwen ke nou gen anpil volonte. kite ke Nemewo telefon mwen ka rele nou. e pete mwen ka patisipe nan yon reyinyon Mesi ! Robi 2013/11/7 Wesly Joseph weslyjose...@gmail.com nou bezwen plis motivation pou cosmhanne vazan pi douvan, tout manb dwe la 2013/11/6 Rodenec Noel rodenecn...@gmail.com byenvini 2013/11/6 ALCE, Samuel Paul alcesamuelp...@gmail.com Bon bagay! Mwen okap pou moman sa map pwofite pase rankontre nou! Kenbe konsa! On Nov 6, 2013 8:57 PM, Alouidor Lesly Louis leslyloui...@gmail.com wrote: Vendredi 8 Novembre 10h AM Pratique Mapping de COSMHANNE A L'Universite Roi Henri CHristophe de Limonade ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate ( http://translate.google.com) pour traduire les messages. ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate ( http://translate.google.com) pour traduire les messages. ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate ( http://translate.google.com) pour traduire les messages. ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate ( http://translate.google.com) pour traduire les messages. ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate ( http://translate.google.com) pour traduire les messages. ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate ( http://translate.google.com) pour traduire les messages. ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages. ___ Talk-ht mailing list Talk-ht@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ht Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour traduire les messages.
