Re: [OSM-talk-be] samenvoegen van stukken weg
Splitsen is meestal gedaan omdat er net een verschil is (verschillende maximum snelheid, maximum gewicht, deel van een route relatie, ...). JOSM klaagt niet als de tags geen conflict vertonen (vb. een maximum gewicht op een deel van de weg, maar niet op de rest), dus zelfs in JOSM kan het samenvoegen gevaarlijk zijn. Het splitsen van een weg is daarentegen heel wat minder gevaarlijk. Groeten, Sander Op 2 januari 2015 13:05 schreef Glenn Plas gl...@byte-consult.be: Ik kom vaak wegen tegen die getekend zijn in iD en die zijn meestal niet connected met de andere ways.Visueel lijkt het wel ok maar logisch gezien staan de uiteinde van de nodes op de way, niet joined met de way. JOSM zorgt voor de relaties automatisch, samenvoegen zou daar niet zoveel schade aanrichten dan in iD. Glenn Dit was een paar maanden geleden ook aan de gang in Almere (Nederland). Ik snap de beweegredenen ook niet. Een perfecte weg verwijderen om een nieuwe te tekenen? Waarom dan niet direkt samenvoegen, dat is toch veel minder werk? Of is dat lastig in iD? Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ 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] samenvoegen van stukken weg
On 2015-01-02 12:14, Marc Gemis wrote: Ik zou er langs deze weg iedereen willen op wijzen dat het gevaarlijk is om stukken weg samen te voegen tot 1 geheel. Zeker als dit gebeurt door de oude weg weg te smijten en een nieuwe te tekenen. Het heeft ook geen enkel nut. In de meeste gevallen zijn de wegen gesplitst voor een goede reden: andere eigenschappen, deel van een relatie. iD laat dit niet allemaal zien. Ik heb de auteur van deze changeset [1] gevraagd om het boeltje te herstellen, maar hij heeft er nog wel een paar gelijkaardige wijzigingen gedaan in de buurt van Lier. Misschien zijn er daar fietsroutes gebroken. In [1] weet ik zeker dat de wandelroutes verwijderd zijn. Dit was een paar maanden geleden ook aan de gang in Almere (Nederland). Ik snap de beweegredenen ook niet. Een perfecte weg verwijderen om een nieuwe te tekenen? Waarom dan niet direkt samenvoegen, dat is toch veel minder werk? Of is dat lastig in iD? Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] samenvoegen van stukken weg
Ik zou er langs deze weg iedereen willen op wijzen dat het gevaarlijk is om stukken weg samen te voegen tot 1 geheel. Zeker als dit gebeurt door de oude weg weg te smijten en een nieuwe te tekenen. Het heeft ook geen enkel nut. In de meeste gevallen zijn de wegen gesplitst voor een goede reden: andere eigenschappen, deel van een relatie. iD laat dit niet allemaal zien. Ik heb de auteur van deze changeset [1] gevraagd om het boeltje te herstellen, maar hij heeft er nog wel een paar gelijkaardige wijzigingen gedaan in de buurt van Lier. Misschien zijn er daar fietsroutes gebroken. In [1] weet ik zeker dat de wandelroutes verwijderd zijn. Hij zal misschien wel hulp nodig hebben om zijn wijzigingen terug te draaien. mvg m [1] https://www.openstreetmap.org/changeset/27816760 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
Hoi Sander, Hebben we over hetzelfde hier ? JOSM gaat u wel een dialoog geven hoor dat de tags verschillen. De user krijgt de merge window open. Het is aan de user om daarin te beslissen. Ik weet niet of je dat onder 'klagen' kan categoriseren, maar een kleine test hier geeft toch aan dat hij wel waarschuwt. (C - combine ways gedaan). Zie screenshot. http://aptum.bitless.be/screenie.png Glenn On 02-01-15 13:31, Sander Deryckere wrote: Splitsen is meestal gedaan omdat er net een verschil is (verschillende maximum snelheid, maximum gewicht, deel van een route relatie, ...). JOSM klaagt niet als de tags geen conflict vertonen (vb. een maximum gewicht op een deel van de weg, maar niet op de rest), dus zelfs in JOSM kan het samenvoegen gevaarlijk zijn. Het splitsen van een weg is daarentegen heel wat minder gevaarlijk. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
Ik kom vaak wegen tegen die getekend zijn in iD en die zijn meestal niet connected met de andere ways.Visueel lijkt het wel ok maar logisch gezien staan de uiteinde van de nodes op de way, niet joined met de way. JOSM zorgt voor de relaties automatisch, samenvoegen zou daar niet zoveel schade aanrichten dan in iD. Glenn Dit was een paar maanden geleden ook aan de gang in Almere (Nederland). Ik snap de beweegredenen ook niet. Een perfecte weg verwijderen om een nieuwe te tekenen? Waarom dan niet direkt samenvoegen, dat is toch veel minder werk? Of is dat lastig in iD? Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
On 2015-01-02 12:14, Marc Gemis wrote : Ik zou er langs deze weg iedereen willen op wijzen dat het gevaarlijk is om stukken weg samen te voegen tot 1 geheel. Zeker als dit gebeurt door de oude weg weg te smijten en een nieuwe te tekenen. Het heeft ook geen enkel nut. In de meeste gevallen zijn de wegen gesplitst voor een goede reden: andere eigenschappen, deel van een relatie. iD laat dit niet allemaal zien. Ik heb de auteur van deze changeset [1] gevraagd om het boeltje te herstellen, maar hij heeft er nog wel een paar gelijkaardige wijzigingen gedaan in de buurt van Lier. Misschien zijn er daar fietsroutes gebroken. In [1] weet ik zeker dat de wandelroutes verwijderd zijn. Hij zal misschien wel hulp nodig hebben om zijn wijzigingen terug te draaien. Je voudrais saisir cette occasion pour rappeler à tous qu'il est dangereux d'ajouter des morceaux loin ensemble en un tout. Surtout si ce est de jeter la vieille manière et dessiner un nouveau. Il dispose également d'aucune utilité. Dans la plupart des cas, les routes sont divisées pour une bonne raison: d'autres propriétés, qui fait partie d'une relation. iD montre ce pas tout. Je suis l'auteur de ce changeset [1] a demandé de récupérer les biens, mais il fait encore des changements similaires dans un proche Lier. Peut-être il ya des pistes cyclables brisées. Dans [1] Je suis sûr que les sentiers sont supprimés. Il sera probablement besoin d'aide pour inverser ses amendements. Utilisez JOSM. Il détecte la majorité des problèmes de fusion. Il va même jusqu'à avertir que faire une opération sans charger des données supplémentaires est susceptible de provoquer un problème avec des données invisibles et inconnues. J'ai vu beaucoup de chemins inutilement découpés. C'est parfaitement hilarant de voir Nominatim donner 10 résultats pour la même rue. J'ai un jour écrit un article décrivant une méthode pour ne plus devoir découper les chemins mais ça n'a intéressé personne. André. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
't gaat in dit geval wel om een delete + opnieuw tekenen. JOSM zal dan wel klagen dan je een weg uit een relatie haalt. Ik weet niet wat iD in zo'n geval doet. m 2015-01-02 13:31 GMT+01:00 Sander Deryckere sander...@gmail.com: Splitsen is meestal gedaan omdat er net een verschil is (verschillende maximum snelheid, maximum gewicht, deel van een route relatie, ...). JOSM klaagt niet als de tags geen conflict vertonen (vb. een maximum gewicht op een deel van de weg, maar niet op de rest), dus zelfs in JOSM kan het samenvoegen gevaarlijk zijn. Het splitsen van een weg is daarentegen heel wat minder gevaarlijk. Groeten, Sander Op 2 januari 2015 13:05 schreef Glenn Plas gl...@byte-consult.be: Ik kom vaak wegen tegen die getekend zijn in iD en die zijn meestal niet connected met de andere ways.Visueel lijkt het wel ok maar logisch gezien staan de uiteinde van de nodes op de way, niet joined met de way. JOSM zorgt voor de relaties automatisch, samenvoegen zou daar niet zoveel schade aanrichten dan in iD. Glenn Dit was een paar maanden geleden ook aan de gang in Almere (Nederland). Ik snap de beweegredenen ook niet. Een perfecte weg verwijderen om een nieuwe te tekenen? Waarom dan niet direkt samenvoegen, dat is toch veel minder werk? Of is dat lastig in iD? Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
is dat verschil niet te verklaren door de eerste checkbox (alleen conflicterende tags) vs. de tweede (tags met meerdere waarden) ? Ik weet niet wat de default is. Ik geloof wel dat JOSM je laatste keuze onthoudt. m. 2015-01-02 13:54 GMT+01:00 Glenn Plas gl...@byte-consult.be: Hoi Sander, Hebben we over hetzelfde hier ? JOSM gaat u wel een dialoog geven hoor dat de tags verschillen. De user krijgt de merge window open. Het is aan de user om daarin te beslissen. Ik weet niet of je dat onder 'klagen' kan categoriseren, maar een kleine test hier geeft toch aan dat hij wel waarschuwt. (C - combine ways gedaan). Zie screenshot. http://aptum.bitless.be/screenie.png Glenn On 02-01-15 13:31, Sander Deryckere wrote: Splitsen is meestal gedaan omdat er net een verschil is (verschillende maximum snelheid, maximum gewicht, deel van een route relatie, ...). JOSM klaagt niet als de tags geen conflict vertonen (vb. een maximum gewicht op een deel van de weg, maar niet op de rest), dus zelfs in JOSM kan het samenvoegen gevaarlijk zijn. Het splitsen van een weg is daarentegen heel wat minder gevaarlijk. Groeten, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
2015-01-02 17:11 GMT+01:00 André Pirard a.pirard.pa...@gmail.com: J'ai un jour écrit un article décrivant une méthode pour ne plus devoir découper les chemins mais ça n'a intéressé personne. I've read somewhere that navigation software will split all ways at a crossing in order to be able to calculate all possible routes. So the merging is only needed for rendering (in order not to show the name over and over again). Nominatim only shows the same way when the classification is different, see [1] for a split street showing multiple results, and [2] for one showing only one segment regards m. [1] http://nominatim.openstreetmap.org/search.php?q=steenweg+op+waarloosviewbox=-112.33%2C46.38%2C112.33%2C-46.38 [2] http://nominatim.openstreetmap.org/search.php?q=Molenstraat%2C+rumstviewbox=4.38%2C51.11%2C4.41%2C51.09 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
Yup, kan dit bevestigen, er moet minstens 1 tag verschillen op beide ways voor die dialog bovenkomt. Als ze beide een tag missen van elkaar krijg je de dialoog wel. Een way zonder tags combineren met eentje met krijg je absoluut geen waarschuwing, hij combineert gewoon silently. Glenn On 02-01-15 14:23, Maarten Deen wrote: On 2015-01-02 13:54, Glenn Plas wrote: Hoi Sander, Hebben we over hetzelfde hier ? JOSM gaat u wel een dialoog geven hoor dat de tags verschillen. De user krijgt de merge window open. Het is aan de user om daarin te beslissen. Je krijgt die dialoog alleen als de tags verschillen. Als een stuk weg een bepaalde tag heeft en het andere stuk niet dan krijg je die dialoog niet. Dus: maxspeed=30 en maxspeed=50 samenvoegen: dialoog, maxspeed=30 en geen maxspeed tag samenvoegen: geen dialoog. Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be -- Everything is going to be 200 OK. ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
We zijn eigenlijk wel beetje naast de feiten aan het praten ivm deze case, als de user de vorige weg verwijdert en dan een nieuwe tekent gaat die natuurlijk geen waarschuwing krijgen over de tags, enkel over eventuele relaties die in het gedrang kunnen komen. Glenn On 02-01-15 13:54, Glenn Plas wrote: Hoi Sander, Hebben we over hetzelfde hier ? JOSM gaat u wel een dialoog geven hoor dat de tags verschillen. De user krijgt de merge window open. Het is aan de user om daarin te beslissen. Ik weet niet of je dat onder 'klagen' kan categoriseren, maar een kleine test hier geeft toch aan dat hij wel waarschuwt. (C - combine ways gedaan). Zie screenshot. http://aptum.bitless.be/screenie.png Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
On 2015-01-02 13:54, Glenn Plas wrote: Hoi Sander, Hebben we over hetzelfde hier ? JOSM gaat u wel een dialoog geven hoor dat de tags verschillen. De user krijgt de merge window open. Het is aan de user om daarin te beslissen. Je krijgt die dialoog alleen als de tags verschillen. Als een stuk weg een bepaalde tag heeft en het andere stuk niet dan krijg je die dialoog niet. Dus: maxspeed=30 en maxspeed=50 samenvoegen: dialoog, maxspeed=30 en geen maxspeed tag samenvoegen: geen dialoog. Maarten ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] samenvoegen van stukken weg
I once read your proposal on the wiki. The main drawback that I see is that one will get an awful lot of layers (or whatever you want to call them). For each property you add to a street a need to create a new layer. After verifying of course that there isn't already a layer with that property. In that case you have to split the layer at the right place. I try to imaging how a UI to edit that would look like. Or software that uses that data. I wonder whether it would much easier to work with such a structure. hard to tell. You are probably to much ahead of your time with this proposal. regards m PS, it is indeed pretty confusing that something with one 'l' in one language has two in the other, and has another meaning in the second language with one l. On Sat, Jan 3, 2015 at 2:34 AM, André Pirard a.pirard.pa...@gmail.com wrote: On 2015-01-02 19:01, Marc Gemis wrote : 2015-01-02 17:11 GMT+01:00 André Pirard a.pirard.pa...@gmail.com: J'ai un jour écrit un article décrivant une méthode pour ne plus devoir découper les chemins mais ça n'a intéressé personne. I've read somewhere that navigation software will split all ways at a crossing in order to be able to calculate all possible routes. So the merging is only needed for rendering (in order not to show the name over and over again). Obviously. With my method, there is no merging necessary because there is no splitting. If a part of a way has different tags, a sort of patch dummy way is created that overlays that part of the way and that contains the tags that are different. Difficult to explain in 2 lines. --- real highway with common tags - dummy way (patch) with bridge=yes If the consumer wants that, it can split the real highway, merge the tags and get the current situation. But it doesn't have to. In a further step, with slight software changes, the patch could be the element of a relation and relations would stop splitting the ways everywhere. Also, a turning restriction and other things could be done with very simple patches instead of complicated relations. All in all very powerful and easy to use, but, alas, it needs software changes. Nothing complicated but in the essential parts. Nominatim only shows the same way when the classification is different, see [1] for a split street showing multiple results, and [2] for one showing only one segment If you click on (details http://nominatim.openstreetmap.org/details.php?place_id=152179547) of [2] you see that it's only a split of Molenstraat and if you click on Search for more results http://nominatim.openstreetmap.org/search?format=htmlexclude_place_ids=152179547,90789266,57800141,152183937,58188920,57651969,89772878,126246678,2642012399,50709423,118353426,2642012397,2642012398,58361979,98773793,57793661,50786385,80736363,123201401,100889764,15832600accept-language=en,fr;q=0.8,wa;q=0.6,ru;q=0.4,nl;q=0.2viewbox=4.38%2C51.11%2C4.41%2C51.09q=Molenstraat%2C+rumst you get another split and it's not very clear at all how that street is split http://www.openstreetmap.org/search?query=molenstraat%20rumst#map=16/51.1009/4.3920, it looks like Nominatim is only showing parts of the splits. It would obviously work better if there were no splits but patches. André. PS: Oops, I first thought that molen were moles and I wondered if they were under the street and drinking a cup of coffee http://www.openstreetmap.org/way/166577477 ;-)They are in fact mills like this water mill http://www.openstreetmap.org/node/259975902#map=19/50.52639/5.52305 that I just mapped and that's probably the best known in Belgium. regards m. [1] http://nominatim.openstreetmap.org/search.php?q=steenweg+op+waarloosviewbox=-112.33%2C46.38%2C112.33%2C-46.38 [2] http://nominatim.openstreetmap.org/search.php?q=Molenstraat%2C+rumstviewbox=4.38%2C51.11%2C4.41%2C51.09 ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk] Tile CDN
Hi! Serving tiles for Austria via Pula doesn't make that much sense. It should be something near to DE-CIX (or VIX). Hetzner for instance is ok. Sample traceroutes for the two biggest Austrian ISPs (A1/Telekom Austria and UPC): traceroute to c.tile.openstreetmap.org (193.198.233.211), 30 hops max, 60 byte packets 1 A1 (80.122.177.***) 86.762 ms 86.498 ms 86.260 ms 2 62.47.95.239 (62.47.95.239) 26.372 ms 42.702 ms 44.726 ms 3 195.3.65.5 (195.3.65.5) 33.910 ms 34.688 ms 37.299 ms 4 195.3.70.154 (195.3.70.154) 39.271 ms 195.3.70.178 (195.3.70.178) 41.516 ms 195.3.70.90 (195.3.70.90) 43.640 ms 5 win-b4-link.telia.net (213.248.96.1) 45.959 ms 49.064 ms 50.281 ms 6 win-bb2-link.telia.net (80.91.253.169) 53.012 ms prag-bb1-link.telia.net (62.115.137.2) 34.078 ms prag-bb1-link.telia.net (62.115.137.8) 29.243 ms 7 ffm-bb2-link.telia.net (62.115.136.134) 48.694 ms ffm-bb2-link.telia.net (213.155.136.140) 40.443 ms ffm-bb2-link.telia.net (80.91.248.146) 44.332 ms 8 ffm-b12-link.telia.net (62.115.141.227) 43.275 ms ffm-b12-link.telia.net (62.115.142.63) 38.701 ms ffm-b12-link.telia.net (62.115.142.33) 50.489 ms 9 be100.agr21.fra03.atlas.cogentco.com (130.117.14.89) 46.761 ms 47.312 ms 51.858 ms 10 be2184.ccr41.fra03.atlas.cogentco.com (130.117.48.70) 47.410 ms be2188.ccr42.fra03.atlas.cogentco.com (130.117.48.114) 47.222 ms 47.999 ms 11 be2228.ccr21.muc01.atlas.cogentco.com (154.54.38.50) 47.130 ms 51.178 ms 44.715 ms 12 be2223.ccr21.vie01.atlas.cogentco.com (130.117.49.138) 38.774 ms be2200.ccr21.vie01.atlas.cogentco.com (130.117.49.2) 36.057 ms be2223.ccr21.vie01.atlas.cogentco.com (130.117.49.138) 41.548 ms 13 te7-2.ccr01.zag01.atlas.cogentco.com (130.117.48.146) 54.598 ms te7-1.ccr01.zag01.atlas.cogentco.com (130.117.48.138) 55.577 ms te7-2.ccr01.zag01.atlas.cogentco.com (130.117.48.146) 51.390 ms 14 te2-1.ccr01.zag02.atlas.cogentco.com (154.54.39.226) 55.622 ms 56.259 ms 58.959 ms 15 149.14.6.18 (149.14.6.18) 63.394 ms 67.632 ms 63.001 ms 16 CN-Efpu-02-ES.core.carnet.hr (193.198.236.38) 65.622 ms 66.795 ms 74.672 ms 17 CN-Efpu-02-ES.core.carnet.hr (193.198.236.38) 76.623 ms 73.920 ms 75.922 ms 18 * * * traceroute to pula.tile.openstreetmap.org (193.198.233.211), 30 hops max, 40 byte packets 1 UPC (83.64.140.***) 0.641 ms 0.642 ms 0.644 ms 2 84.116.231.158 (84.116.231.158) 3.713 ms 3.617 ms 3.801 ms 3 84.116.229.173 (84.116.229.173) 4.517 ms 5.187 ms 4.722 ms 4 at-vie15a-rd1-vl-2048.aorta.net (84.116.228.149) 104.920 ms 104.850 ms 104.882 ms 5 uk-lon01b-rd1-xe-1-0-1.aorta.net (84.116.132.37) 103.962 ms 104.369 ms 107.223 ms 6 de-fra01a-ri2-xe-4-0-0.aorta.net (84.116.130.138) 105.414 ms ch-zrh02a-ra1-xe-0-2-0.aorta.net (84.116.130.86) 105.210 ms 84-116-130-141.aorta.net (84.116.130.141) 103.772 ms 7 84.116.135.77 (84.116.135.77) 103.324 ms 84.116.135.73 (84.116.135.73) 103.068 ms 104.511 ms 8 nyk-b3-link.telia.net (62.115.13.73) 110.437 ms 110.727 ms 123.275 ms 9 nyk-bb1-link.telia.net (80.91.245.81) 127.268 ms 110.546 ms nyk-bb1-link.telia.net (80.239.147.135) 110.771 ms 10 nyk-b5-link.telia.net (213.155.131.137) 112.878 ms 112.757 ms nyk-b5-link.telia.net (213.155.135.19) 112.064 ms 11 cogent-ic-151338-nyk-b5.c.telia.net (213.248.85.106) 110.379 ms 110.596 ms 110.396 ms 12 be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 113.726 ms be2060.ccr41.jfk02.atlas.cogentco.com (154.54.31.9) 112.846 ms be2061.ccr42.jfk02.atlas.cogentco.com (154.54.3.69) 114.274 ms 13 be2317.ccr41.lon13.atlas.cogentco.com (154.54.30.186) 184.726 ms 185.506 ms be2490.ccr42.lon13.atlas.cogentco.com (154.54.42.86) 185.670 ms 14 be2194.ccr41.ams03.atlas.cogentco.com (130.117.50.242) 199.053 ms be2488.ccr42.ams03.atlas.cogentco.com (154.54.39.109) 190.646 ms 190.103 ms 15 be2261.ccr41.fra03.atlas.cogentco.com (154.54.37.30) 199.521 ms be2262.ccr42.fra03.atlas.cogentco.com (154.54.37.34) 193.258 ms be2261.ccr41.fra03.atlas.cogentco.com (154.54.37.30) 194.704 ms 16 be2229.ccr22.muc01.atlas.cogentco.com (154.54.38.58) 200.374 ms be2228.ccr21.muc01.atlas.cogentco.com (154.54.38.50) 206.550 ms be2229.ccr22.muc01.atlas.cogentco.com (154.54.38.58) 203.352 ms 17 be2200.ccr21.vie01.atlas.cogentco.com (130.117.49.2) 208.644 ms 207.409 ms be2223.ccr21.vie01.atlas.cogentco.com (130.117.49.138) 209.604 ms 18 te1-2.ccr01.zag01.atlas.cogentco.com (130.117.48.78) 295.101 ms te7-1.ccr01.zag01.atlas.cogentco.com (130.117.48.138) 307.710 ms te3-5.ccr01.zag01.atlas.cogentco.com (154.54.62.34) 315.770 ms 19 te2-1.ccr01.zag02.atlas.cogentco.com (154.54.39.226) 219.339 ms te3-1.ccr01.zag02.atlas.cogentco.com (154.54.56.6) 216.558 ms te2-1.ccr01.zag02.atlas.cogentco.com (154.54.39.226) 223.595 ms 20 149.14.6.18 (149.14.6.18) 223.196 ms 221.164 ms 223.960 ms 21 CN-Efpu-02-ES.core.carnet.hr (193.198.236.38) 221.556 ms 222.032 ms 223.117 ms 22 CN-Efpu-02-ES.core.carnet.hr (193.198.236.38)
Re: [OSM-talk] Request for feedback: new building colours in openstreetmap-carto
See also https://github.com/gravitystorm/openstreetmap-carto/issues/1176 that proposes adding buildings with historic=castle to major buildings. Currently only buildings with place_of_worship are recognized as major and are rendered with special style (=darker). 2015-01-02 18:17 GMT+01:00 Matthijs Melissen i...@matthijsmelissen.nl: On 27 November 2014 at 01:16, Matthijs Melissen i...@matthijsmelissen.nl wrote: We are considering to change the colour of buildings in openstreetmap-carto, the default rendering on openstreetmap.org. Because this change has a significant effect on the looks of the map, we would like to consult the community before going ahead with this change. I would like to thank everyone for their feedback, either here or on Github. The new style has been accepted with some improvements, and is about to be deployed. We have changed some aspects of the rendering as the result of your suggestions. In particular, we made the buildings a bit darker on zoom levels up to zoom 14, and we shifted the colour to colour that is more gray rather than brownish. There are still a couple of minor issues of which we are aware, such as the rendering of buildings on top of barracks. We will keep working on solving these. We also haven't taken a definite decision on whether to render churches darker or not. It is clear that opinions diverge on this topic. We might reconsider the decision to render churches darker in the future. -- Matthijs ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hemnet.se using OSM data without attribution
I had a quick look at it. Given that the OSM data is clearly separate from the google map background I don't see any problem with that aspect. They naturally should add attribution to OSM as soon as they display the buildings, IMHO on the map. Naturally if the agreement they have entered in to with google is anything like their standard TCs then they likely have a problem with googles terms, but that is not our problem. Simon Am 02.01.2015 um 08:54 schrieb Andreas Vilén: The Swedish real estate website hemnet.se http://hemnet.se has started using OSM data for buildings on top of Google maps on their website. To see it, go to http://www.hemnet.se/ , click sök på karta (under the map) and zoom in on some bigger city that should have building data (for example Stockholm). Sadly they do not credit us but only give a link to is a building missing? with an explanation of how OSM works and that they use OSM for buildings and Google for everything else: http://www.hemnet.se/om/kartdata Of course my first instinct is to ask them to credit us with the same prominence as Google but then it hit me: are they allowed to mix map data like this? What would be the best course of action from here? Regards Andreas (Grillo) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Request for feedback: new building colours in openstreetmap-carto
On 27 November 2014 at 01:16, Matthijs Melissen i...@matthijsmelissen.nl wrote: We are considering to change the colour of buildings in openstreetmap-carto, the default rendering on openstreetmap.org. Because this change has a significant effect on the looks of the map, we would like to consult the community before going ahead with this change. I would like to thank everyone for their feedback, either here or on Github. The new style has been accepted with some improvements, and is about to be deployed. We have changed some aspects of the rendering as the result of your suggestions. In particular, we made the buildings a bit darker on zoom levels up to zoom 14, and we shifted the colour to colour that is more gray rather than brownish. There are still a couple of minor issues of which we are aware, such as the rendering of buildings on top of barracks. We will keep working on solving these. We also haven't taken a definite decision on whether to render churches darker or not. It is clear that opinions diverge on this topic. We might reconsider the decision to render churches darker in the future. -- Matthijs ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Release openstreetmap-carto v2.26.0
Dear all, Today, v2.26.0 of the openstreetmap-carto stylesheet has been released. It will be rolled out to the openstreetmap.org servers soon. Changes include: * Buildings are now rendered in a much lighter colour * Airport labels are rendered in a different colour * The tag natural=mud is rendered from z10 instead of z13 * City names no longer hide country and state names on low zoom levels * The tag natural=saddle is now rendered * Areas tagged as tourism=attraction are no longer rendered in a special way * Various bug fixes For a full list of commits, see https://github.com/gravitystorm/openstreetmap-carto/compare/v2.25.0...v2.26.0. As always, we welcome any bug reports at https://github.com/gravitystorm/openstreetmap-carto/issues. -- Matthijs ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tile CDN
On 02/01/15 17:40, Andreas Labres wrote: Serving tiles for Austria via Pula doesn't make that much sense. It should be something near to DE-CIX (or VIX). Hetzner for instance is ok. The machine at Hetzner (tabaluga) is already very heavily loaded serving Germany (and not much else). More to the point, we do not currently have the necessary technology to choose a server based on network topology, so we use physical distance as the measure instead. The change of DNS server that was hinted at in the blog post today does open the door to doing it on a network topology data, but first we need a good source of data for that. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] weeklyOSM
The weekly round-up of OSM news, issue # 232, is now available online in English, giving as always a summary of all things happening in the openstreetmap world: http://www.weeklyosm.eu Enjoy! ## Manfred Reiter - mobile - please excuse typos and brevity ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Gemeentelijke herindeling
On Thursday, January 1, 2015 12:23:39 AM CEST, Sebastiaan Couwenberg wrote: On 12/27/2014 07:06 PM, Stefan de Konink wrote: On Saturday, December 27, 2014 4:24:16 PM CEST, Sebastiaan Couwenberg wrote: ... Done: http://www.openstreetmap.org/changeset/27832460 Expire draait nu mee, en de OSM laag wordt nu opnieuw gerenderd. -- Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] OpenGeo maakt dagelijkse mutaties BAG beschikbaar
Lectori salutem! Zoals eerder aangekondigd ziet Stichting OpenGeo noodzaak om het monopolie op de distributie van de dagelijkse mutatie bestanden van de Basisregistratie Adressen en Gebouwen door het Kadaster en haar diensten zoals PDOK te doorbreken. Het deze stap hoopt onze stichting dat er meer diensten zullen ontstaan die van de actualiteit van de BAG gebruik kunnen maken en hierop direct kunnen reageren, door slechts de drempel van eenmalige vertrekkingskosten weg te nemen. Comform de licentie voorwaarden van de BAG [1] te vinden op data.overheid.nl valt de data in het publieke domein. Een van de diensten die daarom gemaakt zou kunnen worden is een OpenStreetBug koppeling op basis van wijzigingen in de BAG. Geolocatie diensten en adressenbestanden kunnen nu met een hogere frequentie worden bijgewerkt. Wij hopen dat dit ook de kwaliteit en het aantal terugmeldingen op de BAG door de markt in 2015 zal verhogen. U kunt bij deze data via de OpenStreetMap mirror, waarvan de netwerk infrastructuur om niet beschikbaar is gesteld door Oxilion.nl: http://mirror.openstreetmap.nl/bag/ [1] https://data.overheid.nl/data/dataset/basisregistratie-adressen-en-gebouwen-bag- -- Met vriendelijke groet, Stefan de Konink Stichting OpenGeo ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OpenGeo maakt dagelijkse mutaties BAG beschikbaar
2015-01-02 15:16 GMT+01:00 Stefan de Konink ste...@konink.de: Een van de diensten die daarom gemaakt zou kunnen worden is een OpenStreetBug koppeling op basis van wijzigingen in de BAG Ik dacht dat OpenStreetBug stopgezet was ? zie [1] mvg m [1] http://wiki.openstreetmap.org/wiki/OpenStreetBugs ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OpenGeo maakt dagelijkse mutaties BAG beschikbaar
On Friday, January 2, 2015 3:49:54 PM CEST, Marc Gemis wrote: 2015-01-02 15:16 GMT+01:00 Stefan de Konink ste...@konink.de: Een van de diensten die daarom gemaakt zou kunnen worden is een OpenStreetBug koppeling op basis van wijzigingen in de BAG Ik dacht dat OpenStreetBug stopgezet was ? zie [1] Zie grote kansen om de Notes API in te zetten zie [2] ;) [2] http://wiki.openstreetmap.org/wiki/API_v0.6#Map_Notes_API Voorzetje: http://gis.stackexchange.com/questions/724/how-can-i-find-a-point-inside-a-polygon-in-postgis http://api.openstreetmap.org/api/0.6/notes?lat=centerYlon=centerXtext=In de BAG is de geometrie gewijzigd. -- Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OpenGeo maakt dagelijkse mutaties BAG beschikbaar
Hear, hear! The more BAG, the beter! J-. On 2 januari 2015 15:16:03 CET, Stefan de Konink ste...@konink.de wrote: Lectori salutem! Zoals eerder aangekondigd ziet Stichting OpenGeo noodzaak om het monopolie op de distributie van de dagelijkse mutatie bestanden van de Basisregistratie Adressen en Gebouwen door het Kadaster en haar diensten zoals PDOK te doorbreken. Het deze stap hoopt onze stichting dat er meer diensten zullen ontstaan die van de actualiteit van de BAG gebruik kunnen maken en hierop direct kunnen reageren, door slechts de drempel van eenmalige vertrekkingskosten weg te nemen. Comform de licentie voorwaarden van de BAG [1] te vinden op data.overheid.nl valt de data in het publieke domein. Een van de diensten die daarom gemaakt zou kunnen worden is een OpenStreetBug koppeling op basis van wijzigingen in de BAG. Geolocatie diensten en adressenbestanden kunnen nu met een hogere frequentie worden bijgewerkt. Wij hopen dat dit ook de kwaliteit en het aantal terugmeldingen op de BAG door de markt in 2015 zal verhogen. U kunt bij deze data via de OpenStreetMap mirror, waarvan de netwerk infrastructuur om niet beschikbaar is gesteld door Oxilion.nl: http://mirror.openstreetmap.nl/bag/ [1] https://data.overheid.nl/data/dataset/basisregistratie-adressen-en-gebouwen-bag- -- Met vriendelijke groet, Stefan de Konink Stichting OpenGeo ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] JOSM-Fehler
Am 01.01.2015 um 15:44 schrieb Markus: Schönes neues Jahr Die Hauptseite ist so gegliedert, dass zu erst OP-unabhängige Optionen aufgelistet werden. Grau sind Optionen mit Einschränkungen. Da du anscheinend viel mit Windows zu tun hast: nimm den Windows-Installer. Ja, es geht um die Installation auf Windows für Neue :-) Unter Linux gibt es meistens ein Paket im Distributions-Repository, aber benutzen würde ich die auch nicht. _josm-setup.exe_ Du empfiehlst dafür den Windows-Installer. Was sind die Vorzüge für den Neubenutzer? (im Wiki steht dazu nichts, und der Link-Hintergrund ist grau) Wäre damit auch die Fehlermeldung wegen dem Zertifikat erledigt? In josm.openseamap.org wird josm.jnlp empfohlen (grün und zuoberst). Da ändert sich immer mal wieder etwas, allerdings sollte .jnlp das einfachste sein, wobei java+browser ja auch schon problematisch sein kann. _josm.jnlp_ Wenn ich die Wikipedia-Seite zu jnlp richtig verstehe, wird damit eine XML runtergeladen, die vergleichbar mit einer BAT den Installationsprozess steuert? Jedesmal wenn josm.jnlp gestartet wird, wird geprüft, ob es eine neue JOSM-Version gibt (und die ggf. neu runtergeladen)? Ebenfalls wird geprüft, ob es neue Plugins oder Plugin-Versionen gibt? Auch MapPaint-Stile? und Objektvorlagen? Geprüft wird auch, ob ein JAVA existiert? und ob in aktueller Version? Das wäre ja schon ziemlich ideal für Anfänger...?! Eben, jedoch sind einige dieser Feature (zB. Pluginkontrolle) direkt in JOSM implementiert und somit unabhängig von der Installationsweise Aber als ich das auf einen JOSM-jungfräulichen Rechner versuchte, kammen alle die im der vorherigen Mail erwähnten Fehler. Das ist auf jeden Fall einen Bugreport wert, wenn andere .jnlp laufen bei JOSM ansonsten doch eher bei dem entsprechenden Java. _josm-tested.jar_ Auch hier wird dem Benutzer nicht erklärt, welchen Vorteil jar gegenüber den anderen Varianten hat. Aber dier link ist zumindest grün also irgendwie gut? Wenig Information wird gegeben. Vielleicht hilft Dir [1] bzw [2] weiter. Letzten Endes ist es ein Wiki. Ciao fly [1] https://josm.openstreetmap.de/wiki/Download [2] https://josm.openstreetmap.de/wiki/InstallNotes ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jahresrückblick 2014 und Ausblick auf 2015
Hoi, Am 31.12.2014 um 23:08 schrieb Michael Reichert: Ach komm, jetzt heul ned rum und stell de ned so dumm a. Für den Rest der Leserschaft: Gelegentlich passiert es, dass wir https-Links posten, weil das Admin-Interface aus naheliegenden Gründen über HTTPS erreichbar ist. Eigentlich ist das doch prima; schade ist doch viel mehr, das gelegentlich auch Links ohne http*s* rumgeschickt werden Weil wir zu faul sind und es nicht für nötig halten, sparen wir uns den Zertifikatszirkus. Wer dennoch uns gerne per HTTPS erreichen möchte, kann den Fingerprint vergleichen und das Zertifikat importieren. SHA256-Fingerabruck: 77:5F:5B:A0:CB:1F:C3:A5:DD:39:B9:D1:48:E6:A1:32:8A:D7:9F:76:15:BD:17:2A:4B:03:36:FB:55:B4:98:A1 Und so ist es doch eigentlich auch richtig. Optimalerweise den Fingerprint einmal auf analogen Kanal an die Stammtische verschicken und gut ist. Das Zertifikat von offizieller Seite zu signieren gaukelt ja auch nur Sicherheit vor. Wichtig ist imho erstmal, dass sich das Zertifikat nicht ändert und wenns drauf ankommt den Schlüsselt zu überprüfen. Servus und weiter so Morray ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Routing allungato
Qual'è il plugin per josm? Ho alcuni percorsi da controllare pure io :-) grazie Il 02/gen/2015 13:15 Simone Saviolo simone.savi...@gmail.com ha scritto: Il giorno 2 gennaio 2015 11:48, emmexx emm...@tiscalinet.it ha scritto: Qualcuno riescea capire perche' viene proposto il seguente percorso invece di quello lineare? http://osrm.at/awl I tag mi sembrano corretti, le way sono collegate, non ci sono limiti di velocita' che dovrebbero favorire il percorso lungo il controviale. Non solo osrm, anche il plugin di josm propone il percorso non lineare. Non ho analizzato i dati, ma a occhio direi per evitare il semaforo. Ciao, Simone ___ 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] Routing allungato
Il 01/02/2015 03:40 PM, Simone Saviolo scrisse: Il controviale ha un semaforo, la secondary ne ha tre. Ecco svelato il mistero :-) Quand'è che ci mettiamo seriamente a migliorare la mappatura degli incroci? :-) Mappare semafori e' piu' complicato che tirar linee... ;-) Nel caso in oggetto: i 3 semafori sono ovviamente coerenti tra loro, il routing non dovrebbe considerarli come diversi. Tra l'altro credo siano stati messi 3 semafori a causa della mappatura separata (why? domanda retorica) dei tram). C'e' qualche sistema per gestire semafori coordinati tra loro? ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing allungato
Il giorno 2 gennaio 2015 11:48, emmexx emm...@tiscalinet.it ha scritto: Qualcuno riescea capire perche' viene proposto il seguente percorso invece di quello lineare? http://osrm.at/awl I tag mi sembrano corretti, le way sono collegate, non ci sono limiti di velocita' che dovrebbero favorire il percorso lungo il controviale. Non solo osrm, anche il plugin di josm propone il percorso non lineare. Non ho analizzato i dati, ma a occhio direi per evitare il semaforo. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Problema rendering chiese
Grazie per aver sollevato la questione: per quanto riguarda il Veneto nei vecchi import spesso l'amenity corrispondeva con l'area della chiesa e non con l'edificio stesso. Io propongo di ritaggare l'area da: amenity=place_of_worship a landuse=religious come descritto nella wiki: http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dreligious e fare una ricerca di tutti i building=church senza amenity=place_of_worship e aggiungerlo. Richiede un pò di query su overpasstubo ma dovrebbe essere fattibile. Per coloro che sono curiosi sul cambiamento di rendering su OSM.org qui trovate la pull request con relativo esempio di prima e dopo: https://github.com/gravitystorm/openstreetmap-carto/pull/565 A breve l'intera mappa cambierà al nuovo stile. Il giorno 2 gennaio 2015 18:14, Volker Schmidt vosc...@gmail.com ha scritto: Vorrei portare nella lista italiana questo thread: https://lists.openstreetmap.org/pipermail/tagging/2015-January/020741.html Una prima prova su una zona a caso attorno a Padova di circa 90km x 100km mi ha dato 1000 oggetti sospetti con questo ricerca Overpass Turbo: http://overpass-turbo.eu/s/6Nj Sembra che avremo un problema Volker ___ 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] Problema rendering chiese
2015-01-02 18:28 GMT+01:00 girarsi_liste liste.gira...@gmail.com: Io vedo Birmingham. Penso Volker volesse solo indicare la query overpass per individuare gli amenity=place_of_worship, senza il tag building=* Per coloro che sono curiosi sul cambiamento di rendering su OSM.org qui trovate la pull request con relativo esempio di prima e dopo: Fantastico, secondo me una scelta davvero opportuna, rende la mappa molto più seria attenuando il colore dei fabbricati. Qui si vede proprio la differenza prima/dopo: http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#18.00/38.90004/-77.01866 Per quanto riguarda il problema degli amenity=place_of_worship qui si vede il caso in cui l'amenity applicato all'area non viene renderizzato, mentre prima appariva in grigio (invece si vede ancora il fabbricato perchè taggato come building): http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#19.00/38.91146/-77.02861 Concordo con la soluzione proposta da Leonardo che sicuramente risolverebbe il problema del rendering. In definitiva in questo modo si impone che amenity=place_of_worship sia necessariamente collegato ad un building=*, mentre per le aree pertinenziali o i luoghi di culto senza fabbricati si utilizzerebbe il landuse=religious. Ciao Federico ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing allungato
Il giorno 2 gennaio 2015 15:49, emmexx emm...@tiscalinet.it ha scritto: Il 01/02/2015 03:40 PM, Simone Saviolo scrisse: Il controviale ha un semaforo, la secondary ne ha tre. Ecco svelato il mistero :-) Quand'è che ci mettiamo seriamente a migliorare la mappatura degli incroci? :-) Mappare semafori e' piu' complicato che tirar linee... ;-) Nel caso in oggetto: i 3 semafori sono ovviamente coerenti tra loro, il routing non dovrebbe considerarli come diversi. Tra l'altro credo siano stati messi 3 semafori a causa della mappatura separata (why? domanda retorica) dei tram). Più che altro: sono davvero tre semafori automobilistici? O due riguardano solo i tram? C'e' qualche sistema per gestire semafori coordinati tra loro? Si era parlato di fare una relazione per gli incroci, che sarebbe la cosa più giusta. Ma le relazioni sono brutte e cattive, sono difficili, non c'è supporto negli editor, e la maggior parte degli autori concorda nel ritenerle responsabili della fame nel mondo. Quindi si è accantonata l'idea :-) Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Problema rendering chiese
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 02/01/2015 18:14, Volker Schmidt ha scritto: Vorrei portare nella lista italiana questo thread: https://lists.openstreetmap.org/pipermail/tagging/2015-January/020741.html Una prima prova su una zona a caso attorno a Padova di circa 90km x 100km mi ha dato 1000 oggetti sospetti con questo ricerca Overpass Turbo: http://overpass-turbo.eu/s/6Nj Sembra che avremo un problema Volker Io vedo Birmingham. - -- Simone Girardelli _|_|_|_|_|_|_|_|_|_ |_|_|_|_|_|_|_|_|_|_| -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUptUgAAoJEMTPIIVov0ZtcAcIAIp53dtvq/9OQ1xDHuiZYFjK lFmW0cOXFwFofI4uz9Dll/+L8TXEykTRXajyRgtDqJdqFMQ4RjhAr+aVTGf4eHKj FUA68p0SI29kCRl3OJJAQLskNLZUrMd4VlOmfrOLw23zjZTw17vkvnwltaTeXso4 SXTOfVssvMtaFivf8LRzXCGnRLVkWC6n2LntV+Z/jO/b6xKX66ZDXw/Xxz68wpur u3TfwyY0Hexc695i3g/VxmfE+lnf5f3O5lCslRN69c26VaIvoJmEh8X4mhNRRzSV 2ysJUszXKkEwKIZyfvgqbQ23U5bO41G/zV3g0CVLlH5i4/8llWyc7Su31XO8NnQ= =WiWH -END PGP SIGNATURE- ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] mappe città europee
Il giorno 29 dicembre 2014 11:36, Simone Cortesi sim...@cortesi.com ha scritto: su segnalazione vi inoltro il sito: http://www.paologianfrancesco.com/graphic/urban-shape mappe grafiche progettate dall'architetto Paolo Gianfrancesco. Le mappe si basano su dati di Open Street Map. La serie copre tutte le capitali europee. La scelta del colore è basata sulla tavolozza dei colori Pantone in dissolvenza dal più alto valore di popolazione al più basso. Solo io non vedo il valore artistico di questo progetto? Mi sembra che non ci sia alcuna data reduction, nessun vero punto di vista e nessuna interpretazione. Ok, ha scelto una tavolozza di colori, e allora? Trovo molto più interessanti le mappe Watercolor di Stamen. Ciao, Simone ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing allungato
Il controviale ha un semaforo, la secondary ne ha tre. Ecco svelato il mistero :-) Quand'è che ci mettiamo seriamente a migliorare la mappatura degli incroci? :-) Ciao, Simone Il giorno 2 gennaio 2015 15:30, emmexx emm...@tiscalinet.it ha scritto: Il 01/02/2015 01:14 PM, Simone Saviolo scrisse: Non ho analizzato i dati, ma a occhio direi per evitare il semaforo. Semaforo che ad occhio c'e' anche nel controviale, anche se mi sa che non c'e' in osm. Provo a controllare. grazie maxx ___ 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] Problema rendering chiese
Vorrei portare nella lista italiana questo thread: https://lists.openstreetmap.org/pipermail/tagging/2015-January/020741.html Una prima prova su una zona a caso attorno a Padova di circa 90km x 100km mi ha dato 1000 oggetti sospetti con questo ricerca Overpass Turbo: http://overpass-turbo.eu/s/6Nj Sembra che avremo un problema Volker ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Routing allungato
Qualcuno riescea capire perche' viene proposto il seguente percorso invece di quello lineare? http://osrm.at/awl I tag mi sembrano corretti, le way sono collegate, non ci sono limiti di velocita' che dovrebbero favorire il percorso lungo il controviale. Non solo osrm, anche il plugin di josm propone il percorso non lineare. grazie maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing allungato
Il 01/02/2015 01:14 PM, Simone Saviolo scrisse: Non ho analizzato i dati, ma a occhio direi per evitare il semaforo. Semaforo che ad occhio c'e' anche nel controviale, anche se mi sa che non c'e' in osm. Provo a controllare. grazie maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Routing allungato
Il 01/02/2015 01:25 PM, Leonardo Frassetto scrisse: Qual'è il plugin per josm? Cerca nei plugin, si chiama routing. ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Modalità meno note di accesso ai dati cartografici
Andrea, anch'io ero stato incuriosito dal fatto che gli esempi erano incentrati sui dati dell'Umbria, avevo visto dati normalmente non raggiungibili ma non avevo provato a scaricare nulla. Ho controllato e nella pagina delle condizioni d'uso del geoportale: http://geo.umbriaterritorio.it/geoportal/catalog/content/disclaimer.page è riportato il messaggio Le informazioni presenti su questo sito sono considerate pubbliche e possono essere distribuite o copiate, quindi credo sia Public Domain, ma se ad esempio si arriva all'ecografico catastale dalla pagina degli Open Data è presente come servizio WMS ed è riportata la licenza CC-BY 3.0. Può cambiare la licenza a seconda del servizio di distribuzione degli stessi dati? Ciao Marcello Il 31/12/2014 15:18, Andrea Fredduzzi ha scritto: Molto interessante! Seguendo passo passo gli esempi ho scaricato un po di dati dall'ecografico catastale dell'Umbria. Grazie per le dritte. Andrea Fredduzzi Il 29/dic/2014 15:12 aborruso aborr...@gmail.com mailto:aborr...@gmail.com ha scritto: Un thread aggiornato recentemente in questa lista, mi ha stimolato la chiusura di un post che avevo in bozza da diverse settimane. Riguarda l'accesso in REST a server ArcGIS tramite query. Si tratta di una tecnologia proprietaria molto diffusa tra le nostre PA per esporre dati cartografici, ma di solito (lato utente) la usiamo soltanto per accessi in WMS o WFS (rappresentazione dei dati o veri e propri dati). Si tratta però di applicativi server che offrono altre features, ed altre modalità di accesso ai dati, a cui nemmeno pensiamo, proprio perché sono poco note. Modalità che consentono di acquisire dati che potrebbero essere utili per OSM. Nel post faccio qualche esempio: http://blog.spaziogis.it/2014/12/29/take-the-best-use-the-rest/ Saluti, a - Andrea Borruso email: aborr...@tin.it mailto:aborr...@tin.it website: http://blog.spaziogis.it my 2.0 life: http://aborruso.spaziogis.it feed: http://feeds2.feedburner.com/Tanto 38° 7' 48 N, 13° 21' 9 E -- View this message in context: http://gis.19327.n5.nabble.com/Modalita-meno-note-di-accesso-ai-dati-cartografici-tp5828410.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org mailto: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] Modalità meno note di accesso ai dati cartografici
Ciao Marcello, Marcello Arcangeli wrote Ho controllato e nella pagina delle condizioni d'uso del geoportale: http://geo.umbriaterritorio.it/geoportal/catalog/content/disclaimer.page è riportato il messaggio Le informazioni presenti su questo sito sono considerate pubbliche e possono essere distribuite o copiate, quindi credo sia Public Domain, ma se ad esempio si arriva all'ecografico catastale dalla pagina degli Open Data è presente come servizio WMS ed è riportata la licenza CC-BY 3.0. Può cambiare la licenza a seconda del servizio di distribuzione degli stessi dati? la licenza del geoportale di cui inserisci il link, secondo copre i contenuti delle pagine del sito http://geo.umbriaterritorio.it/. Sui dati in genere, su http://geo.umbriaterritorio.it/ non mi sembra che ci sia un licenza generica, e quindi laddove non dichiarato dovrebbe essere un open by default, quindi una sorta di CC BY. Ci tengo a precisare, non lo dico per te, che il post non è scritto per raccontare di una modalità strumentale per scavalcare una barriera formale, ma per mostrare dei servizi pubblici molto diffusi per accedere a dati e informazioni spaziali, molto ben documentati e con delle belle librerie a supporto. Ma poco noti. Strumenti e licenza d'uso devono comunque essere ben accoppiati rispetto all'obiettivo finale. Le PA potrebbero con il tempo fare una paginetta più per esperti, con un paio di esempio di chiamate d'uso, gli output raw e qualche rendering; e con una dichiarazione sulla licenza. Ciao, a - Andrea Borruso email: aborr...@tin.it website: http://blog.spaziogis.it my 2.0 life: http://aborruso.spaziogis.it feed: http://feeds2.feedburner.com/Tanto 38° 7' 48 N, 13° 21' 9 E -- View this message in context: http://gis.19327.n5.nabble.com/Modalita-meno-note-di-accesso-ai-dati-cartografici-tp5828410p5828790.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] Problema rendering chiese
Ciao, mi sa che l'hanno rilasciato subito... https://c.tile.openstreetmap.org/17/68787/47453.png Stefano Il giorno 2 gennaio 2015 21:44, Federico Cortese cortese...@gmail.com ha scritto: 2015-01-02 18:28 GMT+01:00 girarsi_liste liste.gira...@gmail.com: Io vedo Birmingham. Penso Volker volesse solo indicare la query overpass per individuare gli amenity=place_of_worship, senza il tag building=* Per coloro che sono curiosi sul cambiamento di rendering su OSM.org qui trovate la pull request con relativo esempio di prima e dopo: Fantastico, secondo me una scelta davvero opportuna, rende la mappa molto più seria attenuando il colore dei fabbricati. Qui si vede proprio la differenza prima/dopo: http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#18.00/38.90004/-77.01866 Per quanto riguarda il problema degli amenity=place_of_worship qui si vede il caso in cui l'amenity applicato all'area non viene renderizzato, mentre prima appariva in grigio (invece si vede ancora il fabbricato perchè taggato come building): http://bl.ocks.org/pnorman/raw/c61d6b11193081910866/#19.00/38.91146/-77.02861 Concordo con la soluzione proposta da Leonardo che sicuramente risolverebbe il problema del rendering. In definitiva in questo modo si impone che amenity=place_of_worship sia necessariamente collegato ad un building=*, mentre per le aree pertinenziali o i luoghi di culto senza fabbricati si utilizzerebbe il landuse=religious. Ciao Federico ___ 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] Problema rendering chiese
2015-01-02 22:48 GMT+01:00 sabas88 saba...@gmail.com: Ciao, mi sa che l'hanno rilasciato subito... https://c.tile.openstreetmap.org/17/68787/47453.png non sto capendo come mai genova la vedo col nuovo stile, mentre trento con quello vecchio, ed ho anche provato a far ricaricare le tiles... Stefano -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-co] Fwd: Re: [talk-latam] Más regiones para Mapazonia
En la lista de latinoamérica se está cocinando el mapeo de la amazonía y colocaron una tarea en el task manager. Todos bienvenidos a mapear. Happy mapping! -- Forwarded message -- From: wille wi...@wille.blog.br Date: Jan 2, 2015 10:31 AM Subject: Re: [talk-latam] Más regiones para Mapazonia To: OpenStreetMap Latinoamérica talk-la...@openstreetmap.org Cc: Yo he creado la actividad de Mapazonia Colombia: http://tasks.hotosm.org/ project/832 Mauricio puede añadila al sitio web? Hola, Johnattan! Necesitamos elegir una región prioritaria en Peru para crearmos la actividad en el Tasking Manager. Tiene alguna idea de una área que no esté tan bien mapeada y que tengamos buenas imágenes de satélite? Wille Em 2015-01-01 19:03, Johnattan Rupire escreveu: Si se pudiera hacer esto para la amazonía en Perú, nos alegrarían la vida a muchos... Saludos y gracias por el trabajo! El 31/12/14 a las 13:40, Igor TAmara escribió: Buenísimo, todo lo que tenga aerofotografía lo deberíamos colocar, tu indicas la tarea y propagamos en la lista de correo de Colombia para recibir colaboraciones. Muchas gracias. El 30 de diciembre de 2014, 20:20, Wille wi...@wille.blog.br escribió: Hola Igor, Encontré dos regiones en Colombia con imágenes de alta resolución y ríos que necesitan ser mapeados o mejorados. Una región tiene 632 km² y la otra tiene 52 km². https://gist.github.com/willemarcel/c607950f0e9b03f8b2ac [2] Si está de acuerdo, puedo poner estas dos áreas en el Tasking Manager. hasta luego, wille On 25-12-2014 17:07, Igor TAmara wrote: Hola, en http://test.openstreetmap.co/ [3] tenemos un mapa con aerofotografía que hemos identificado, lastimosamente hay poco en la parte de la Amazonía, pero creo que de allí se podría tomar información para apuntarnos a mapear en el proyecto. Lo primero que hicimos fue marcar las zonas que contaban con resolución en un polígono. Con overpass creo que se puede mejorar esto apuntando primero estos polígonos, http://overpass-turbo.eu/s/6FU [4] Les parece? El 22 de diciembre de 2014, 21:11, Wille wi...@wille.blog.br escribió: Hola, El mapeo de la cuenca del Río Acre ya está 60% hecho y la tarea brasileña ya está en 27%. Creo que ya está en el momento de definir nuevas regiones para poner en el Tasking Manager. Hay alguien de Peru, Colombia o Venezuela acá? Caso no, alguien puede sugerir regiones que necesitan ser mapeadas en estos países? hasta luego, wille ___ talk-latam mailing list talk-la...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam [1] ___ talk-latam mailing list talk-la...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam [1] ___ talk-latam mailing list talk-la...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam [1] ___ talk-latam mailing list talk-la...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam [1] Links: -- [1] https://lists.openstreetmap.org/listinfo/talk-latam [2] https://gist.github.com/willemarcel/c607950f0e9b03f8b2ac [3] http://test.openstreetmap.co/ [4] http://overpass-turbo.eu/s/6FU ___ talk-latam mailing list talk-la...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam -- wille http://wille.blog.br ___ talk-latam mailing list talk-la...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-latam ___ Talk-co mailing list Talk-co@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-dk] Stier og veje i Jægersborg Dyrehave
Hej, Jeg ved godt at det var en opstramning af modellen for service veje, men jeg syntes at det giver god mening at navngivne service veje har en tilhørende rigtig vej med samme navn. Wikien siger forøvrigt om service veje: For access roads to, or within an industrial estate, camp site, business park, car park etc. Derfor er dit eksempel (http://www.openstreetmap.org/way/102276421) korrekt. Det var i rollen som 'landlige tilkørselsveje' jeg forsøgte at definere service veje. Her er et andet eksempel: http://osm.org/go/0SpZxaFrE-?way=147076066 (det er muligvis forkert - hovedvejen hedder muligvis Skibstedvej, men det kan stadig bruges som eksempel). Hvis vi antager at hovedvejens navn er korrekt, og der her kun er tre huse på Skibstedvej, skal den så være service eller unclassified? On Friday, January 02, 2015 12:57:47 Michael Andersen wrote: Det er ikke ualmindeligt at skovveje har egne navne. Se bare... De findes helt sikkert, men de er sjældne i forhold til unavngivne tracks. /Michael On Friday, January 02, 2015 12:13:27 Niels Elgaard Larsen wrote: On 02-01-2015 09:53, Michael Larsen wrote: Hej, Generelt en god beskrivelse af de forskellige vejkategorier. Man kunne overveje følgende tilføjelser: Anden privat fællesvej: service En navngiven servicevej kan kun eksistere i sammenhæng med en tilsvarende navngiven vej af højere 'rang' (fx. residential, living_street eller unclassified). Service veje er typisk forbindelser mellem 'rigtige veje' og adresser etc. Jeg synes godt, at man kan navngive separate serviceways, fx på militærområder, industriområder, osv. Jeg har også set alleys i udlandet, som var navngivet uden at der var en større vej med samme navn. http://www.openstreetmap.org/way/102276421 Disse veje kan ofte findes på landet, hvor man fx. kan finde tre huse med deres egen vej - i sådanne tilfælde vil jeg mene at vejen er af typen unclassified og ikke service. Hvis husene er uafhængige. Tit er det fx en større gård, hvor et par bygninger, har fået hver deres adresseknude. Så er det stadig service. Hvis to parcelhuse deler en indkørsel på 20 meter, så synes jeg heller ikke at det er en unclassified eller residential vej. Privat indkørsel til enkelt ejendom: service + service=driveway Indkørsler navngives iht. til den adresse de giver adgang til. En indkørsel markeres kun med 'access=private' hvis det er skiltet. Privat mark- eller skovvej, der ikke anvendes som adgangsvej til adresse: track (også hvis den private ejer er Skov- og Naturstyrelsen eller lignende) God pointe med adressen - veje som giver adgang til adresser har rang af service eller højere. Deraf følger også at tracks sjældent har navne. En typisk undtagelse som jeg har observeret er vindmøller - de har ofte en adresse, men jeg vil mene vejen dertil ofte er et track. Jeg mener klart, at det er service. Vejene til dem er jo netop lavet for at kunne servicere vindmøllerne. Dvs. navngivne tracks som ikke er i nærheden af vindmøller burde være sjældne. Prøv fx. nedenstående overpass søgning - der er mange tracks der måske burde ændres til service: Hvis du mener med samme navn som en større vej, er jeg enig. Men selvom de fleste tracks ikke har navne, er der ikke noget galt i det. Hvis en landmand ejer en markvej og han har lyst til at give den et navn og sætter en skilt op på vejen, så hedder den vel det, han har kaldt den. Det er jo hans vej. http://overpass-turbo.eu/s/6MA /Michael On Tuesday, December 23, 2014 17:06:13 Ole Nielsen / osm wrote: OgsÃ¥ enig. Her vestpÃ¥ er der stadig en del grusveje som er fælles for flere huse og bruges af alle slags køretøjer. De er forhÃ¥bentlig taggede med highway=unclassified og surface=gravel eller surface=unpaved. Nogle af dem er ret ringe, sÃ¥ de burde egentlig tagges med tracktype=grade4. Det mÃ¥ man godt, men om renderen kan bruge det ved jeg ikke. For mig ligger der en eller anden landbrugs- eller forstmæssig benyttelse i ordet track, dvs markvej eller skovvej, hvor der normalt ikke er adgang for familiebiler, selv om adgangen selvfølgelig ogsÃ¥ kan tagges. Jeg ville umiddelbart være ked af at bil-ruteren ledte mig ud pÃ¥ et track. Jeg har i øvrigt fundet en potentiel fejlkilde mere til disse tags: Potlatch har nogle tvetydige smÃ¥billeder, og kan i øvrigt heller ikke foreslÃ¥ tracktype. Enig. Det er vejens brug og ejerforhold og ikke overfladen, som afgør om det er track, residential, unclassified, service etc. Min opfattelse af grusvejes klassifikation: Offentlig vej med eget vejnavn: residential eller unclassified Privat fællesvej med eget vejnavn (f.eks i sommerhusområde): residential eller unclassified Anden privat fællesvej: service Privat indkørsel til enkelt ejendom: service + service=driveway Privat mark- eller skovvej, der ikke anvendes som adgangsvej til adresse: track (også
Re: [Talk-dk] Stier og veje i Jægersborg Dyrehave
On 02-01-2015 09:53, Michael Larsen wrote: Hej, Generelt en god beskrivelse af de forskellige vejkategorier. Man kunne overveje følgende tilføjelser: Anden privat fællesvej: service En navngiven servicevej kan kun eksistere i sammenhæng med en tilsvarende navngiven vej af højere 'rang' (fx. residential, living_street eller unclassified). Service veje er typisk forbindelser mellem 'rigtige veje' og adresser etc. Jeg synes godt, at man kan navngive separate serviceways, fx på militærområder, industriområder, osv. Jeg har også set alleys i udlandet, som var navngivet uden at der var en større vej med samme navn. http://www.openstreetmap.org/way/102276421 Disse veje kan ofte findes på landet, hvor man fx. kan finde tre huse med deres egen vej - i sådanne tilfælde vil jeg mene at vejen er af typen unclassified og ikke service. Hvis husene er uafhængige. Tit er det fx en større gård, hvor et par bygninger, har fået hver deres adresseknude. Så er det stadig service. Hvis to parcelhuse deler en indkørsel på 20 meter, så synes jeg heller ikke at det er en unclassified eller residential vej. Privat indkørsel til enkelt ejendom: service + service=driveway Indkørsler navngives iht. til den adresse de giver adgang til. En indkørsel markeres kun med 'access=private' hvis det er skiltet. Privat mark- eller skovvej, der ikke anvendes som adgangsvej til adresse: track (også hvis den private ejer er Skov- og Naturstyrelsen eller lignende) God pointe med adressen - veje som giver adgang til adresser har rang af service eller højere. Deraf følger også at tracks sjældent har navne. En typisk undtagelse som jeg har observeret er vindmøller - de har ofte en adresse, men jeg vil mene vejen dertil ofte er et track. Jeg mener klart, at det er service. Vejene til dem er jo netop lavet for at kunne servicere vindmøllerne. Dvs. navngivne tracks som ikke er i nærheden af vindmøller burde være sjældne. Prøv fx. nedenstående overpass søgning - der er mange tracks der måske burde ændres til service: Hvis du mener med samme navn som en større vej, er jeg enig. Men selvom de fleste tracks ikke har navne, er der ikke noget galt i det. Hvis en landmand ejer en markvej og han har lyst til at give den et navn og sætter en skilt op på vejen, så hedder den vel det, han har kaldt den. Det er jo hans vej. http://overpass-turbo.eu/s/6MA /Michael On Tuesday, December 23, 2014 17:06:13 Ole Nielsen / osm wrote: OgsÃ¥ enig. Her vestpÃ¥ er der stadig en del grusveje som er fælles for flere huse og bruges af alle slags køretøjer. De er forhÃ¥bentlig taggede med highway=unclassified og surface=gravel eller surface=unpaved. Nogle af dem er ret ringe, sÃ¥ de burde egentlig tagges med tracktype=grade4. Det mÃ¥ man godt, men om renderen kan bruge det ved jeg ikke. For mig ligger der en eller anden landbrugs- eller forstmæssig benyttelse i ordet track, dvs markvej eller skovvej, hvor der normalt ikke er adgang for familiebiler, selv om adgangen selvfølgelig ogsÃ¥ kan tagges. Jeg ville umiddelbart være ked af at bil-ruteren ledte mig ud pÃ¥ et track. Jeg har i øvrigt fundet en potentiel fejlkilde mere til disse tags: Potlatch har nogle tvetydige smÃ¥billeder, og kan i øvrigt heller ikke foreslÃ¥ tracktype. Enig. Det er vejens brug og ejerforhold og ikke overfladen, som afgør om det er track, residential, unclassified, service etc. Min opfattelse af grusvejes klassifikation: Offentlig vej med eget vejnavn: residential eller unclassified Privat fællesvej med eget vejnavn (f.eks i sommerhusområde): residential eller unclassified Anden privat fællesvej: service Privat indkørsel til enkelt ejendom: service + service=driveway Privat mark- eller skovvej, der ikke anvendes som adgangsvej til adresse: track (også hvis den private ejer er Skov- og Naturstyrelsen eller lignende) Sti/vej skiltet som gangsti: footway Sti/vej skiltet som cykelsti: cycleway Sti/vej skiltet som ridesti: bridleway Sti uden skilt i skov eller åbent land, der ikke (kan) anvendes af tosporede køretøjer: path Vi mangler stadig den entydige begyndervejledning... Ja. Det her er ikke en begyndervejledning, men kan hjælpe til at afgøre standard adgangsforhold til tracks, paths med videre: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions# Denmark Jeg har brugt Skov og Naturstyrelsens vejledning om adgangsregler som basis for tabellens data for stier og skov- og markveje. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk -- Niels Elgaard Larsen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Stier og veje i Jægersborg Dyrehave
Hej, Generelt en god beskrivelse af de forskellige vejkategorier. Man kunne overveje følgende tilføjelser: Anden privat fællesvej: service En navngiven servicevej kan kun eksistere i sammenhæng med en tilsvarende navngiven vej af højere 'rang' (fx. residential, living_street eller unclassified). Service veje er typisk forbindelser mellem 'rigtige veje' og adresser etc. Disse veje kan ofte findes på landet, hvor man fx. kan finde tre huse med deres egen vej - i sådanne tilfælde vil jeg mene at vejen er af typen unclassified og ikke service. Privat indkørsel til enkelt ejendom: service + service=driveway Indkørsler navngives iht. til den adresse de giver adgang til. En indkørsel markeres kun med 'access=private' hvis det er skiltet. Privat mark- eller skovvej, der ikke anvendes som adgangsvej til adresse: track (også hvis den private ejer er Skov- og Naturstyrelsen eller lignende) God pointe med adressen - veje som giver adgang til adresser har rang af service eller højere. Deraf følger også at tracks sjældent har navne. En typisk undtagelse som jeg har observeret er vindmøller - de har ofte en adresse, men jeg vil mene vejen dertil ofte er et track. Dvs. navngivne tracks som ikke er i nærheden af vindmøller burde være sjældne. Prøv fx. nedenstående overpass søgning - der er mange tracks der måske burde ændres til service: http://overpass-turbo.eu/s/6MA /Michael On Tuesday, December 23, 2014 17:06:13 Ole Nielsen / osm wrote: OgsÃ¥ enig. Her vestpÃ¥ er der stadig en del grusveje som er fælles for flere huse og bruges af alle slags køretøjer. De er forhÃ¥bentlig taggede med highway=unclassified og surface=gravel eller surface=unpaved. Nogle af dem er ret ringe, sÃ¥ de burde egentlig tagges med tracktype=grade4. Det mÃ¥ man godt, men om renderen kan bruge det ved jeg ikke. For mig ligger der en eller anden landbrugs- eller forstmæssig benyttelse i ordet track, dvs markvej eller skovvej, hvor der normalt ikke er adgang for familiebiler, selv om adgangen selvfølgelig ogsÃ¥ kan tagges. Jeg ville umiddelbart være ked af at bil-ruteren ledte mig ud pÃ¥ et track. Jeg har i øvrigt fundet en potentiel fejlkilde mere til disse tags: Potlatch har nogle tvetydige smÃ¥billeder, og kan i øvrigt heller ikke foreslÃ¥ tracktype. Enig. Det er vejens brug og ejerforhold og ikke overfladen, som afgør om det er track, residential, unclassified, service etc. Min opfattelse af grusvejes klassifikation: Offentlig vej med eget vejnavn: residential eller unclassified Privat fællesvej med eget vejnavn (f.eks i sommerhusområde): residential eller unclassified Anden privat fællesvej: service Privat indkørsel til enkelt ejendom: service + service=driveway Privat mark- eller skovvej, der ikke anvendes som adgangsvej til adresse: track (også hvis den private ejer er Skov- og Naturstyrelsen eller lignende) Sti/vej skiltet som gangsti: footway Sti/vej skiltet som cykelsti: cycleway Sti/vej skiltet som ridesti: bridleway Sti uden skilt i skov eller åbent land, der ikke (kan) anvendes af tosporede køretøjer: path Vi mangler stadig den entydige begyndervejledning... Ja. Det her er ikke en begyndervejledning, men kan hjælpe til at afgøre standard adgangsforhold til tracks, paths med videre: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions# Denmark Jeg har brugt Skov og Naturstyrelsens vejledning om adgangsregler som basis for tabellens data for stier og skov- og markveje. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Stier og veje i Jægersborg Dyrehave
Fredag den 2. januar 2015 12:13:27 skrev Niels Elgaard Larsen: God pointe med adressen - veje som giver adgang til adresser har rang af service eller højere. Deraf følger også at tracks sjældent har navne. En typisk undtagelse som jeg har observeret er vindmøller - de har ofte en adresse, men jeg vil mene vejen dertil ofte er et track. Jeg mener klart, at det er service. Vejene til dem er jo netop lavet for at kunne servicere vindmøllerne. Korrekt, men på den anden side eksisterer de fleste mark- og skov-veje jo også kun for at servicere de tilstødende marker og skove, så måske vi skal passe på ikke at bevæge os for langt ud i petitesser og akademiske betragtninger. Dvs. navngivne tracks som ikke er i nærheden af vindmøller burde være sjældne. Prøv fx. nedenstående overpass søgning - der er mange tracks der måske burde ændres til service: Hvis du mener med samme navn som en større vej, er jeg enig. Men selvom de fleste tracks ikke har navne, er der ikke noget galt i det. Hvis en landmand ejer en markvej og han har lyst til at give den et navn og sætter en skilt op på vejen, så hedder den vel det, han har kaldt den. Det er jo hans vej. http://overpass-turbo.eu/s/6MA /Michael Det er ikke ualmindeligt at skovveje har egne navne. Se bare f.eks. https://www.openstreetmap.org/#map=16/55.2024/8.9517. Skoven hører under naturstyrelsen (som har kontorer i bygningerne ved Skovridervej). Skovridervej er iøvrigt en grusvej, men da den er offentlig vej har jeg tagget den som unclassified (og hvis man er i tvivl om hvorvidt jeg kender til forholdene i området, kan man bare kaste et blik på gps-sporene i skoven, såvel som Mapillary). ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Stier og veje i Jægersborg Dyrehave
On Friday, January 02, 2015 13:17:42 Michael Larsen wrote: Hej, Jeg ved godt at det var en opstramning af modellen for service veje, men jeg syntes at det giver god mening at navngivne service veje har en tilhørende rigtig vej med samme navn. Wikien siger forøvrigt om service veje: For access roads to, or within an industrial estate, camp site, business park, car park etc. Derfor er dit eksempel (http://www.openstreetmap.org/way/102276421) korrekt. Det var i rollen som 'landlige tilkørselsveje' jeg forsøgte at definere service veje. Her er et andet eksempel: http://osm.org/go/0SpZxaFrE-?way=147076066 Bedre, mere korrekt eksempel: https://www.openstreetmap.org/way/147076056 (det er muligvis forkert - hovedvejen hedder muligvis Skibstedvej, men det kan stadig bruges som eksempel). Hvis vi antager at hovedvejens navn er korrekt, og der her kun er tre huse på Skibstedvej, skal den så være service eller unclassified? On Friday, January 02, 2015 12:57:47 Michael Andersen wrote: Det er ikke ualmindeligt at skovveje har egne navne. Se bare... De findes helt sikkert, men de er sjældne i forhold til unavngivne tracks. /Michael On Friday, January 02, 2015 12:13:27 Niels Elgaard Larsen wrote: On 02-01-2015 09:53, Michael Larsen wrote: Hej, Generelt en god beskrivelse af de forskellige vejkategorier. Man kunne overveje følgende tilføjelser: Anden privat fællesvej: service En navngiven servicevej kan kun eksistere i sammenhæng med en tilsvarende navngiven vej af højere 'rang' (fx. residential, living_street eller unclassified). Service veje er typisk forbindelser mellem 'rigtige veje' og adresser etc. Jeg synes godt, at man kan navngive separate serviceways, fx på militærområder, industriområder, osv. Jeg har også set alleys i udlandet, som var navngivet uden at der var en større vej med samme navn. http://www.openstreetmap.org/way/102276421 Disse veje kan ofte findes på landet, hvor man fx. kan finde tre huse med deres egen vej - i sådanne tilfælde vil jeg mene at vejen er af typen unclassified og ikke service. Hvis husene er uafhængige. Tit er det fx en større gård, hvor et par bygninger, har fået hver deres adresseknude. Så er det stadig service. Hvis to parcelhuse deler en indkørsel på 20 meter, så synes jeg heller ikke at det er en unclassified eller residential vej. Privat indkørsel til enkelt ejendom: service + service=driveway Indkørsler navngives iht. til den adresse de giver adgang til. En indkørsel markeres kun med 'access=private' hvis det er skiltet. Privat mark- eller skovvej, der ikke anvendes som adgangsvej til adresse: track (også hvis den private ejer er Skov- og Naturstyrelsen eller lignende) God pointe med adressen - veje som giver adgang til adresser har rang af service eller højere. Deraf følger også at tracks sjældent har navne. En typisk undtagelse som jeg har observeret er vindmøller - de har ofte en adresse, men jeg vil mene vejen dertil ofte er et track. Jeg mener klart, at det er service. Vejene til dem er jo netop lavet for at kunne servicere vindmøllerne. Dvs. navngivne tracks som ikke er i nærheden af vindmøller burde være sjældne. Prøv fx. nedenstående overpass søgning - der er mange tracks der måske burde ændres til service: Hvis du mener med samme navn som en større vej, er jeg enig. Men selvom de fleste tracks ikke har navne, er der ikke noget galt i det. Hvis en landmand ejer en markvej og han har lyst til at give den et navn og sætter en skilt op på vejen, så hedder den vel det, han har kaldt den. Det er jo hans vej. http://overpass-turbo.eu/s/6MA /Michael On Tuesday, December 23, 2014 17:06:13 Ole Nielsen / osm wrote: OgsÃ¥ enig. Her vestpÃ¥ er der stadig en del grusveje som er fælles for flere huse og bruges af alle slags køretøjer. De er forhÃ¥bentlig taggede med highway=unclassified og surface=gravel eller surface=unpaved. Nogle af dem er ret ringe, sÃ¥ de burde egentlig tagges med tracktype=grade4. Det mÃ¥ man godt, men om renderen kan bruge det ved jeg ikke. For mig ligger der en eller anden landbrugs- eller forstmæssig benyttelse i ordet track, dvs markvej eller skovvej, hvor der normalt ikke er adgang for familiebiler, selv om adgangen selvfølgelig ogsÃ¥ kan tagges. Jeg ville umiddelbart være ked af at bil-ruteren ledte mig ud pÃ¥ et track. Jeg har i øvrigt fundet en potentiel fejlkilde mere til disse tags: Potlatch har nogle tvetydige smÃ¥billeder, og kan i øvrigt heller ikke foreslÃ¥ tracktype. Enig. Det er vejens brug og ejerforhold og ikke overfladen, som afgør om det er track, residential, unclassified, service etc. Min opfattelse af grusvejes klassifikation: Offentlig vej med eget vejnavn: residential eller unclassified Privat
Re: [Talk-dk] Stier og veje i Jægersborg Dyrehave
On Friday, January 02, 2015 13:35:20 Michael Larsen wrote: On Friday, January 02, 2015 13:17:42 Michael Larsen wrote: Hej, Jeg ved godt at det var en opstramning af modellen for service veje, men jeg syntes at det giver god mening at navngivne service veje har en tilhørende rigtig vej med samme navn. Wikien siger forøvrigt om service veje: For access roads to, or within an industrial estate, camp site, business park, car park etc. Derfor er dit eksempel (http://www.openstreetmap.org/way/102276421) korrekt. Det var i rollen som 'landlige tilkørselsveje' jeg forsøgte at definere service veje. Her er et andet eksempel: http://osm.org/go/0SpZxaFrE-?way=147076066 Bedre, mere korrekt eksempel: https://www.openstreetmap.org/way/147076056 Hvilket også var et dårligt eksempel (hvad gør man ikke for at skabe lidt trafik på den her liste :-) ) Her er et eksempel, tre gårde på deres egen vej. Helt klart unclassified vil jeg mene. https://www.openstreetmap.org/way/121806882 Hvis der kun havde været to gårde og de havde ligget side om side - havde det så været service+driveway? (det er muligvis forkert - hovedvejen hedder muligvis Skibstedvej, men det kan stadig bruges som eksempel). Hvis vi antager at hovedvejens navn er korrekt, og der her kun er tre huse på Skibstedvej, skal den så være service eller unclassified? On Friday, January 02, 2015 12:57:47 Michael Andersen wrote: Det er ikke ualmindeligt at skovveje har egne navne. Se bare... De findes helt sikkert, men de er sjældne i forhold til unavngivne tracks. /Michael On Friday, January 02, 2015 12:13:27 Niels Elgaard Larsen wrote: On 02-01-2015 09:53, Michael Larsen wrote: Hej, Generelt en god beskrivelse af de forskellige vejkategorier. Man kunne overveje følgende tilføjelser: Anden privat fællesvej: service En navngiven servicevej kan kun eksistere i sammenhæng med en tilsvarende navngiven vej af højere 'rang' (fx. residential, living_street eller unclassified). Service veje er typisk forbindelser mellem 'rigtige veje' og adresser etc. Jeg synes godt, at man kan navngive separate serviceways, fx på militærområder, industriområder, osv. Jeg har også set alleys i udlandet, som var navngivet uden at der var en større vej med samme navn. http://www.openstreetmap.org/way/102276421 Disse veje kan ofte findes på landet, hvor man fx. kan finde tre huse med deres egen vej - i sådanne tilfælde vil jeg mene at vejen er af typen unclassified og ikke service. Hvis husene er uafhængige. Tit er det fx en større gård, hvor et par bygninger, har fået hver deres adresseknude. Så er det stadig service. Hvis to parcelhuse deler en indkørsel på 20 meter, så synes jeg heller ikke at det er en unclassified eller residential vej. Privat indkørsel til enkelt ejendom: service + service=driveway Indkørsler navngives iht. til den adresse de giver adgang til. En indkørsel markeres kun med 'access=private' hvis det er skiltet. Privat mark- eller skovvej, der ikke anvendes som adgangsvej til adresse: track (også hvis den private ejer er Skov- og Naturstyrelsen eller lignende) God pointe med adressen - veje som giver adgang til adresser har rang af service eller højere. Deraf følger også at tracks sjældent har navne. En typisk undtagelse som jeg har observeret er vindmøller - de har ofte en adresse, men jeg vil mene vejen dertil ofte er et track. Jeg mener klart, at det er service. Vejene til dem er jo netop lavet for at kunne servicere vindmøllerne. Dvs. navngivne tracks som ikke er i nærheden af vindmøller burde være sjældne. Prøv fx. nedenstående overpass søgning - der er mange tracks der måske burde ændres til service: Hvis du mener med samme navn som en større vej, er jeg enig. Men selvom de fleste tracks ikke har navne, er der ikke noget galt i det. Hvis en landmand ejer en markvej og han har lyst til at give den et navn og sætter en skilt op på vejen, så hedder den vel det, han har kaldt den. Det er jo hans vej. http://overpass-turbo.eu/s/6MA /Michael On Tuesday, December 23, 2014 17:06:13 Ole Nielsen / osm wrote: OgsÃ¥ enig. Her vestpÃ¥ er der stadig en del grusveje som er fælles for flere huse og bruges af alle slags køretøjer. De er forhÃ¥bentlig taggede med highway=unclassified og surface=gravel eller surface=unpaved. Nogle af dem er ret ringe, sÃ¥ de burde egentlig tagges med tracktype=grade4. Det mÃ¥ man godt, men om renderen kan bruge det ved jeg ikke. For mig ligger der en eller anden landbrugs- eller forstmæssig benyttelse i ordet track, dvs markvej eller skovvej, hvor der normalt ikke er adgang for familiebiler, selv om adgangen selvfølgelig
Re: [Talk-dk] Stier og veje i Jægersborg Dyrehave
Michael Larsen skrev: Her er et eksempel, tre gårde på deres egen vej. Helt klart unclassified vil jeg mene. https://www.openstreetmap.org/way/121806882 Hvis der kun havde været to gårde og de havde ligget side om side - havde det så været service+driveway? Du kan jo kigge på vejen lige ved siden af: https://www.openstreetmap.org/way/141247255 Den er lidt længere, men har kun to huse. Den er tagget som service/driveway. Lad os et kort øjeblik lade som om, at Rosenvangsvej ikke havde sit eget navn: Det giver ingen mening at lade vejtypen afgøres af antallet af huse på vejen. Det må være vejens brug, der er afgørende, uanset hvor mange huse, der er. Vi tagger ikke en hovedvej som residential, bare fordi der ligger mange huse ved den. Og vi tagger ikke en villavej som service eller unclassified, bare fordi den kun har ét hus. De to ovennævne sideveje burde altså tagges ens. Begge vejes funktion er tilsyneladende at fungere som adgangsvej fra den store vej til de huse, der ligger der. Så efter min mening burde de begge være highway=service,service=driveway,surface=unpaved. MEN: Der så åbenbart nogen, der har givet Rosenvangsvej sit eget navn. Dermed er vejen blevet ophøjet til noget mere end bare en indkørsel. Primært kan man bruge den til rutebeskrivelser (du skal dreje til højre første gang efter Rosenvangsvej). Man kan så diskutere, om det bør medføre, at den får en anden markering, f.x. highway=unclassified. Det er et vurderingsspørgsmål. I dette tilfælde vil jeg nok mest hælde til at tagge den som highway=unclassified,surface=unpaved. - Jørgen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Stier og veje i Jægersborg Dyrehave
Jeg er enig i denne klassificering, og grunden til at vælge unclassified i stedet for service er udelukkende at den har sit eget navn, hvilket var mit oprindelige budskab. Hvis der er nogen der kender eksempler hvor en selvstændigt navngiven vej bedst markeres som service vil jeg gerne høre om det. /Michael On Friday, January 02, 2015 15:40:12 Jørgen Elgaard Larsen wrote: Man kan så diskutere, om det bør medføre, at den får en anden markering, f.x. highway=unclassified. Det er et vurderingsspørgsmål. I dette tilfælde vil jeg nok mest hælde til at tagge den som highway=unclassified,surface=unpaved. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Stier og veje i Jægersborg Dyrehave
On 02-01-2015 12:57, Michael Andersen wrote: Fredag den 2. januar 2015 12:13:27 skrev Niels Elgaard Larsen: God pointe med adressen - veje som giver adgang til adresser har rang af service eller højere. Deraf følger også at tracks sjældent har navne. En typisk undtagelse som jeg har observeret er vindmøller - de har ofte en adresse, men jeg vil mene vejen dertil ofte er et track. Jeg mener klart, at det er service. Vejene til dem er jo netop lavet for at kunne servicere vindmøllerne. Korrekt, men på den anden side eksisterer de fleste mark- og skov-veje jo også kun for at servicere de tilstødende marker og skove, så måske vi skal passe på ikke at bevæge os for langt ud i petitesser og akademiske betragtninger. Jeg synes ikke, at det er en akademisk betragtning. tracks er veje, der er beregnet til skov- og landbrugsmaskiner, som traktorer, bulldozers, offroaders, osv. De veje, der er lavet til vindmøller, er typisk fine grusveje, der er lavet så ingeniører, elektrikere, statslige kontrollanter, rengøringsfolk, osv kan inspicere og servicere møllerne også i almindelige person- og varebiler. Hvis nu fx mit lille IT-firma blev hyret til at installere noget software i en vindmølle og jeg skulle køre ud til den i min lille Peugeot 107, så ville min GPS nægte at rute mig ad tracks. Det ville jeg opfatte som et meget praktisk problem. Dvs. navngivne tracks som ikke er i nærheden af vindmøller burde være sjældne. Prøv fx. nedenstående overpass søgning - der er mange tracks der måske burde ændres til service: Hvis du mener med samme navn som en større vej, er jeg enig. Men selvom de fleste tracks ikke har navne, er der ikke noget galt i det. Hvis en landmand ejer en markvej og han har lyst til at give den et navn og sætter en skilt op på vejen, så hedder den vel det, han har kaldt den. Det er jo hans vej. http://overpass-turbo.eu/s/6MA /Michael Det er ikke ualmindeligt at skovveje har egne navne. Se bare f.eks. https://www.openstreetmap.org/#map=16/55.2024/8.9517. Skoven hører under naturstyrelsen (som har kontorer i bygningerne ved Skovridervej). Skovridervej er iøvrigt en grusvej, men da den er offentlig vej har jeg tagget den som unclassified (og hvis man er i tvivl om hvorvidt jeg kender til forholdene i området, kan man bare kaste et blik på gps-sporene i skoven, såvel som Mapillary). ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk -- Niels Elgaard Larsen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Stier og veje i Jægersborg Dyrehave
2. januar 2015 kl. 16.20 skrev Niels Elgaard Larsen elga...@agol.dk: On 02-01-2015 12:57, Michael Andersen wrote: Fredag den 2. januar 2015 12:13:27 skrev Niels Elgaard Larsen: God pointe med adressen - veje som giver adgang til adresser har rang af service eller højere. Deraf følger også at tracks sjældent har navne. En typisk undtagelse som jeg har observeret er vindmøller - de har ofte en adresse, men jeg vil mene vejen dertil ofte er et track. Jeg mener klart, at det er service. Vejene til dem er jo netop lavet for at kunne servicere vindmøllerne. Korrekt, men på den anden side eksisterer de fleste mark- og skov-veje jo også kun for at servicere de tilstødende marker og skove, så måske vi skal passe på ikke at bevæge os for langt ud i petitesser og akademiske betragtninger. Jeg synes ikke, at det er en akademisk betragtning. tracks er veje, der er beregnet til skov- og landbrugsmaskiner, som traktorer, bulldozers, offroaders, osv. De veje, der er lavet til vindmøller, er typisk fine grusveje, der er lavet så ingeniører, elektrikere, statslige kontrollanter, rengøringsfolk, osv kan inspicere og servicere møllerne også i almindelige person- og varebiler. Hvis nu fx mit lille IT-firma blev hyret til at installere noget software i en vindmølle og jeg skulle køre ud til den i min lille Peugeot 107, så ville min GPS nægte at rute mig ad tracks. Det ville jeg opfatte som et meget praktisk problem. Hvis jeg kigger på de eksempler der er på wikien, så ser jeg nogle meget gode gursveje, hvilket jeg vil mene du sagtens kan køre på med din mindre bil uden problemer. Jeg er opmærksom på at den nævner It usually applies to highway=track but is often used for non-tracks too [...]. http://wiki.openstreetmap.org/wiki/Key:tracktype Dvs. navngivne tracks som ikke er i nærheden af vindmøller burde være sjældne. Prøv fx. nedenstående overpass søgning - der er mange tracks der måske burde ændres til service: Hvis du mener med samme navn som en større vej, er jeg enig. Men selvom de fleste tracks ikke har navne, er der ikke noget galt i det. Hvis en landmand ejer en markvej og han har lyst til at give den et navn og sætter en skilt op på vejen, så hedder den vel det, han har kaldt den. Det er jo hans vej. http://overpass-turbo.eu/s/6MA /Michael Det er ikke ualmindeligt at skovveje har egne navne. Se bare f.eks. https://www.openstreetmap.org/#map=16/55.2024/8.9517. Skoven hører under naturstyrelsen (som har kontorer i bygningerne ved Skovridervej). Skovridervej er iøvrigt en grusvej, men da den er offentlig vej har jeg tagget den som unclassified (og hvis man er i tvivl om hvorvidt jeg kender til forholdene i området, kan man bare kaste et blik på gps-sporene i skoven, såvel som Mapillary). ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk -- Niels Elgaard Larsen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-gb-westmidlands] Monthly meeting?
Weather looks dreadful tomorrow so I might only come for the pub lunch On 1 Jan 2015 16:50, Rob Nickerson rob.j.nicker...@gmail.com wrote: I assumed we weren't meeting as its a public holiday. Are you sorted for Saturday or do you need a lift? Rob On 1 Jan 2015 11:12, Matthijs Melissen i...@matthijsmelissen.nl wrote: Dear all, Happy new year to all of you! I'm not sure if we decided anything about the monthly meeting in the Bull tonight? I suppose because of the New Year and our meeting this Saturday we won't meet tonight, but just wanted to verify. -- Matthijs ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
[Talk-es] weeklyosm #232 disponible en castellano
Hola El semanario #232 de weeklyosm, el sumario de todo lo que está ocurriendo en mundo OSM está en linea en español http:/www.weeklyosm.eu/?lang=es Disfrutadlo!!___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] Gratkorn
On 02.01.2015 19:25, Michael Maier wrote: nördlich von Graz gibt es ja die beiden Orte Gratwein und Gratkorn. Für Gratwein (westlich der Mur) gibt es einen Place-Node, für Gratkorn (östlich der Mur) keinen. Ging der irgendwann verloren? Ja, Node 85922192 war einmal mit place=village + name=Gratkorn getaggt. Den Node sollten wir wiederherstellen statt einen neuen anzulegen. Sollen wir einen Place-Node für Gratkorn hinzufügen (imho auf jeden Fall)? Wo? Ich kenn mich in der Gegend leider nicht aus, gibt's da einen Mittelpunkt, Hauptplatz oder so? Ich kenne mich dort überhaupt nicht aus, aber wenn ich http://pfarre-gratkorn.at/unsere-pfarre/geschichte/ richtig interpretiere, ist Way 127556536 (noch unzureichend getaggt!) die Hauptkirche, und demnach können wir dort den historischen Ortskern annehmen. Aber weil das ziemlich am Rand der heutigen Siedlung liegt, würde ich den Node etwas weiter SW platzieren. PS: Damit komme ich aufs gleiche Ergebnis wie Grubernd. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Steirische Straßen effizient erfassen
Dankeschön jetzt gehts! Lg Johannes From: Thomas Konrad tkon...@gmx.net To: OpenStreetMap AT talk-at@openstreetmap.org Subject: Re: [Talk-at] Steirische Straßen effizient erfassen Message-ID: 4c605126-ae3a-43bb-8798-1b09681e9...@gmx.net Content-Type: text/plain; charset=utf-8 Hallo Johannes, oh, darauf hab ich vergessen - du brauchst zum Importieren von Shapefiles in JOSM das opendata-Plugin [1]! Schöne Grüße Thomas [1] http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData On 01 Jan 2015, at 19:41, Johannes Silly johannes.si...@gmail.com wrote: Erstmal Sehr gutes Video leicht erklärt auch für Anfänger, aber mein JOSM macht die ZIP Datei nicht auf, hab die Webstarter Version für Win8. Josm Ver. 7906 Kann wer helfen? Irgend ein Plugin vielleicht? ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gratkorn
On 2015-01-02 19:25, Michael Maier wrote: Sollen wir einen Place-Node für Gratkorn hinzufügen (imho auf jeden Fall)? Wo? Ich kenn mich in der Gegend leider nicht aus, gibt's da einen Mittelpunkt, Hauptplatz oder so? disclaimer: kein Gratkorner. ich würde den node in diese gegend setzen: http://www.openstreetmap.org/#map=18/47.13298/15.34052 das ist ziemlich in der mitte und die wichtigsten sachen nebenan: post, hotel, bäckerei, ein platz mit springbrunnen, usw usw. vielleicht die leere wiese nordöstlich von dem halbrunden gebäude nehmen, dann haben renderer noch eine zeitlang eine chance den node auch zu rendern - gemäss der maxime wir mappen nicht für den renderer aber wir machen es ihm auch nicht absichtlich schwer. meine 2ct. grubernd ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Gratkorn
Hallo, nördlich von Graz gibt es ja die beiden Orte Gratwein und Gratkorn. Für Gratwein (westlich der Mur) gibt es einen Place-Node, für Gratkorn (östlich der Mur) keinen. Ging der irgendwann verloren? Dementsprechend wird bei einer Nominatim-Suche in der OSM nur die Gemeinde-Relation gefunden, und der Ort nur über Geonames. Sollen wir einen Place-Node für Gratkorn hinzufügen (imho auf jeden Fall)? Wo? Ich kenn mich in der Gegend leider nicht aus, gibt's da einen Mittelpunkt, Hauptplatz oder so? lg, Michael -- Michael Maier, Student of Telematics @ Graz University of Technology OpenStreetMap Graz http://osm.org/go/0Iz@paV http://wiki.osm.org/Graz http://wiki.osm.org/Graz/Stammtisch signature.asc Description: OpenPGP digital signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Steirische Straßen effizient erfassen
Hallo Johannes, oh, darauf hab ich vergessen - du brauchst zum Importieren von Shapefiles in JOSM das “opendata”-Plugin [1]! Schöne Grüße Thomas [1] http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData On 01 Jan 2015, at 19:41, Johannes Silly johannes.si...@gmail.com wrote: Erstmal Sehr gutes Video leicht erklärt auch für Anfänger, aber mein JOSM macht die ZIP Datei nicht auf, hab die Webstarter Version für Win8. Josm Ver. 7906 Kann wer helfen? Irgend ein Plugin vielleicht? ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gratkorn
On 02.01.2015 20:14, grubernd wrote: ich würde den node in diese gegend setzen: http://www.openstreetmap.org/#map=18/47.13298/15.34052 das ist ziemlich in der mitte und die wichtigsten sachen nebenan: post, hotel, bäckerei, ein platz mit springbrunnen, usw usw. vielleicht die leere wiese nordöstlich von dem halbrunden gebäude nehmen, dann haben renderer noch eine zeitlang eine chance den node auch zu rendern - gemäss der maxime wir mappen nicht für den renderer aber wir machen es ihm auch nicht absichtlich schwer. Vielleicht machst du es ihm gerade damit schwer, denn dann hat er keine Chance, den Ort richtig anzuzeigen. Wo er die Beschriftung platziert, hängt von der Zoomstufe ab, von der Schriftgröße, von der Auswahl der dargestellten Objekte (z.B. gibt es auch Karten, wo keine Häuser, Straßen usw. eingezeichnet sind) und auch von der Priorität (der Renderer kann den Hintergrund ohne weiteres mit dem Ortsnamen überschreiben). D.h. der Renderer MUSS das selber berechnen. Und selbst wenn du ihm eine Stelle vorgibst, wärs immer noch möglich, dass er dort nicht die Beschriftung platziert, sondern ein Kugerl zeichnet und die Beschriftung dann erst woanders hintun muss. Außerdem werden die Place-Nodes auch für Routing, Abstandsberechnungen, Koordinatenlisten usw. benötigt. Ich setze die Nodes deshalb immer dorthin, wo Scotty mich hinbeamen soll, wenn ich ihm nur den Ortsnamen sage. Der Vergleich ginge auch mit einem Taxifahrer, wenn der überall fahren dürfte. Jedenfalls hätte ich keine Freude, wenn ich dem Taxifahrer oder dem Router Gratkorn als Ziel gebe und mich dann auf einer leeren Wiese wiederfinde. ;-) -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gratkorn
On 02.01.15 19:25, Michael Maier wrote: nördlich von Graz gibt es ja die beiden Orte Gratwein und Gratkorn. Für Gratwein (westlich der Mur) gibt es einen Place-Node, für Gratkorn (östlich der Mur) keinen. Ging der irgendwann verloren? Deleted 7 months ago by eriosw. http://www.openstreetmap.org/node/85922192 undeleted. Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-it-trentino] M'appare il Lagorai Cima D'Asta
Nell'attesa di potervi fornire ulteriori info in merito all'inziativa ...Auguroi a tutti un buon 2015 Giorgio ___ Talk-it-trentino mailing list Talk-it-trentino@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it-trentino
Re: [Talk-pt] Talk-pt Digest, Vol 61, Issue 11
Viva, criei um documento na wiki do osm sob a comunidade de Braga (uma vez que tem referência directa na página base da wiki portuguesa) com informação sobre o que está feito e o que falta fazer nas rotas TUB de Braga. Como ainda não havia qualquer conteúdo na comunidade de Braga, coloquei o documento na raíz - claro que assim que surgirem mais temas na comunidade, arruma-se o documento numa página com referência à pagina base. À medida que for desenvolvendo o trabalho de criação das rotas, vou actualizando a tabela que lá está. Pedia a quem quisesse colaborar que se cordenasse comigo. Abraço a todos! Miguel (mirtilo) No dia 19 de dezembro de 2014 às 18:04, Nuno Gomes Lopes n.gomeslo...@gmail.com escreveu: Boa tarde a todos. Fui eu, na sequência do projeto do TransportesPublicos.pt, que introduzi essas rotas em Braga. Introduzi as rotas pelo número ( http://www.transportespublicos.pt/operadores-tarifarios/). Fico contente por perceber que este trabalho está a ter continuidade - talvez proximamente Braga possa juntar-se a Almada como um concelho com todas as rotas de autocarros no OSM (ficam a faltar, como é óbvio, as rotas de operadores privados). Gonçalo, o TP.pt já é um serviço a nível nacional baseado no OSM, se bem que a informação das rotas não vem do OSM (utilizamos o Open Trip Planner, que existe um pouco por todo o mundo). Os TUB entraram no nosso serviço ao mesmo tempo que entraram no google transit, o que considerámos uma bom *modus operandi*. O mesmo não podemos dizer da CP, que também entrou no google transit sem ter disponibilizado as suas rotas a outros serviços. Miguel, uma sugestão: podias criar uma wiki para transportes rodoviários, e introduzir lá as rotas (a introduzir aqui, semelhante à das 'ferrovias'). Continuação de bom trabalho! Abraço a todos. No dia 19 de dezembro de 2014 às 16:30, talk-pt-requ...@openstreetmap.org escreveu: Send Talk-pt mailing list submissions to talk-pt@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.openstreetmap.org/listinfo/talk-pt or, via email, send a message with subject or body 'help' to talk-pt-requ...@openstreetmap.org You can reach the person managing the list at talk-pt-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-pt digest... Today's Topics: 1. Rotas dos Transportes Urbanos de Braga (Miguel Borges) 2. Re: Rotas dos Transportes Urbanos de Braga (Gonçalo Lourenço) 3. Re: Rotas dos Transportes Urbanos de Braga (Miguel Borges) -- Message: 1 Date: Fri, 19 Dec 2014 12:44:05 + From: Miguel Borges borges.mig...@gmail.com To: Lista Talk-pt@openstreetmap.org Subject: [Talk-pt] Rotas dos Transportes Urbanos de Braga Message-ID: CA+O3NLn0hAh=nxwgF3z58vkmLuaPm0xmD= g6nme7cxwkdhv...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Talk-pt@openstreetmap.orgOlá a todos, Escrevo-vos para dar conta à comunidade do trabalho que estou a desenvolver e para ver se não colide com o trabalho que algum outro membro esteja a fazer. Ainda um apelo: se alguém quiser dar uma ajuda, é bem-vindo(a)! Meti-me na empreitada de completar as rotas dos transportes urbanos de Braga (TUB) com base na informação publicada no site da empresa transportadora (www.tub.pt) e no meu conhecimento local. A situação actual é a de 15 rotas já criadas, julgo que pelo transportespublicospt, e que de entre as quais 3 estão com problemas de continuidade e todas sem referência ao sentido da rota. Das 55 rotas restantes, já criei 6, pelo que ainda restam 49. Partilho convosco o método que estou a usar para a criação de rotas: 0. Criar relações de rotas, com prioridade às rotas que se estendam por zonas do teritório ainda sem cobertura 1. Começo por acrescentar à relação, os segmentos no sentido da ida 2. Se o segmento é apenas percorrido na ida, marco-o com o role de forward 3. Se o segmento é comum à ida e volta, não lhe marco role 4. Depois de acrescentar todos os segmentos ida e comuns, marco os segmentos que apenas são feitos no regresso (incluindo partes de rotundas e acessos) e associo-lhe o role de backward *. Fica para uma outra fase a adição de bus_stops, pois o levantamento e identificação não são de momento exaustivos Uma questão sobre este tipo de trabalhos: onde acham que devo disponibilizar info sobre evolução a das tarefas? E se alguém perceber que estou a fazer asneira, que me avise ;) Abraço, Miguel Borges (mirtilo) -- Dados particulares Relações das rotas que estavam já criadas: 3169698, 3170247, 3170450, 3171730, 3173404, 3231617, 3299812, 3311977, 3313484, 444, 3356514, 3313604 Relações das rotas com problemas de continuidade: 3231742, 3331955, 3332367 Relações das rotas criadas por mim entretanto: 4280370, 4282032,4285307,
Re: [Talk-ca] Offset à Laval
Bonjour, Voici un complément d'informations: Voici toutes les données qui ont le même alignement: - les données des contributeurs locaux datant de +12 mois (parc, bâtiments, pistes cyclables...) qui étaient probablement alignées sur l'ancienne imagerie Bing de 2009/2010 approx. - les interpolations CANVEC - l'imagerie Mapbox Exemple: https://www.openstreetmap.org/#map=18/45.585185/-73.671649 Ce qui laisse à penser que, depuis longtemps, l'import CANVEC et l'ancienne imagerie Bing étaient corrects (hypothèse confirmée par le positionnement identique de la récente imagerie Mapbox), donc l'imageire Bing actuelle serait la seule a être décallée. Ceci oriente pas mal la réponse à ma question.. mais quel est votre avis? Le 1 janvier 2015 22:24, Daniel Begin jfd...@hotmail.com a écrit : Salut Bruno, J’ai travaillé à Laval il y a un bon moment. L’imagerie de l’époque était médiocre alors j’utilisais les tracés GPS disponibles pour caler les images. Il y a peut-être un peu de ça dans ce que tu constates? Daniel *From:* Bruno Remy [mailto:bremy.qc...@gmail.com] *Sent:* January-01-15 20:22 *To:* talk-ca@openstreetmap.org *Subject:* [Talk-ca] Offset à Laval Bonjour à tous, Parmi les contributeurs qui éditent dans le coin de l'Ile de Laval (QC), il semble y avoir un offset de l'imagerie Bing. Travaillez-vous avec un décallage de l'imagerie satellite dans JOSM, pour l'aligner avec les données ? Ou bien ce sont les données existantes qui ont une mauvaise géométrie et qui doivent être corrigées selon l'imagerie? Merci d'avance! -- Bruno Remy -- Bruno Remy ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Offset à Laval
Finalement, après une bonne observation des données, j'ai appliqué un offset de +14.32; -1.91 sur le calque d'imagerie Bing. Toutes les données (import Canvec, import Géobase, tracés des terrains de sports et buildings par les contributeurs) sont alignées de maniérè homogène sur cet offset. Si jamais des tracés GPS, avec des appareils récents et très précis, et en grand nombre, nous prouvent le contraire, alors nous devront définir un nouvel offset plus réaliste et décaller en conséquence les données importées ainsi que les données rajoutées/ajustées par les contributeurs. Je suis d'Accord là-dessus avec toi, Daniel. Donc je rappelle qu'à court terme, pour l'Île de Laval toutes les données ont un* offset de +14.32; -1.91* par rapport à l'imagerie Bing actuelle Par soucis de cohérence, il serait bon que tous les contributeurs en tiennent compte. Le 2 janvier 2015 18:21, Daniel Begin jfd...@hotmail.com a écrit : Bruno, Il y a beaucoup de tracés GPS dans la région de Laval … Je comparerais les images en questions avec les tracés disponibles, particulièrement près des autoroutes (là où il y aura une grande quantité de tracés). Comme la topographie est plane dans la région, le calage devrait être valide pour de grandes distances par rapport à la localisation des tracés… Je cale toujours les images avec des tracés GPS, particulièrement s’il y en a plus d’un (compte-tenu des erreurs associées aux données GPS). Daniel *From:* Bruno Remy [mailto:bremy.qc...@gmail.com] *Sent:* January-02-15 11:45 *To:* Daniel Begin *Cc:* talk-ca@openstreetmap.org *Subject:* Re: [Talk-ca] Offset à Laval Bonjour, Voici un complément d'informations: Voici toutes les données qui ont le même alignement: - les données des contributeurs locaux datant de +12 mois (parc, bâtiments, pistes cyclables...) qui étaient probablement alignées sur l'ancienne imagerie Bing de 2009/2010 approx. - les interpolations CANVEC - l'imagerie Mapbox Exemple: https://www.openstreetmap.org/#map=18/45.585185/-73.671649 Ce qui laisse à penser que, depuis longtemps, l'import CANVEC et l'ancienne imagerie Bing étaient corrects (hypothèse confirmée par le positionnement identique de la récente imagerie Mapbox), donc l'imageire Bing actuelle serait la seule a être décallée. Ceci oriente pas mal la réponse à ma question.. mais quel est votre avis? Le 1 janvier 2015 22:24, Daniel Begin jfd...@hotmail.com a écrit : Salut Bruno, J’ai travaillé à Laval il y a un bon moment. L’imagerie de l’époque était médiocre alors j’utilisais les tracés GPS disponibles pour caler les images. Il y a peut-être un peu de ça dans ce que tu constates? Daniel *From:* Bruno Remy [mailto:bremy.qc...@gmail.com] *Sent:* January-01-15 20:22 *To:* talk-ca@openstreetmap.org *Subject:* [Talk-ca] Offset à Laval Bonjour à tous, Parmi les contributeurs qui éditent dans le coin de l'Ile de Laval (QC), il semble y avoir un offset de l'imagerie Bing. Travaillez-vous avec un décallage de l'imagerie satellite dans JOSM, pour l'aligner avec les données ? Ou bien ce sont les données existantes qui ont une mauvaise géométrie et qui doivent être corrigées selon l'imagerie? Merci d'avance! -- Bruno Remy -- Bruno Remy -- Bruno Remy ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-cz] Posunutá mapa?
Tak oblast Křižánek je v mezích možností na svém místě. Opravil jsem budovy, silnice, cesty, vodní plochy a adresní místa. Svratka naštěstí posunutá nebyla. Funkce Filtr se tímto stává mým nejoblíbenějším nástrojem v JOSM ;-) Martin On 30.11.2014 07:48, Tomáš Tichý wrote: Dokonce jsem na to zakládal OSM note: http://www.openstreetmap.org/note/268165#map=14/49.6863/16.0872layers=N Po importu z RÚIAN už jdou podobné případy celkem snadno odhalit. TT On Sun Nov 30 2014 at 4:23:19 jzvc j...@tpfree.net mailto:j...@tpfree.net wrote: Dne 30.11.2014 v 1:33 Petr Vejsada napsal(a): Ahoj, na Bing to sedí naprosto přesně, takže věc je asi jasná :-( Na tohle narazim taky pomerne casto, Bing by bylo treba terminovat jako zdroj. Je klidne misty i 50 metru mimo. Zajimavy, ze tvurcum (neb to neni jeden clovek) nijak zvlast nevadi silnice skrz domy a podobne. Dne Ne 30. listopadu 2014 01:20:30, Martin Švec - OSM napsal(a): Ahoj, narazil jsem na podezřelou oblast: https://www.openstreetmap.org/#map=16/49.6887/16.0645 Zdá se mi to, nebo jsou adresní místa, budovy, cesty, silnice, Svratka atd. posunuté vůči katastrální mapě (a LPIS polygonům) o 5-10 metrů na západ? Jako by si někdo rovnal katastrální mapu vůči Bingu místo obráceně... Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org mailto:Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] funguje tracer LPIS
díky za info Pražák -- Původní zpráva -- Od: Martin Švec - OSM o...@maatts.cz Komu: talk-cz@openstreetmap.org Datum: 2. 1. 2015 17:38:47 Předmět: Re: [Talk-cz] funguje tracer LPIS Nefunguje, jelikož mají odstávku: http://eagri.cz/public/web/mze/farmar/LPIS/novinky/odstavka-lpis-1.html V termínu 2. 1. 2015 (0:00) až 10. 1. 2015 (20:00 - odstávka může být ukončena i dříve) bude probíhat plánovaná odstávka registru LPIS. V tomto období budou probíhat úpravy registru LPIS v souvislosti s novelou zákona o zemědělství, která bude účinná od 1. 1. 2015. V tomto termínu nebude dostupné webové rozhraní veřejného LPIS a LPISu pro farmáře. Nedostupné budou také WMS/WFS služby a veřejné webové služby LPIS. Částečné omezení bude také v aplikacích napojených na LPIS a to: Data ke stažení, EPH, IZR a dále Registru vinic (RV). Přehledný soupis změn v LPISu od 1. 1. 2015 je uveden ve zvláštním článku. V případě problémů s LPIS kontaktujte helpdesk MZe - helpd...@mze.cz, 221 811 888. Martin On 2.1.2015 16:38, Zdeněk Pražák wrote: Chtěl jsem se zeptat, zda vám funguje LPIS tracer Pražák ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz;___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Osmose Česká republika
Ahoj, stale si hraju s osmose, dosel jsem k tomu, ze staci opravovat vlastni chyby na http://osmose.openstreetmap.fr/cs/byuser/UZIVATEL Vzhledem k tomu, ze se to chova znacne viralne (upravite objekty na kterych se pak hledaji dalsi chyby), tak clovek postupne opravuje dalsi a dalsi, ale pritom je toho rozumne mnozstvi. Kazdopadne proc pisu - dostal jsem se na nejakou chyby v Hradci kralove a prijde mi ze je to tam zrejme nejakym(i) importem/ty docela zaplevelene - prekryvajici se budovy, deprecated tagy (building:type apod). Nechce na to nekdo mistni kouknout trochu lip, neco jsem zkusil pospravovat, ale je toho prilis mnoho. A jinak vse nejlepsi v novem roce ;-) -- Tomas Kasparek e-mail: kaspa...@fit.vutbr.cz CVT FIT VUT Brno, L127 jabber: tomas.kaspa...@jabber.cz Bozetechova 1, 612 66web : http://www.fit.vutbr.cz/~kasparek Brno, Czech Republic phone : +420 54114-1220 GPG:2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! pgptpIvS_m6VF.pgp Description: PGP signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] RÚIAN tracer
Dne 3.1.2015 v 00:23 Michal Pustějovský napsal(a): Zdravím, měl bych malou prosbu na RÚIAN tracer. Šlo by naprogramovat, aby při nahrazování existujících domů u klíče building=* přepisoval stávající hodnotu tou z RÚIAN POUZE pro building=yes? Spousta domů už totiž má upřesňující značky typu building=supermarket, building=train_station apod. Při použití traceru hodnoty změní na obecnější civic příp. transportation. Podobná situace je i u building:levels, kdy ruian není vždy přesný. Takže bych radši nechávál stávající hodnoty. Stačil by například i zaškrtávací box v nastaveních. Dost by to zrychlilo a zpřesnilo práci. Ahoj, takhle to původně bylo, ale při úpravách se to ztratilo. Implementoval jsem oba požadavky. Asi nejlepší by bylo, kdyby se zobrazilo okno s rozdíly. Tak jak to je třeba dělá příkaz replace geometry. Ale podle mne by to spíše zdržovalo a časem by to mohlo začít vadit. Takže pokud bych to dělal, tak bych to asi udělal konfigurovatelné. Marián Díky, Michal ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] funguje tracer LPIS
Nefunguje, jelikož mají odstávku: http://eagri.cz/public/web/mze/farmar/LPIS/novinky/odstavka-lpis-1.html V termínu 2. 1. 2015 (0:00) až 10. 1. 2015 (20:00 - odstávka může být ukončena i dříve) bude probíhat plánovaná odstávka registru LPIS. V tomto období budou probíhat úpravy registru LPIS v souvislosti s novelou zákona o zemědělství, která bude účinná od 1. 1. 2015. V tomto termínu nebude dostupné webové rozhraní veřejného LPIS a LPISu pro farmáře. Nedostupné budou také WMS/WFS služby a veřejné webové služby LPIS. Částečné omezení bude také v aplikacích napojených na LPIS a to: Data ke stažení, EPH, IZR a dále Registru vinic (RV). Přehledný soupis změn v LPISu od 1. 1. 2015 je uveden ve zvláštním článku. V případě problémů s LPIS kontaktujte helpdesk MZe - helpd...@mze.cz, 221 811 888. Martin On 2.1.2015 16:38, Zdeněk Pražák wrote: Chtěl jsem se zeptat, zda vám funguje LPIS tracer Pražák ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] RÚIAN tracer
Zdravím, měl bych malou prosbu na RÚIAN tracer. Šlo by naprogramovat, aby při nahrazování existujících domů u klíče building=* přepisoval stávající hodnotu tou z RÚIAN POUZE pro building=yes? Spousta domů už totiž má upřesňující značky typu building=supermarket, building=train_station apod. Při použití traceru hodnoty změní na obecnější civic příp. transportation. Podobná situace je i u building:levels, kdy ruian není vždy přesný. Takže bych radši nechávál stávající hodnoty. Stačil by například i zaškrtávací box v nastaveních. Dost by to zrychlilo a zpřesnilo práci. Díky, Michal ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[OSM-talk-fr] [BANO] noms non trouvés sur cadastre
Bonjour, Quand un nom de voie est rapporté sur BANO, mais dont le nom n'est pas indiqué sur la couche cadastre, comment faites-vous ? Pour l'instant, je vais vérifier sur le terrain, ou mets une note pour le faire. Mais bon, dans certains cas sans équivoque, BANO (donc croisement fantoir, cadastre, toussa) doit certainement être dans le vrai. Pensez-vous que c'est OK, on met le nom indiqué ? Exemple ici : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/45.72420/3.04662[1] Prenez la couche fr où on voit la voie que j'ai tracé. Ça me semble sans équivoque. De toutes façons, si on veut avancer, j'imagine qu'il faut procéder ainsi. OK ? Pour info, dans certains cas, impossible de trancher sans aller sur le terrain. Par exemple ici : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/45.70444/3.02199[2] 2 noms pour une même impasse, il doit y avoir une erreur. Dans ce cas, je mets une note. -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin [1] http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/45.72420/3.04662 [2] http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#19/45.70444/3.02199 ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] noms non trouvés sur cadastre
Le 2 janvier 2015 12:09, David Crochet david.croc...@free.fr a écrit : Bonjour Le 02/01/2015 11:55, Nicolas Dumoulin a écrit : Quand un nom de voie est rapporté sur BANO, mais dont le nom n'est pas indiqué sur la couche cadastre, comment faites-vous ? Je rapporte les erreurs ici : http://cadastre.openstreetmap.fr/fantoir/ Euh... Dans la liste des erreurs Fantoir (http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_%28BANO%29#Typologie_des_anomalies_FANTOIR ), je ne vois *pas* le cas cité par Nicolas ( nom de voie est rapporté sur BANO (sans doute issu des adresses des parcelles), mais dont le nom n'est pas indiqué sur la couche cadastre) Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] noms non trouvés sur cadastre
Bonjour Le 02/01/2015 11:55, Nicolas Dumoulin a écrit : Quand un nom de voie est rapporté sur BANO, mais dont le nom n'est pas indiqué sur la couche cadastre, comment faites-vous ? Je rapporte les erreurs ici : http://cadastre.openstreetmap.fr/fantoir/ Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles - fusion de communes
Et une petite carte overpass-turbo pour l'occasion: http://overpass-turbo.eu/s/6MO -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonne année
Bonne année à tous les contributeurs OSM FredM ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] weeklyOSM en français?
On peut traduire workflow par plan de travail (quoique l'expression peut aussi désigner une table ou une surface plane en cuisine ou dans un atelier, le mot plan a plusieurs sens en français), ou organisation du travail. Les ingénieurs francophones et entreprises ont tendance à garder le mot anglais, mais souvent employé aussi à mauvais escient quand cela désigne plutôt une méthode de travail, ou la répartition des tâches entre les acteurs disponibles, ou le modèle organisationnel pour la direction et le suivi d'un projet; ou un diagramme des activités, ou un processus. L'anglicisme est parfois à conserver; chaque projet choisissant sa terminologie justement à la façon dont il s'organise et les outils utilisés et selon les tâches assignées entre les responsables de certains lots, surtout dans les domaines techniques et informatiques comme ici en cartographie informatique. Le 2 janvier 2015 17:04, Manfred A. Reiter ma.rei...@gmail.com a écrit : Bonjour Pierre, j'ai appris l'ordinateur, logicil, disque dur ... etc., mais workflow ... c'est qoui von français? [image: *;) Clin d’œil] 2015-01-02 16:54 GMT+01:00 Pierre Béland pierz...@yahoo.fr: Bonjour Manfred, Tu t'exprimes assez bien en français, sauf quelques fautes de syntaxe. Et de toute façon, tu utilises moins de mots étrangers que les français eux-mêmes [image: *;) Clin d’œil] Bonne année à toi aussi. Pierre -- *De :* Manfred A. Reiter ma.rei...@gmail.com *À :* Discussions sur OSM en français talk-fr@openstreetmap.org; Madalina Ionescu madalinaionesc...@gmail.com *Envoyé le :* Vendredi 2 janvier 2015 10h45 *Objet :* Re: [OSM-talk-fr] weeklyOSM en français? à propos: bonne année a tous, et encore une fois: excusez mon mauvais français, s'il vous plait. 2015-01-02 15:57 GMT+01:00 Jean-Baptiste Holcroft jb.holcr...@gmail.com : Christian/Manfred, l'objectif est d'avoir une équipe de traduction ou une équipe éditoriale ? Le sujet est évidemment intéressant, mais j'ai aussi peur de ne pas avoir la disponibilité sur la durée. *Equipe: * Oui, vous avez raison, it faut une équipe - au moins de deux personnes, d'autant plus, tant mieux. ;-) *Traduction ou Éditoriale?* Les deux. Je vais essayer d'expliquer le workflow de la Wochennotiz http://blog.openstreetmap.de/ (WN) - weeklyOSM http://www.weeklyosm.eu/es/. 1. Une fois nous obtenons les rapports finaux du blog hebdomadaire allemand WN (Je suis membre de l'équipe éditoriale). 2. Pour la version en englais je supprime les messages qui sont d'intérêt que pour l'Allemagne. 3. J' ajoute des messages qui sont d'intérêt général, mais n'a pas été inclus dans la Wochennotiz ou qui ont un niveau d'instruction general. (Example: Did you know ... ) 4. Carlos, notre collègue espagnol, traduit, élimie et ajoute ce qu'il pense est intéressant pour sa communauté. En quelques mots, il ya un flux de données à la WN (parce que Carlos et moin, nous observons le monde francophone et l'Amérique latine de l'OSM.), et le weeklyOSM est de 98% une traduction de la WN. Je espère que vous pouvez comprendre mes explications, écrit dans un mauvais français. Pardonnez mois. Manfred ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- ## Manfred Reiter - - ## A. Because it breaks the logical sequence of discussion ## Q. Why is top posting bad? ## Please avoid sending me Word or PowerPoint attachments. ## See: http://www.gnu.org/philosophy/no-word-attachments.html ## INGOTs Assessor Trainer ## (International Grades in Open Technologies) ## www.theingots.org ## www.igab-saar.de - Brückendemo 2007 - 4500 Menschen ## 16.02.2008 - Aktionstag Saarlouis - 7.000 Menschen ## 23.02.2008 - an der Katastrophe vorbeigeschrammt - 60.000 Menschen ## 24.02.2008 - Demo Saarwellingen - 6.000 Menschen - Der Schlossplatz ist zu klein ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] weeklyOSM en français?
Cher Philippe, merci beaucoup pour l'explication détaillée. Donc, ce que j'ai explicé c'était l'organisation du travail avec la répartition des tâches, n'est-ce pas? ;-) 2015-01-03 7:28 GMT+01:00 Philippe Verdy verd...@wanadoo.fr: On peut traduire workflow par plan de travail (quoique l'expression peut aussi désigner une table ou une surface plane en cuisine ou dans un atelier, le mot plan a plusieurs sens en français), ou organisation du travail. Les ingénieurs francophones et entreprises ont tendance à garder le mot anglais, mais souvent employé aussi à mauvais escient quand cela désigne plutôt une méthode de travail, ou la répartition des tâches entre les acteurs disponibles, ou le modèle organisationnel pour la direction et le suivi d'un projet; ou un diagramme des activités, ou un processus. L'anglicisme est parfois à conserver; chaque projet choisissant sa terminologie justement à la façon dont il s'organise et les outils utilisés et selon les tâches assignées entre les responsables de certains lots, surtout dans les domaines techniques et informatiques comme ici en cartographie informatique. Le 2 janvier 2015 17:04, Manfred A. Reiter ma.rei...@gmail.com a écrit : Bonjour Pierre, j'ai appris l'ordinateur, logicil, disque dur ... etc., mais workflow ... c'est qoui von français? [image: *;) Clin d’œil] 2015-01-02 16:54 GMT+01:00 Pierre Béland pierz...@yahoo.fr: Bonjour Manfred, Tu t'exprimes assez bien en français, sauf quelques fautes de syntaxe. Et de toute façon, tu utilises moins de mots étrangers que les français eux-mêmes [image: *;) Clin d’œil] Bonne année à toi aussi. Pierre -- *De :* Manfred A. Reiter ma.rei...@gmail.com *À :* Discussions sur OSM en français talk-fr@openstreetmap.org; Madalina Ionescu madalinaionesc...@gmail.com *Envoyé le :* Vendredi 2 janvier 2015 10h45 *Objet :* Re: [OSM-talk-fr] weeklyOSM en français? à propos: bonne année a tous, et encore une fois: excusez mon mauvais français, s'il vous plait. 2015-01-02 15:57 GMT+01:00 Jean-Baptiste Holcroft jb.holcr...@gmail.com : Christian/Manfred, l'objectif est d'avoir une équipe de traduction ou une équipe éditoriale ? Le sujet est évidemment intéressant, mais j'ai aussi peur de ne pas avoir la disponibilité sur la durée. *Equipe: * Oui, vous avez raison, it faut une équipe - au moins de deux personnes, d'autant plus, tant mieux. ;-) *Traduction ou Éditoriale?* Les deux. Je vais essayer d'expliquer le workflow de la Wochennotiz http://blog.openstreetmap.de/ (WN) - weeklyOSM http://www.weeklyosm.eu/es/. 1. Une fois nous obtenons les rapports finaux du blog hebdomadaire allemand WN (Je suis membre de l'équipe éditoriale). 2. Pour la version en englais je supprime les messages qui sont d'intérêt que pour l'Allemagne. 3. J' ajoute des messages qui sont d'intérêt général, mais n'a pas été inclus dans la Wochennotiz ou qui ont un niveau d'instruction general. (Example: Did you know ... ) 4. Carlos, notre collègue espagnol, traduit, élimie et ajoute ce qu'il pense est intéressant pour sa communauté. En quelques mots, il ya un flux de données à la WN (parce que Carlos et moin, nous observons le monde francophone et l'Amérique latine de l'OSM.), et le weeklyOSM est de 98% une traduction de la WN. Je espère que vous pouvez comprendre mes explications, écrit dans un mauvais français. Pardonnez mois. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Bonne année
Je ne pense pas non plus que la séparation des collectivités territoriales du Rhône et de la Métropole de Lyn change le découpage administratif de l'Etat; celui de la préfecture du Rhône. Je n'ai pas vu la nomination d'un nouveau préfet ou sous-préfet de Lyon; et pas plus de réorganisation des services préfectoraux. Les préfets sont déjà compétents pour gérer plusieurs collectivités: départements, régions, communes, EPCI à fiscalité propres, syndicats mixtes. Et on n'est pas à l'heure où l'Etat va augmenter encore sa propre administration préfectorale. (Note: il peut y avoir depuis longtemps deux préfectures ou sous-préfectures à la même adresse comme en Alsace; la sous-préfecture n'est pas nécessairement dans le territoire de l'arrondissement départemental) Le 1 janvier 2015 21:55, Christian Quest cqu...@openstreetmap.fr a écrit : Le découpage NUTS n'est pas (en théorie) administratif... chaque niveau représente en principe une population plus ou moins comparable d'un pays à l'autre. Il serait donc de mon point de vue plus logique de conserver le découpage NUTS sur l'ensemble Rhône + Métropole, plutôt que d'avoir 2 polygones avec le même ref:NUTS. Le 1 janvier 2015 21:42, Otourly Wiki otou...@yahoo.fr a écrit : Donc il faux créer une relation qui englobe le tout spécifiquement pour la subdivision NUTS ? Florian Le Jeudi 1 janvier 2015 20h42, Philippe Verdy verd...@wanadoo.fr a écrit : Note que la subdivision NUTS contient encore tout le département du Rhône y compris la métropole de Lyon qui s.'en est détachée. Pas sûr que NUTS soit invalidé ou mis à jour avant longtemps) Le 1 janv. 2015 16:43, Otourly Wiki otou...@yahoo.fr a écrit : Bonne année Et pour bien commencer l'année une modification non des moindres : http://www.openstreetmap.org/relation/1663048 http://www.openstreetmap.org/relation/7378 Du coup il faudra prévoir une mise à jour du(des) jeu(x) de données concernés sur le portail Opendata Florian -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cantons
Le travail est en cours mais il y a peu de monde dessus (également pour les vérifier exhaustivement, j'ai noté des erreurs dans ceux qui étaient tracés par endroit). C'est compliqué et long à faire dans les communes subdivisées : les arrêtés ne sont pas toujours très précis ou il nous manque des noms de rues, parfois ce sont des coordonnées légales Lambert à convertir en coordonnées GPS WGS84, avec l'outil téléchargeable Circé France (version 4.2 actuellement) si on veut une bonne précision. Mais pour la grande majorité des cantons manquants encore ce n'est pas compliqué de prendre la liste des communes et créer les relations. La page wiki progresse un peu plus vite ces temps-ci; département par département (certaines régions sont entièrement faites ou presque; la première a été la Bretagne puis Rhône-Alpes et le Nord-Pas-de-Calais). http://wiki.openstreetmap.org/wiki/FR:Cantons_in_France Pour certains cantons il y a des FIXME là où il y a une imprécision ou des infos encore à chercher, mais ce n'est pas une raison pour ne pas au moins les commencer pour aller vite sur ce qui est connu même si'l reste des trucs à chercher. Le 2 janvier 2015 02:50, Jérôme Amagat jerome.ama...@gmail.com a écrit : On parle de mouvement dans les communes et les métropoles. et les cantons? On a 2 types de Cantons dans osm : Ceux qui sont effectifs mais qui ne servent plus à grand chose. Et ceux à partir desquels, les élections vont avoir lieu au mois de mars. indiquer avec des planned: A partir de quand on passe les 1er en disused: (ou un truc du genre) et on enlève ce planned: sur les autre? On va surement bientôt en entendre parler dans les média. (ça serai aussi pas mal qu'avant les élection tous les cantons soit présent dans osm) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Communes nouvelles - fusion de communes
Désolé de le dire mais des communes associées ont leurs propres quartiers au niveau 10. Le niveau 9 est approprié pour les toutes communes associées dans une commune fusion-association de niveau 8, c'est plutôt à ton script de faire une éventuelle exception pour les 3 seules communes à arrondissements en France bien qu'il n'y ait aucune ambiguité quant on voit seulement les noms de leurs arrondissements numérotés. Ces 3 exceptions n'empêcheront pas alors de cartographier les 700 communes associées (dont celles qui manquent par exemple à Lille où la centaine d'homonymies de rues pose problème : les noms des communes associées font bel et bien partie des adresses; par exemple Hellemmes ou Wazemmes, qui ont aussi leur propres quartiers en plus au niveau 10 de la même façon que les quartiers administratifs parisiens ou lyonnais découpant les arrondissements !). Le 1 janvier 2015 15:26, Christian Quest cqu...@openstreetmap.fr a écrit : J'ai remis les admin_level à 10, ça mettait la pagaille dans mon script de génération des limites de communes/arrondissements municipaux. J'ai aussi remis le ref:INSEE du chef lieu des communes fusionnées comme ref:INSEE de la nouvelle commune... c'est peut être pas parfait, il faudra attendre le COG2015 pour savoir si c'est la règle ou pas (voire même si il y a une logique). Je tente de sortir un nouveau fichier complet les limites communales pour data.gouv.fr... le mettre à dispo le 1er janvier c'est un chouette challenge, non ? Le 01/01/2015 15:13, Damouns a écrit : Cool merci à tous ! Je vois que les métropoles c'est fait aussi. ___ Talk-fr mailing listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] noms non trouvés sur cadastre
Ah oui, dans ce cas, c'est la bonne solution. Je pensais à un autre cas que j'ai rencontré : une rue normale, entourée de maisons, pour laquelle aucun nom n'apparait sur le plan cadastral, quel que soit le niveau de zoom, mais pour laquelle la couche BANO présente un polygone convexe avec un nom, nom qui existe dans le FANTOIR. Ce cas là est, a mon avis, un manque du cadastre, pas de FANTOIR. Art. Le 2 janv. 2015 12:49, David Crochet david.croc...@free.fr a écrit : Bonjour Le 02/01/2015 12:37, Art Penteur a écrit : je ne vois*pas* le cas cité par Nicolas ( nom de voie est rapporté sur BANO (sans doute issu des adresses des parcelles), mais dont le nom n'est pas indiqué sur la couche cadastre) J'ai le cas d'une parcelle contenant uniquement un transformateur électrique. Tout autour de lui, tout à changé (ZI) et une nouvelle rue a été nommé pour alimenter les nouveaux bâtiments. Un nom a été donnée à cette rue avec son code fantoir (61168X002G), elle apparaît en clair sur le site du cadastre en ligne De cette parcelle, est associé dons l'ancienne route, avec elle aussi son code fantoir(611681211M). Sur place, cette parcelle administrativement existe, mais rien n'indique son nom. Sur le cadastre en ligne, si je demande des données sur cette parcelle, il me ressort bien son nom avec le nom de la route, mais pas de la rue qui pour cette dernière est bien associé à tout son environnement. J'ai donc signalé sur le site cadastre/fantoir que cette route est Nom introuvable sur le terrain. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] weeklyOSM en français?
Je vais certainement proposer à Manfred et weeklyOSM ma participation. Mais comme je ne serai pas disponible chaque semaine, je suppose qu'il serait intéressant d'avoir d'autres volontaires pour se passer le relais de temps à autre. althio 2015-01-02 14:46 GMT+01:00 Christian Quest cqu...@openstreetmap.fr: Aucun réponse au message de Manfred ? Trop occupés à mapper ? Mais il faut lever un peu la tête de temps en temps pour ce genre d'action qui permettent d'être plus nombreux et d'animer la communauté... C'est le moment des bonnes résolutions ;) Le 27 décembre 2014 15:58, Manfred A. Reiter ma.rei...@gmail.com a écrit : Bonjour à tous, Excusez mon mauvais français, s'il vous plait. Mon nom est Manfred, je vis dans la Sarre (près de La Lorraine et du Luxembourg). Je suis responsable pour la coordination du travail au www.weeklyosm.eu. Peut-être l'un ou l'autre connait notre blog hebdomadaire, avec les nouvelles importantes du monde de l'OSM. Nous croyons que la communauté française de OSM est si important qu'il mérite sa propre version en langue française. Nous serions très heureux si quelqu'un de la communauté française aimerait se joindre à notre équipe. Contactez-nous s'il vous plait via theweekly...@gmail.com. -- ## Manfred ## www.weeklyosm.eu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] weeklyOSM en français?
J'en profite pour adresser mes remerciements aux auteurs de feu le bulletin OSM-fr, qui était une source d'information variée et dense. Art. Le 2 janv. 2015 14:47, Christian Quest cqu...@openstreetmap.fr a écrit : Aucun réponse au message de Manfred ? Trop occupés à mapper ? Mais il faut lever un peu la tête de temps en temps pour ce genre d'action qui permettent d'être plus nombreux et d'animer la communauté... C'est le moment des bonnes résolutions ;) Le 27 décembre 2014 15:58, Manfred A. Reiter ma.rei...@gmail.com a écrit : Bonjour à tous, Excusez mon mauvais français, s'il vous plait. Mon nom est Manfred, je vis dans la Sarre (près de La Lorraine et du Luxembourg). Je suis responsable pour la coordination du travail au www.weeklyosm.eu. Peut-être l'un ou l'autre connait notre blog hebdomadaire, avec les nouvelles importantes du monde de l'OSM. Nous croyons que la communauté française de OSM est si important qu'il mérite sa propre version en langue française. Nous serions très heureux si quelqu'un de la communauté française aimerait se joindre à notre équipe. Contactez-nous s'il vous plait via theweekly...@gmail.com. -- ## Manfred ## www.weeklyosm.eu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] noms non trouvés sur cadastre
Merci pour le rappel de ce truc, une piqûre de rappel de temps en temps ne fait pas de mal. Mais je maintiens ce que j'ai dit dans mon cas : le nom de rue est bien absent sur le plan cadastral, que j'ai récupéré sous plusieurs formes. Art. Le 2 janv. 2015 14:31, David Crochet david.croc...@free.fr a écrit : Bonjour Le 02/01/2015 14:08, Art Penteur a écrit : Ce cas là est, a mon avis, un manque du cadastre, pas de FANTOIR. Il y a un piège dans le cadastre en ligne : Si je comprend bien le principe, il (JOSM) télécharge, au format image, des carrées de données enregistré en vectoriel. Chaque image étant fabriqué indépendamment des autres : il y a parfois des morceau de texte sur l'un des carrées puis plus rien sur l'autre, on zoom, tiens, c'est l'inverse, on dézomme, tout le texte apparait. La solution : demander, sur le cadastre en ligne, un export en PDF : il est encore plus net que les images téléchargé par JOSM. Ce PDF, je le fout en arrière plan dans JOSM ou alors je travaille côte-côte. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] weeklyOSM en français?
Aucun réponse au message de Manfred ? Trop occupés à mapper ? Mais il faut lever un peu la tête de temps en temps pour ce genre d'action qui permettent d'être plus nombreux et d'animer la communauté... C'est le moment des bonnes résolutions ;) Le 27 décembre 2014 15:58, Manfred A. Reiter ma.rei...@gmail.com a écrit : Bonjour à tous, Excusez mon mauvais français, s'il vous plait. Mon nom est Manfred, je vis dans la Sarre (près de La Lorraine et du Luxembourg). Je suis responsable pour la coordination du travail au www.weeklyosm.eu. Peut-être l'un ou l'autre connait notre blog hebdomadaire, avec les nouvelles importantes du monde de l'OSM. Nous croyons que la communauté française de OSM est si important qu'il mérite sa propre version en langue française. Nous serions très heureux si quelqu'un de la communauté française aimerait se joindre à notre équipe. Contactez-nous s'il vous plait via theweekly...@gmail.com. -- ## Manfred ## www.weeklyosm.eu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] noms non trouvés sur cadastre
Bonjour Le 02/01/2015 12:37, Art Penteur a écrit : je ne vois*pas* le cas cité par Nicolas ( nom de voie est rapporté sur BANO (sans doute issu des adresses des parcelles), mais dont le nom n'est pas indiqué sur la couche cadastre) J'ai le cas d'une parcelle contenant uniquement un transformateur électrique. Tout autour de lui, tout à changé (ZI) et une nouvelle rue a été nommé pour alimenter les nouveaux bâtiments. Un nom a été donnée à cette rue avec son code fantoir (61168X002G), elle apparaît en clair sur le site du cadastre en ligne De cette parcelle, est associé dons l'ancienne route, avec elle aussi son code fantoir(611681211M). Sur place, cette parcelle administrativement existe, mais rien n'indique son nom. Sur le cadastre en ligne, si je demande des données sur cette parcelle, il me ressort bien son nom avec le nom de la route, mais pas de la rue qui pour cette dernière est bien associé à tout son environnement. J'ai donc signalé sur le site cadastre/fantoir que cette route est Nom introuvable sur le terrain. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] noms non trouvés sur cadastre
Bonjour, Sur la Couche Bano, en rouge, ce sont des données qui viennent du cadastre donc pas besoin de vérifier a nouveau sur le cadastre dans le cas où c'est facile de déduire quelle portion de route porte ce nom. Dans le cadastre vecteur 2 types d'infos : - celles que tu vois quand tu regarde l'image du cadastre (les nom de rue ecite sur les chemin, mairie ecole...) - les données a l’intérieur de chaque parcelle. pour chaque parcelle il y a une adresse d'inscrite. et quand c'est un numero et un nom de rue (et pas seulement le nom du lieu dit) il va apparaître sur la couche Bano. Ces info sont plus à jour que les précédentes. On peut retrouver ces info sur http://www.cadastre.gouv.fr/ (cliquer sur une parcelle puis faite valider en bas a droite) ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] noms non trouvés sur cadastre
Bonjour Le 02/01/2015 14:08, Art Penteur a écrit : Ce cas là est, a mon avis, un manque du cadastre, pas de FANTOIR. Il y a un piège dans le cadastre en ligne : Si je comprend bien le principe, il (JOSM) télécharge, au format image, des carrées de données enregistré en vectoriel. Chaque image étant fabriqué indépendamment des autres : il y a parfois des morceau de texte sur l'un des carrées puis plus rien sur l'autre, on zoom, tiens, c'est l'inverse, on dézomme, tout le texte apparait. La solution : demander, sur le cadastre en ligne, un export en PDF : il est encore plus net que les images téléchargé par JOSM. Ce PDF, je le fout en arrière plan dans JOSM ou alors je travaille côte-côte. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] noms non trouvés sur cadastre
Le 2 janv. 2015 15:27, Jérôme Amagat jerome.ama...@gmail.com a écrit : On peut retrouver ces info sur http://www.cadastre.gouv.fr/ (cliquer sur une parcelle puis faite valider en bas a droite) Merci pour ce truc que je ne connaissais pas. Art. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] conseil achat smartphone Android bon GPS?
99 $US pour une précision relative de 3 mètres et une batterie minimale de 1100 mAH qui ne tient que 12 heures (neuve), je trouve ça un peu limite et cher; d'autant olus qu'il n'y a aucun écran (qui compte pour la moitié du prix d'un smartphone). Regardez aussi le temps de démarrage à froid: 1 minute (30 secondes en veille); plus 5 secondes pour la première acquisition. La batterie ne vaut guère plus de 10 euros (marge constructeur/vendeur incluse), la puce de décodage et avec un petit microprocesseur léger pas plus de 5 euros, les antennes GPS et Bluetooth pas plus d'1 euro comme le boitier plastique, le tout ne devrait pas coûter plus de 30 euros. Ajouter aussi le prix du support non inclus: 15 $US pour une fixation uniquement par friction donc uniquement posé à plat sur un tableau de bord ! Garmin ici fait monter les prix mais c'est sans doute parce que ce type de produit est pour une niche assez marginale du marché quand tout le monde utilise des GPS intégrés (avec écran 4/5 pouces et fixation incluse, plus une carto pour pratiquement le même prix celui d'une petite tablette) ou son smartphone. Mais là il n'y a même pas un petit afficheur LCD donnant au moins les coordonnées en continu à lire. Quant à l'association en Bluetooth, déjà que le smartphone sera connecté à un navigateur, je me demande quel est l'usage de ce truc qui n'a aucune fonction de mobilité sans afficheur minimal et sans autonomie correcte. Disons que ça ne peut servir qu'à ceux dont le smartphone ou la tablette n'a pas déjà un GPS intégré. Mais est-ce qu'avec la connexion Bluetooth ou USB les applis tournant sur le smartphone ou la tablette reconnaîtront les positions fournies par cet appareil? L'inquiétude c'est la liste des appareils compatibles qui ont leurs applis spécifiques pour utiliser cet appareil: elle est trop restreinte il n'est visiblement pas prévu une appli Android générique greffant un pilote reconnu par les autres applis. Et rien de précisé concernant les exports possibles de données. Tant qu'à faire autant passer à un autre modèle avec écran comme celui-ci l'eTrex 10 (le plus petit de la gamme hiking mais avec au moins un écran et 25 heures d'autonomie et des batteries AA recharchables classiques ou NiMH) https://buy.garmin.com/en-US/US/on-the-trail/handhelds/etrex-10/prod87768.html (import/export inclus des GPX, support GPS+GLONASS jusqu'à 12 satellites simultanés dans les 2 constellations, pas de Bluetooth, donc meilleure autonomie, mais USB inclus; plus d'options de montage pour voiture, vélo; et étanche pour usage extérieur...) Le 3 janvier 2015 01:28, Shohreh codecompl...@free.fr a écrit : Je pense à une alternative : plutôt que d'acheter un nouveau smartphone avec support pour GPS + Glonass, quid d'un récepteur externe avec connexion au smartphone par Bluetooth ou câble USB-OTG? https://buy.garmin.com/en-US/US/oem/sensors-and-boards/glo-/prod109827.html Ça coûte moins cher et ça semble plus efficace qu'un composant dans un smartphone. -- View this message in context: http://gis.19327.n5.nabble.com/Smartphone-Android-avec-GPS-rapide-tp5777133p5828812.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] weeklyOSM en français?
Bonjour Pierre, j'ai appris l'ordinateur, logicil, disque dur ... etc., mais workflow ... c'est qoui von français? [image: *;) Clin d’œil] 2015-01-02 16:54 GMT+01:00 Pierre Béland pierz...@yahoo.fr: Bonjour Manfred, Tu t'exprimes assez bien en français, sauf quelques fautes de syntaxe. Et de toute façon, tu utilises moins de mots étrangers que les français eux-mêmes [image: *;) Clin d’œil] Bonne année à toi aussi. Pierre -- *De :* Manfred A. Reiter ma.rei...@gmail.com *À :* Discussions sur OSM en français talk-fr@openstreetmap.org; Madalina Ionescu madalinaionesc...@gmail.com *Envoyé le :* Vendredi 2 janvier 2015 10h45 *Objet :* Re: [OSM-talk-fr] weeklyOSM en français? à propos: bonne année a tous, et encore une fois: excusez mon mauvais français, s'il vous plait. 2015-01-02 15:57 GMT+01:00 Jean-Baptiste Holcroft jb.holcr...@gmail.com: Christian/Manfred, l'objectif est d'avoir une équipe de traduction ou une équipe éditoriale ? Le sujet est évidemment intéressant, mais j'ai aussi peur de ne pas avoir la disponibilité sur la durée. *Equipe: * Oui, vous avez raison, it faut une équipe - au moins de deux personnes, d'autant plus, tant mieux. ;-) *Traduction ou Éditoriale?* Les deux. Je vais essayer d'expliquer le workflow de la Wochennotiz http://blog.openstreetmap.de/ (WN) - weeklyOSM http://www.weeklyosm.eu/es/. 1. Une fois nous obtenons les rapports finaux du blog hebdomadaire allemand WN (Je suis membre de l'équipe éditoriale). 2. Pour la version en englais je supprime les messages qui sont d'intérêt que pour l'Allemagne. 3. J' ajoute des messages qui sont d'intérêt général, mais n'a pas été inclus dans la Wochennotiz ou qui ont un niveau d'instruction general. (Example: Did you know ... ) 4. Carlos, notre collègue espagnol, traduit, élimie et ajoute ce qu'il pense est intéressant pour sa communauté. En quelques mots, il ya un flux de données à la WN (parce que Carlos et moin, nous observons le monde francophone et l'Amérique latine de l'OSM.), et le weeklyOSM est de 98% une traduction de la WN. Je espère que vous pouvez comprendre mes explications, écrit dans un mauvais français. Pardonnez mois. Manfred ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- ## Manfred Reiter - - ## A. Because it breaks the logical sequence of discussion ## Q. Why is top posting bad? ## Please avoid sending me Word or PowerPoint attachments. ## See: http://www.gnu.org/philosophy/no-word-attachments.html ## INGOTs Assessor Trainer ## (International Grades in Open Technologies) ## www.theingots.org ## www.igab-saar.de - Brückendemo 2007 - 4500 Menschen ## 16.02.2008 - Aktionstag Saarlouis - 7.000 Menschen ## 23.02.2008 - an der Katastrophe vorbeigeschrammt - 60.000 Menschen ## 24.02.2008 - Demo Saarwellingen - 6.000 Menschen - Der Schlossplatz ist zu klein ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] weeklyOSM en français?
Bonjour Manfred, Tu t'exprimes assez bien en français, sauf quelques fautes de syntaxe. Et de toute façon, tu utilises moins de mots étrangers que les français eux-mêmes Bonne année à toi aussi. Pierre De : Manfred A. Reiter ma.rei...@gmail.com À : Discussions sur OSM en français talk-fr@openstreetmap.org; Madalina Ionescu madalinaionesc...@gmail.com Envoyé le : Vendredi 2 janvier 2015 10h45 Objet : Re: [OSM-talk-fr] weeklyOSM en français? à propos: bonne année a tous, et encore une fois: excusez mon mauvais français, s'il vous plait. 2015-01-02 15:57 GMT+01:00 Jean-Baptiste Holcroft jb.holcr...@gmail.com: Christian/Manfred, l'objectif est d'avoir une équipe de traduction ou une équipe éditoriale ? Le sujet est évidemment intéressant, mais j'ai aussi peur de ne pas avoir la disponibilité sur la durée. Equipe: Oui, vous avez raison, it faut une équipe - au moins de deux personnes, d'autant plus, tant mieux. ;-) Traduction ou Éditoriale?Les deux. Je vais essayer d'expliquer le workflow de la Wochennotiz (WN) - weeklyOSM. 1. Une fois nous obtenons les rapports finaux du blog hebdomadaire allemand WN (Je suis membre de l'équipe éditoriale). 2. Pour la version en englais je supprime les messages qui sont d'intérêt que pour l'Allemagne. 3. J' ajoute des messages qui sont d'intérêt général, mais n'a pas été inclus dans la Wochennotiz ou qui ont un niveau d'instruction general. (Example: Did you know ... ) 4. Carlos, notre collègue espagnol, traduit, élimie et ajoute ce qu'il pense est intéressant pour sa communauté. En quelques mots, il ya un flux de données à la WN (parce que Carlos et moin, nous observons le monde francophone et l'Amérique latine de l'OSM.), et le weeklyOSM est de 98% une traduction de la WN. Je espère que vous pouvez comprendre mes explications, écrit dans un mauvais français. Pardonnez mois. Manfred ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] weeklyOSM en français?
Christian/Manfred, l'objectif est d'avoir une équipe de traduction ou une équipe éditoriale ? Le sujet est évidemment intéressant, mais j'ai aussi peur de ne pas avoir la disponibilité sur la durée. Le 2 janv. 2015 16:46, Art Penteur art.pent...@gmail.com a écrit : J'en profite pour adresser mes remerciements aux auteurs de feu le bulletin OSM-fr, qui était une source d'information variée et dense. Art. Le 2 janv. 2015 14:47, Christian Quest cqu...@openstreetmap.fr a écrit : Aucun réponse au message de Manfred ? Trop occupés à mapper ? Mais il faut lever un peu la tête de temps en temps pour ce genre d'action qui permettent d'être plus nombreux et d'animer la communauté... C'est le moment des bonnes résolutions ;) Le 27 décembre 2014 15:58, Manfred A. Reiter ma.rei...@gmail.com a écrit : Bonjour à tous, Excusez mon mauvais français, s'il vous plait. Mon nom est Manfred, je vis dans la Sarre (près de La Lorraine et du Luxembourg). Je suis responsable pour la coordination du travail au www.weeklyosm.eu. Peut-être l'un ou l'autre connait notre blog hebdomadaire, avec les nouvelles importantes du monde de l'OSM. Nous croyons que la communauté française de OSM est si important qu'il mérite sa propre version en langue française. Nous serions très heureux si quelqu'un de la communauté française aimerait se joindre à notre équipe. Contactez-nous s'il vous plait via theweekly...@gmail.com. -- ## Manfred ## www.weeklyosm.eu ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] weeklyOSM en français?
à propos: bonne année a tous, et encore une fois: excusez mon mauvais français, s'il vous plait. 2015-01-02 15:57 GMT+01:00 Jean-Baptiste Holcroft jb.holcr...@gmail.com: Christian/Manfred, l'objectif est d'avoir une équipe de traduction ou une équipe éditoriale ? Le sujet est évidemment intéressant, mais j'ai aussi peur de ne pas avoir la disponibilité sur la durée. *Equipe: * Oui, vous avez raison, it faut une équipe - au moins de deux personnes, d'autant plus, tant mieux. ;-) *Traduction ou Éditoriale?* Les deux. Je vais essayer d'expliquer le workflow de la Wochennotiz http://blog.openstreetmap.de/ (WN) - weeklyOSM http://www.weeklyosm.eu/es/. 1. Une fois nous obtenons les rapports finaux du blog hebdomadaire allemand WN (Je suis membre de l'équipe éditoriale). 2. Pour la version en englais je supprime les messages qui sont d'intérêt que pour l'Allemagne. 3. J' ajoute des messages qui sont d'intérêt général, mais n'a pas été inclus dans la Wochennotiz ou qui ont un niveau d'instruction general. (Example: Did you know ... ) 4. Carlos, notre collègue espagnol, traduit, élimie et ajoute ce qu'il pense est intéressant pour sa communauté. En quelques mots, il ya un flux de données à la WN (parce que Carlos et moin, nous observons le monde francophone et l'Amérique latine de l'OSM.), et le weeklyOSM est de 98% une traduction de la WN. Je espère que vous pouvez comprendre mes explications, écrit dans un mauvais français. Pardonnez mois. Manfred ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [BANO] noms non trouvés sur cadastre
hrtp://cadastre.openstreetmap.fr/adresses exporte aussi en fichier .osm la pluspart des noms dessinés sur l'export pdf. Le 2 janv. 2015 14:31, David Crochet david.croc...@free.fr a écrit : Bonjour Le 02/01/2015 14:08, Art Penteur a écrit : Ce cas là est, a mon avis, un manque du cadastre, pas de FANTOIR. Il y a un piège dans le cadastre en ligne : Si je comprend bien le principe, il (JOSM) télécharge, au format image, des carrées de données enregistré en vectoriel. Chaque image étant fabriqué indépendamment des autres : il y a parfois des morceau de texte sur l'un des carrées puis plus rien sur l'autre, on zoom, tiens, c'est l'inverse, on dézomme, tout le texte apparait. La solution : demander, sur le cadastre en ligne, un export en PDF : il est encore plus net que les images téléchargé par JOSM. Ce PDF, je le fout en arrière plan dans JOSM ou alors je travaille côte-côte. Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] conseil achat smartphone Android bon GPS?
Je pense à une alternative : plutôt que d'acheter un nouveau smartphone avec support pour GPS + Glonass, quid d'un récepteur externe avec connexion au smartphone par Bluetooth ou câble USB-OTG? https://buy.garmin.com/en-US/US/oem/sensors-and-boards/glo-/prod109827.html Ça coûte moins cher et ça semble plus efficace qu'un composant dans un smartphone. -- View this message in context: http://gis.19327.n5.nabble.com/Smartphone-Android-avec-GPS-rapide-tp5777133p5828812.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
