Re: [talk-ph] ternate - nasugbu tunnel
It seems to be in OSM already but part of the route is marked as highway=track. There's also a tunnel present: http://osm.org/go/4zKlwYzB- On Sun, Mar 3, 2013 at 11:45 AM, rem zamora pompy...@gmail.com wrote: i passed this road already. lemme check my gps files when i get home. last time i went there last january, it is still being constructed but about 80 percent complete and cars can pass the tunnel one at a time. if you are coming from manila to nasugbu, this is a good alternative route since you will bypass the traffic of sta rosa and tagaytay already. good roads that is comparable to subic roads. sometimes you can even see monkeys by the road side. right after puerto azul, there is a junction to your left. it is a paved road. you wont go straight to caylabne. just go straight pagkakaliwa mo, tutumbukin mo na yung tunnel na yun lusot mo sa pico de loro at tali beach and other sosi beach resorts :) rem On Sun, Mar 3, 2013 at 11:33 AM, tutubi tut...@backpackingphilippines.com wrote: where exactly is this? is this near puerto azul? is this already on OSM but UC? thanks --- I explore, therefore I blog! http://www.backpackingphilippines.com http://www.facebook.com/backpackingPhilippines http://www.twitter.com/backpackPH ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- Rem Zamora Photojournalist +63-917-592-74-33 -link to my photos-http://www.googleplussuomi.com/photobox/?googleid=110367850779921090576 ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] replace ref on stops De Lijn with mijnlijn.be/x0xxxx
Schitterend ! Dankjewel Alexander en Sander. Georges 2013/3/2 Jo winfi...@gmail.com Alexander implemented Sander's suggestion on Openlinkmap.org: Go to: http://www.openlinkmap.org/?zoom=18lat=50.8819lon=4.71503layers=BFT Make sure the public transport layer is in view Click on one of the stops. Click on the link after timetables and get the passages of buses at that stop in real time. This only works for stops where operator contains De Lijn and ref is (already) set to the six digit number found on all the stops. Thanks to Alexander and Sander! Jo 2013/1/31 Sander Deryckere sander...@gmail.com 2013/1/31 Jo winfi...@gmail.com Hi, I like that proposal, but I don't know how to implement it for openlinkmap. The developer is accepting patches, but he doesn't have time to code stuff himself anymore. That's a pity. My initial proposal had the advantage of instant gratification. It would work with the current tagging habits. It's true that it has the disadvantage of being dependent on the continued use of that url domain by De Lijn and it's more verbose than I would like. I agree with the advantage it has, but it creates other difficulties like maintainability of the database. It's like the Don't tag for the renderer, only, a bit different. It's not because openlinkmap displays a certain tag, that we should tag everything this way. One small remark. The way I understand it we are moving to replacing highway=bus_stop with public_transport=platform. So it should work for that combination of tags as well. And it should be enough that a node contains De Lijn. Some stops are shared with MIVB/STIB, TEC and VEOLIA. These are valid remarks, and show why the configuration file should be crowd sourced. A single developer can never come up with all these exceptions for all these different nations. Jo I looked at the openlinkmap code, and it seems that he's filtering a lot of tags before the file gets imported in a database. The filtering also happens with a program that doesn't allow regex, only wildcards. So reading such a configuration file would be a hell of a job. I think I found something better. We could use the osmosis tagtransform plugin (http://wiki.osm.org/Osmosis/TagTransform). Where we could use a configuration file to transform tags to an url:*= tag. Like the example from De Lijn could be as following: http://pastebin.com/4G4FPyEq(currently writing to url:delijn, but we could also check for the existence of an url tag, and write to that if it's not present). The disadvantages of this tool are that an url tag can only be created from a single other tag (as the discussion page on the wiki says), And a key needs to stay a key, and a value needs to stay a value. Another drawback might be the installation of an extra plugin. It doesn't seem so easy as it should be (version conflicts etc). But it should be very straightforward to use the file afterwards, and to have this file crowd sourced. And, on the positive side, the osmosis team is looking into making this task part of the standard installation. In which case you won't have to install anything new at all. Regards, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Tag for 'mutualiteiten' ?
Glen, ik vrees dat dit geen goede keuze is. In het Engels is een office in de context van gezondheidszorg de doctor's office en geen kantoor in de klassieke betekenis. Dit blijkt ook uit de omschrijving bij http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0#health_facility:type.3D.2A . Gilbert On 21 February 2013 12:29, Glenn Plas gl...@byte-consult.be wrote: Denk dat het deze wordt, dit lijkt me prima match. Te vinden in deze v2.0 Healthcare proposal : http://wiki.openstreetmap.org/**wiki/Proposed_features/**Healthcare_2.0http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0 health_facility:type=office Glenn __**_ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-behttp://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] replace ref on stops De Lijn with mijnlijn.be/x0xxxx
Nice program, but every now and then it hangs. I have not yet figured out how to reproduce it in a predictable way, but it seems to be related to opening more than one bubble and eventually the oldest one does not respond to the close button (x). I also saw occurences where all bubbles are clodes when I close the most recently opened bubble. Program seems to have a problem keeping track of mutiple bubbles. On one line I saw a strange warning message. Maybe you know what's causing it ? It's bus stop Perron 2 on the railway station in Mol. Warning: Illegal offset type in /home/www/sites/ 194.245.35.149/site/api/functions.php on line 1248 *Mol Station Perron 2* Operator: De Lijn Gilbert On 2 March 2013 19:25, Jo winfi...@gmail.com wrote: Alexander implemented Sander's suggestion on Openlinkmap.org: Go to: http://www.openlinkmap.org/?zoom=18lat=50.8819lon=4.71503layers=BFT Make sure the public transport layer is in view Click on one of the stops. Click on the link after timetables and get the passages of buses at that stop in real time. This only works for stops where operator contains De Lijn and ref is (already) set to the six digit number found on all the stops. Thanks to Alexander and Sander! Jo 2013/1/31 Sander Deryckere sander...@gmail.com 2013/1/31 Jo winfi...@gmail.com Hi, I like that proposal, but I don't know how to implement it for openlinkmap. The developer is accepting patches, but he doesn't have time to code stuff himself anymore. That's a pity. My initial proposal had the advantage of instant gratification. It would work with the current tagging habits. It's true that it has the disadvantage of being dependent on the continued use of that url domain by De Lijn and it's more verbose than I would like. I agree with the advantage it has, but it creates other difficulties like maintainability of the database. It's like the Don't tag for the renderer, only, a bit different. It's not because openlinkmap displays a certain tag, that we should tag everything this way. One small remark. The way I understand it we are moving to replacing highway=bus_stop with public_transport=platform. So it should work for that combination of tags as well. And it should be enough that a node contains De Lijn. Some stops are shared with MIVB/STIB, TEC and VEOLIA. These are valid remarks, and show why the configuration file should be crowd sourced. A single developer can never come up with all these exceptions for all these different nations. Jo I looked at the openlinkmap code, and it seems that he's filtering a lot of tags before the file gets imported in a database. The filtering also happens with a program that doesn't allow regex, only wildcards. So reading such a configuration file would be a hell of a job. I think I found something better. We could use the osmosis tagtransform plugin (http://wiki.osm.org/Osmosis/TagTransform). Where we could use a configuration file to transform tags to an url:*= tag. Like the example from De Lijn could be as following: http://pastebin.com/4G4FPyEq(currently writing to url:delijn, but we could also check for the existence of an url tag, and write to that if it's not present). The disadvantages of this tool are that an url tag can only be created from a single other tag (as the discussion page on the wiki says), And a key needs to stay a key, and a value needs to stay a value. Another drawback might be the installation of an extra plugin. It doesn't seem so easy as it should be (version conflicts etc). But it should be very straightforward to use the file afterwards, and to have this file crowd sourced. And, on the positive side, the osmosis team is looking into making this task part of the standard installation. In which case you won't have to install anything new at all. Regards, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] replace ref on stops De Lijn with mijnlijn.be/x0xxxx
That mol error is interesting, I'll show it to Alexander 2013/3/3 Gilbert Hersschens gherssch...@gmail.com Nice program, but every now and then it hangs. I have not yet figured out how to reproduce it in a predictable way, but it seems to be related to opening more than one bubble and eventually the oldest one does not respond to the close button (x). I also saw occurences where all bubbles are clodes when I close the most recently opened bubble. Program seems to have a problem keeping track of mutiple bubbles. On one line I saw a strange warning message. Maybe you know what's causing it ? It's bus stop Perron 2 on the railway station in Mol. Warning: Illegal offset type in /home/www/sites/ 194.245.35.149/site/api/functions.php on line 1248 *Mol Station Perron 2* Operator: De Lijn Gilbert On 2 March 2013 19:25, Jo winfi...@gmail.com wrote: Alexander implemented Sander's suggestion on Openlinkmap.org: Go to: http://www.openlinkmap.org/?zoom=18lat=50.8819lon=4.71503layers=BFT Make sure the public transport layer is in view Click on one of the stops. Click on the link after timetables and get the passages of buses at that stop in real time. This only works for stops where operator contains De Lijn and ref is (already) set to the six digit number found on all the stops. Thanks to Alexander and Sander! Jo 2013/1/31 Sander Deryckere sander...@gmail.com 2013/1/31 Jo winfi...@gmail.com Hi, I like that proposal, but I don't know how to implement it for openlinkmap. The developer is accepting patches, but he doesn't have time to code stuff himself anymore. That's a pity. My initial proposal had the advantage of instant gratification. It would work with the current tagging habits. It's true that it has the disadvantage of being dependent on the continued use of that url domain by De Lijn and it's more verbose than I would like. I agree with the advantage it has, but it creates other difficulties like maintainability of the database. It's like the Don't tag for the renderer, only, a bit different. It's not because openlinkmap displays a certain tag, that we should tag everything this way. One small remark. The way I understand it we are moving to replacing highway=bus_stop with public_transport=platform. So it should work for that combination of tags as well. And it should be enough that a node contains De Lijn. Some stops are shared with MIVB/STIB, TEC and VEOLIA. These are valid remarks, and show why the configuration file should be crowd sourced. A single developer can never come up with all these exceptions for all these different nations. Jo I looked at the openlinkmap code, and it seems that he's filtering a lot of tags before the file gets imported in a database. The filtering also happens with a program that doesn't allow regex, only wildcards. So reading such a configuration file would be a hell of a job. I think I found something better. We could use the osmosis tagtransform plugin (http://wiki.osm.org/Osmosis/TagTransform). Where we could use a configuration file to transform tags to an url:*= tag. Like the example from De Lijn could be as following: http://pastebin.com/4G4FPyEq(currently writing to url:delijn, but we could also check for the existence of an url tag, and write to that if it's not present). The disadvantages of this tool are that an url tag can only be created from a single other tag (as the discussion page on the wiki says), And a key needs to stay a key, and a value needs to stay a value. Another drawback might be the installation of an extra plugin. It doesn't seem so easy as it should be (version conflicts etc). But it should be very straightforward to use the file afterwards, and to have this file crowd sourced. And, on the positive side, the osmosis team is looking into making this task part of the standard installation. In which case you won't have to install anything new at all. Regards, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] replace ref on stops De Lijn with mijnlijn.be/x0xxxx
In fact I was a bit too fast posting this on the list... He was still working hard debugging it yesterday. By the time I saw his answer with the request not to post it yet, I had already done that. On the other hand, bug reports probably come in handy when debugging... And Sander, you had the idea for the proposal of doing it right in a broader context right away, so you deserve 'some' credit :-) Cheers, Jo 2013/3/3 Gilbert Hersschens gherssch...@gmail.com Nice program, but every now and then it hangs. I have not yet figured out how to reproduce it in a predictable way, but it seems to be related to opening more than one bubble and eventually the oldest one does not respond to the close button (x). I also saw occurences where all bubbles are clodes when I close the most recently opened bubble. Program seems to have a problem keeping track of mutiple bubbles. On one line I saw a strange warning message. Maybe you know what's causing it ? It's bus stop Perron 2 on the railway station in Mol. Warning: Illegal offset type in /home/www/sites/ 194.245.35.149/site/api/functions.php on line 1248 *Mol Station Perron 2* Operator: De Lijn Gilbert On 2 March 2013 19:25, Jo winfi...@gmail.com wrote: Alexander implemented Sander's suggestion on Openlinkmap.org: Go to: http://www.openlinkmap.org/?zoom=18lat=50.8819lon=4.71503layers=BFT Make sure the public transport layer is in view Click on one of the stops. Click on the link after timetables and get the passages of buses at that stop in real time. This only works for stops where operator contains De Lijn and ref is (already) set to the six digit number found on all the stops. Thanks to Alexander and Sander! Jo 2013/1/31 Sander Deryckere sander...@gmail.com 2013/1/31 Jo winfi...@gmail.com Hi, I like that proposal, but I don't know how to implement it for openlinkmap. The developer is accepting patches, but he doesn't have time to code stuff himself anymore. That's a pity. My initial proposal had the advantage of instant gratification. It would work with the current tagging habits. It's true that it has the disadvantage of being dependent on the continued use of that url domain by De Lijn and it's more verbose than I would like. I agree with the advantage it has, but it creates other difficulties like maintainability of the database. It's like the Don't tag for the renderer, only, a bit different. It's not because openlinkmap displays a certain tag, that we should tag everything this way. One small remark. The way I understand it we are moving to replacing highway=bus_stop with public_transport=platform. So it should work for that combination of tags as well. And it should be enough that a node contains De Lijn. Some stops are shared with MIVB/STIB, TEC and VEOLIA. These are valid remarks, and show why the configuration file should be crowd sourced. A single developer can never come up with all these exceptions for all these different nations. Jo I looked at the openlinkmap code, and it seems that he's filtering a lot of tags before the file gets imported in a database. The filtering also happens with a program that doesn't allow regex, only wildcards. So reading such a configuration file would be a hell of a job. I think I found something better. We could use the osmosis tagtransform plugin (http://wiki.osm.org/Osmosis/TagTransform). Where we could use a configuration file to transform tags to an url:*= tag. Like the example from De Lijn could be as following: http://pastebin.com/4G4FPyEq(currently writing to url:delijn, but we could also check for the existence of an url tag, and write to that if it's not present). The disadvantages of this tool are that an url tag can only be created from a single other tag (as the discussion page on the wiki says), And a key needs to stay a key, and a value needs to stay a value. Another drawback might be the installation of an extra plugin. It doesn't seem so easy as it should be (version conflicts etc). But it should be very straightforward to use the file afterwards, and to have this file crowd sourced. And, on the positive side, the osmosis team is looking into making this task part of the standard installation. In which case you won't have to install anything new at all. Regards, Sander ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Tag for 'mutualiteiten' ?
On 03/03/2013 10:37 AM, Gilbert Hersschens wrote: Glen, ik vrees dat dit geen goede keuze is. In het Engels is een office in de context van gezondheidszorg de doctor's office en geen kantoor in de klassieke betekenis. Dit blijkt ook uit de omschrijving bij http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0#health_facility:type.3D.2A. Klopt, Maar ik had al zoveel gespamd die dag dat ik het niet had achter gestuurd, uiteindelijk was die idd ook niet erop. Blijkbaar kent de rest van de wereld niet echt de betekenis van een mutualiteit. Uiteindelijk is het maar dit geworden, idioot maar dat past het nog beste bij: name=CM Zemst office=insurance operator=Christelijke Mutualiteit Keep it simple zeker ? Glenn ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Tag for 'mutualiteiten' ?
What about health_insurance? If there is no proper tag yet, it's allowed to add new ones. It's better to do that and document it, than to use one that means something different. Jo Op 3 maart 2013 15:37 schreef Glenn Plas gl...@byte-consult.be het volgende: On 03/03/2013 10:37 AM, Gilbert Hersschens wrote: Glen, ik vrees dat dit geen goede keuze is. In het Engels is een office in de context van gezondheidszorg de doctor's office en geen kantoor in de klassieke betekenis. Dit blijkt ook uit de omschrijving bij http://wiki.openstreetmap.org/**wiki/Proposed_features/** Healthcare_2.0#health_**facility:type.3D.2Ahttp://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0#health_facility:type.3D.2A . Klopt, Maar ik had al zoveel gespamd die dag dat ik het niet had achter gestuurd, uiteindelijk was die idd ook niet erop. Blijkbaar kent de rest van de wereld niet echt de betekenis van een mutualiteit. Uiteindelijk is het maar dit geworden, idioot maar dat past het nog beste bij: name=CM Zemst office=insurance operator=Christelijke Mutualiteit Keep it simple zeker ? Glenn __**_ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-behttp://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] E-laadstations
Nee, de 'niet commercieel' eis is er zeker teveel aan. Als je het wil gebruiken, dan moet je de eigenaars eerst om schriftelijke toestemming vragen. On 3 Mar 2013 15:26, Gilbert Hersschens gherssch...@gmail.com wrote: Mogen we deze gegevens gebruiken ? http://www.oplaadpalen.nl/w/creative-commons/ Gilbert ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] natuurgebieden
Kan iemand de pagina http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area#Protect_classes_for_various_countriesaanvullen voor Belgium? Zodra dit gebeurd is, kan ik Naturschutzgebiet vertalen voor de How_to_map_a. dank bij voorbaat. ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] natuurgebieden
Juiste URL is http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area#Protect_classes_for_various_countries Op 3 maart 2013 20:06 schreef Ivo De Broeck ivo.debro...@gmail.com het volgende: Kan iemand de pagina http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area#Protect_classes_for_various_countriesaanvullen voor Belgium? Zodra dit gebeurd is, kan ik Naturschutzgebiet vertalen voor de How_to_map_a. dank bij voorbaat. ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
Zie inline commentaar. On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: On 02/27/2013 09:34 PM, Gertjan Idema wrote: On Sun, 2013-02-24 at 17:09 +0100, Sebastiaan Couwenberg wrote: Het is niet handig dat de ref:woonplaatscode van Putten is aangepast naar de code in de meest recente BAG zonder ook de geometrie aan te passen. De ref:woonplaatscode/name tuple hoorde bij de geometrie van het record in bag:extract WPL08082012, bij de aangepaste woonplaatscode zit ook een nieuwe geometrie van de woonplaats in bag:extract WPL08012013. Voor Putten er Nijkerk heb ik net ook de geometrie aangepast met de versie uit bag:extract WPL08012013. Ik was me er niet van bewust dat je al zo ver was met de BAG woonplaatsgrenzen. Dat is ook deels mijn schuld, ik heb er geen openbare progress report oid van bijgehouden zoals voor het Woonplaatsbesluiten project is gedaan. http://wiki.openstreetmap.org/wiki/Bestaande_geodata_hergebruiken_woonplaatsbesluiten Het is mijn bedoeling om een dergelijk overzicht te genereren met bijbehorende interactieve kaart voor de grenzen die in OSM geupdate kunnen worden met de meeste recente versie in de BAG. Hier wil ik pas echt goed voor gaan zitten als ik klaar ben met alle woonplaatsgrenzen gelijk trekken met de inmiddels wat oude BAG, maar gezien de woonplaatsen niet zoveel aan verandering onderhevig zijn als de panden vind ik dat niet zo'n probleem. Voordat de grenzen met BAG data geupdate werden was er tijden weinig tot niets aangepast, we zijn er dus op vooruit gegaan qua actualiteit, maar nog niet helemaal volledig up-to-date. In eerste instantie had ik mij ook voorgenomen om de procedure die ik volg bij het toevoegen en updaten van grenzen aan de BAGimport wiki pagina toe te voegen, maar ik twijfelde over het nut ervan. Het toevoegen van grenzen is een redelijk eenmalig proces, daarna zullen de bestaande grenzen aangepast worden. Tenzij er nog nieuwe woonplaatsen in het leven geroepen worden zal al het werk het updaten van bestaande grenzen omvatten. Het is leek mij nuttiger om dat proces te gaan documenteren wanneer alle ontbrekende grenzen waren toegevoegd. Daar is het nu dus wel tijd voor aan het worden, maar ik zal hoogst waarschijnlijk nog even procastinaten. Want ik wil mijn tijd nu nog even in de laatste 484 woonplaatsen steken. Dit lijkt mij inderdaad een eenmalige klus. Zou jammer zijn van je energie om het uitgebreid te documenteren. 2. 'Onlogische' woonplaatsnamen in de BAG: Bij een aantal plaatsen heb ik er voor gekozen om de naam in OSM niet aan te passen aan de officiële BAG namen. In plaats daarvan heb ik de BAG namen in de 'alt_name' tag geplaatst. Aan het lijstje hieronder is denk ik wel te zien waarom. (de tweede naam is de BAG naam): AlteveerAlteveer gem Hoogeveen BotlekBotlek Rotterdam De Hoefde Hoef De Luttede Lutte Den Haag's-Gravenhage De Woudede Woude ElstElst Ut EuropoortEuropoort Rotterdam HoogvlietHoogvliet Rotterdam MaasvlakteMaasvlakte Rotterdam PernisPernis Rotterdam 's-HertogenboschDen Bosch UrsemUrsem gem. S VondelingenplaatVondelingenplaat Rotterdam Ik twijfelde welke tag hiervoor te gebruiken, official_name was misschien ook een optie gezien de Woonplaats als zodanig in de officiele bron staat. Maar alt_name is waarschijnlijk beter. Bij http://wiki.openstreetmap.org/wiki/Key:official_name staat 'It has been created for country names'. Er staat dus niet bij dat het niet voor andere namen gebruikt mag worden. Ik neig er nu toch meer naar om 'official_name' te gaan gebruiken. Zodra we het er over eens zijn, kunnen we dit vermelden in de Nederlandse wiki. Tsja, interpretatie van tags blijft een lastig issue. Wat is de officiële naam van een woonplaats? Dat lijkt mij de naam die op officiële documenten gebruikt word, ik denk niet dat gemeente of provincie hints in de woonplaats naam onderdeel zijn van de officiële naam zoals op briefpapier van het stadsbestuur word gebruikt, op de plaatsnaamborden staat, en wat men in het postadres zou gebruiken. Het lijkt mij deze deze in het verleden zijn toegevoegd zodat om unique contraints in een database gewerkt kon worden, of om simpelweg in de oude kaartenbakken op basis van de naam het onderscheid te kunnen zien. Het hergebruiken van bestaande tags maar deze anders interpreteren voor een nieuw project zorgt voor nodeloze verwarring bij diegenen die bekent zijn met de originele insteek. Om dit te voorkomen kunnen we misschien beter onze eigen tag introduceren zodat we vrij zijn deze te definiëren. Zodoende voel ik er ook wel wat voor om bag:name of bag:woonplaatsnaam te gebruiken voor de naam zoals het in de BAG staat. Deze namespace is vrij voor ons om invulling te geven, en zullen minder snel aangepast worden als de name tag. Ik zie ook liever Alteveer op de kaart dan Alteveer gem
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
On 03/03/2013 06:04 PM, Gertjan Idema wrote: Eén puntje wil ik wel in overweging geven: Als iemand netjes de officiële naam opgeeft in bijvoorbeeld nominatum, dan zou het wel zo prettig zijn als de bijbehorende plaats dan ook wordt gevonden. Op het moment word zelfs zonder het gebruik van de official_name tag voor beide namen vrijwel dezelfde resultaten getoont. Dus daar hoeven we het niet voor te doen. On 03/03/2013 06:04 PM, Gertjan Idema wrote: On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: Huidige status: done: 2000, TODO: 484, Total: 2484 (complete: 80.5152979066023%) Als ik het goed heb, zouden het er 2500 moeten zijn. (2505 woonplaatscodes als je de 'dubbelen' mee telt). Klopt. Ik was Flevoland vergeten in het overzicht. Zuid Holland heb ik vandaag afgemaakt, en daarmee is de huidige status: done: 2152, TODO: 349, Total: 2501 (complete: 86.0455817672931%) On 03/03/2013 06:04 PM, Gertjan Idema wrote: On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: Maar hiermee heb je niet de waterway=river wegen die vaak over grenzen getrokken zijn, en de verschillende highways, buildings e.d. Als je alle mogelijkheden wilt afvangen moet je alle data binnen de boundingbox ophalen en dat is al snel teveel voor een grote stad laat staan een hele gemeente of provincie. Als de rivier de officiële grens is, betwijfel ik of je grens en de rivier moet loskoppelen. Valt wat voor te zeggen. Maar het maakt het editten van boundaries buiten de volledige dataset om wel nodeloos meer werk. Idealiter leven de boundaries in hun eigen layer, omdat ze niet interacteren met de andere data. Ze hoeven niet gekoppeld te zijn voor routing of iets dergelijks. Hekken en degelijke barriers kunnen overlap hebben met boundaries en zouden van dezelfde ways en/of nodes gebruik kunnen maken als een hekwerk is geplaatst om de grens op locatie aan te duiden. Maar kunnen net zo goed los van elkaar staan. In mijn ogen is een administratieve grens een virtuele feature die per definitie losstaat van de features die op de grond kunnen bestaan. Zodoende dient de logische scheiding tussen de features behouden te worden door diens nodes en ways niet te combineren. Wanneer een rivier of andere niet-virtuele feature gebruikt word ter bepaling van een grens dient de logisch scheiding gerespecteerd te worden. Zo kunnen de ways over elkaar getekend worden maar geen nodes te sharen, of mijn voorkeur, teken de waterway en boundary vlak naast elkaar. On 03/03/2013 06:04 PM, Gertjan Idema wrote: On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote: On 02/27/2013 09:34 PM, Gertjan Idema wrote: On Sun, 2013-02-24 at 17:09 +0100, Sebastiaan Couwenberg wrote: Andere klussen: Het gebruik van type=boundary/type=multipolygon nog niet consequent. Volgens de Nederlandse conventie gebruiken we type=multipolygon. Op de internationale site staat echter dat type=multipolygon verouderd is. Dat is nogal verwarrend. Huidige status: multipolygon=2173x, boundary=327x Een van de JOSM ontwikkelaars pushed de standaardisatie naar type=boundary. En als je op basis van de wiki of taginfo beslist hoe te taggen zal type=boundary altijd de voorkeur hebben. Ik kan op zich leven met 'type=boundary' als dit overal behalve in Nederland en Duitsland de standaard is. Dan is het wel zaak om de Nederlandse documentatie hier op aan te passen. Eerst maar eens uitzoeken wat destijds de argumenten voor type=multipolygon waren. Het enige nadeel aan type=boundary is wat mij betreft dat hier standaard een warning voor getoond word in OSMI. Maar omdat deze super eenvoudig uitschakelen is, het dat redelijk een non-argument. Als type=boundary de officiële standaard is, is dat in mijn ogen een bug in OSMI die binnenkort wel verleden tijd zal zijn. Dat zou mooi zijn, maar ik weet het nog niet zo zeker. Het belangrijkste is dat wij documenteren welk type we gebruiken en waarom, en hoe dat afwijkt van bepaalde documentatie, QA tools, e.d. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
Bas, Bij het editten van de grenzen heb je hier een aantal (fiets)paden mede verplaatst: http://www.openstreetmap.org/?lat=52.06349lon=6.07858zoom=17layers=M Die zaten kennelijk aan de grenzen vastgeklikt? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM in RD tiles
Misschien is dit wel de oorzaak:
$ gdalsrsinfo epsg:28992
ERROR 1: gdalsrsinfo was compiled against GDAL 1.9 but current library
version is 1.7
Ik ben laatst van GDAL 1.9 terug gegaan naar GDAL 1.7 omdat Mapnik niet
meer functioneerde. Tijd om weer eens van A tot Z op te schonen en naar
de laatste versies over te stappen.
Groeten,
Peter
Op 2-3-2013 22:24, Gertjan Idema schreef:
Ik heb de indruk dat gdal zelf ook coordinatensystemen bij houdt.
Op mijn systeem vind ik ze op 3 plaatsen:
/usr/share/gdal/1.8
/usr/share/gdal/1.9
/usr/share/gdal16
Geen idee of daar wat mee gedaan wordt.
Wel vond ik een handig commando:
gdalsrsinfo epsg:28992
Bij mij geeft dit:
PROJ.4 : '+proj=sterea +lat_0=52.156160
+lon_0=5.387639 +k=0.079 +x_0=155000 +y_0=463000
+ellps=bessel
+towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725
+units=m +no_defs '
OGC WKT :
PROJCS[Amersfoort / RD New,
GEOGCS[Amersfoort,
DATUM[Amersfoort,
SPHEROID[Bessel 1841,6377397.155,299.1528128,
AUTHORITY[EPSG,7004]],
TOWGS84[565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725],
AUTHORITY[EPSG,6289]],
PRIMEM[Greenwich,0,
AUTHORITY[EPSG,8901]],
UNIT[degree,0.0174532925199433,
AUTHORITY[EPSG,9122]],
AUTHORITY[EPSG,4289]],
PROJECTION[Oblique_Stereographic],
PARAMETER[latitude_of_origin,52.156160],
PARAMETER[central_meridian,5.387639],
PARAMETER[scale_factor,0.079],
PARAMETER[false_easting,155000],
PARAMETER[false_northing,463000],
UNIT[metre,1,
AUTHORITY[EPSG,9001]],
AXIS[X,EAST],
AXIS[Y,NORTH],
AUTHORITY[EPSG,28992]]
Gertjan
On Sat, 2013-03-02 at 22:02 +0100, Peter Peterse wrote:
Hallo,
het is een proj 4.7.1 zelf gebouwd. Een andere versie staat er niet op.
Zoals te zien in mijn eerdere mail bevat deze wel de optie +towgs84=
locate epsg vond enkel dit bestand dat relevant was voor dit issue.
Groeten,
Peter
Op 2-3-2013 21:47, Cartinus schreef:
Hallo,
Staat er niet ook nog een bestand /usr/share/proj/epsg op je computer?
Dat is waar dacht ik de meeste linux distributies het laten. De
standaard packages bevatten meestal versie 4.7.0 (of ouder) van proj en
daarin miste de +towgs84 parameter.
m.v.g.,
Martijn
On 03/02/2013 09:31 PM, Peter Peterse wrote:
Hallo Gertjan,
bedankt voor het antwoord. Het werkt. Zie resultaat
http://osm.peterse-uithuizen.com/~peter/2deMaasvlakte_in_RD_2.png
http://osm.peterse-uithuizen.com/%7Epeter/2deMaasvlakte_in_RD_2.png
Echter begrijp ik het niet. In het bestand /usr/local/share/proj/epsg
van proj zie ik:
28992 +proj=sterea +lat_0=52.156160 +lon_0=5.387639
+k=0.08 +x_0=155000 +y_0=463000 +ellps=bessel +units=m
+towgs84=565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.8703473836068,4.0812
+no_defs no_defs
Deze bevat gelijke waarden als jij in het forum noemt.
Een andere schuldige kan ik zo niet vinden.
Nogmaals bedankt,
Peter
Op 2-3-2013 12:52, Gertjan Idema schreef:
Hallo Peter,
Het lijkt er op de projectie parameters voor RD niet compleet zijn.
Dat geeft een afwijking van zo'n 100m naar het zuid-zuidwesten. In het
volgende forum artikel onder #7 vind je een mogelijke work-around:
forum.openstreetmap.org/viewtopic.php?id=12204
Laat even weten of het werkt.
Groeten, Gertjan
On Fri, 2013-03-01 at 16:45 +0100, Peter Peterse wrote:
Hallo allemaal,
ik probeer de 2de maasvlakte in RD tiles weer te geven. Echter zie ik
een
verschil t.o.v. de officiele site:
http://www.openstreetmap.org/?lat=51.9777lon=4.001zoom=14layers=M
Een screenshot van mijn lokale server is te vinden op:
http://osm.peterse-uithuizen.com/~peter/2deMaasvlakte_in_RD.png
http://osm.peterse-uithuizen.com/%7Epeter/2deMaasvlakte_in_RD.png
http://osm.peterse-uithuizen.com/%7Epeter/2deMaasvlakte_in_RD.png
Tussen de weg en het strand bevind zich bij mij water. Ik heb de
world_boundaries bijgewerkt en geherprojecteerd met de commando's:
extent=225743.58199723 6343505.39917919 816703.80429861
7125169.31386459
ogr2ogr -f ESRI Shapefile -s_srs EPSG:900913 -t_srs EPSG:${srs} \
-spat ${extent} builtup_area_28992.shp builtup_area.shp
ogr2ogr -f ESRI Shapefile -s_srs EPSG:900913 -t_srs EPSG:${srs} \
-spat ${extent} processed_p_28992.shp processed_p.shp
ogr2ogr -f ESRI Shapefile -s_srs EPSG:900913 -t_srs EPSG:${srs} \
-spat ${extent} shoreline_300_28992.shp
shoreline_300.shp
Heeft iemand een idee wat er mis kan zijn?
Alvast bedankt,
Peter
___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
On 03/03/2013 07:47 PM, Minko wrote: Bas, Bij het editten van de grenzen heb je hier een aantal (fiets)paden mede verplaatst: http://www.openstreetmap.org/?lat=52.06349lon=6.07858zoom=17layers=M Die zaten kennelijk aan de grenzen vastgeklikt? Dat klopt. Ik ben er nog niet aan toegekomen om alle grenzen die ik heb aangepast te controleren op dit soort zaken. Mvg, Bas -- GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old) ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)
Ok, ik heb de situatie daar weer hersteld. Die zaten kennelijk aan de grenzen vastgeklikt? Dat klopt. Ik ben er nog niet aan toegekomen om alle grenzen die ik heb aangepast te controleren op dit soort zaken. Mvg, Bas ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-br] mapas do IBGE e JOSM/PicLayer
oi, Aun! On 08-01-2013 21:50, Aun Yngve Johnsen wrote: Algumas perguntas, Os pdf's sao georeferenciadas? Como abrir em JOSM? Para abrir no JOSM, converta o mapa para jpg: convert -density 300 mapa.pdf mapa.jpg e use o plugin PicLayer Não tem computador disponivel este semana Aun Johnsen On 8. jan. 2013, at 22:45, Wille wi...@wille.blog.br mailto:wi...@wille.blog.br wrote: Encontrei novamente no site do IBGE os mapas de 2007 com numa escala que nos permite consultar os nomes das ruas de cidades de todo o Brasil: ftp://geoftp.ibge.gov.br/mapas_estatisticos/censo_2007/mapa_urbano_estatistico/ abçs, wille On 05-10-2012 13:31, Wille wrote: Valeu, Gerard! Porém os da Bahia continuam com o mesmo problema, veja um exemplo: ftp://geoftp.ibge.gov.br/mapas_estatisticos/censo_2010/mapa_municipal_estatistico/ba/brumado_v2.pdf On 05-10-2012 12:26, Gerald Weber wrote: Dê uma olhada nos mapas v2 ftp://geoftp.ibge.gov.br/mapas_estatisticos/censo_2010/mapa_municipal_estatistico/mg parecem ser bem mais detalhados abraço Gerald 2012/10/5 Wille wi...@wille.blog.br mailto:wi...@wille.blog.br Dei uma olhada nos mapas, mas os daqui da Bahia mostram apenas o entorno das cidades. Não vão ser muito úteis... On 20-09-2012 22:05, Wille wrote: Massa, Arlindo! Depois vou contribuir com alguns arquivos. abraços, On 19-09-2012 17:43, Arlindo Pereira wrote: Criei o repositório no GitHub: https://github.com/nighto/calibracao-mapas-ibge Gerald (e demais), você pode colocar lá (ou me passar) os arquivos .cal referente aos arquivos que você já fez? []s 2012/9/19 George Silva georger.si...@gmail.com mailto:georger.si...@gmail.com Arlindo e demais... Geralmente fico só nos bizus na lista, mas não acho que seja o ideal duplicar a informação, portanto, aqui vai uma sugestã: Deixe que o IBGE se preocupe com o armazenamento dos dados por enquanto. Abra o repositório no github e faça um link através da wiki do git. É menos trabalhoso :D. Abraços 2012/9/19 Arlindo Pereira openstreet...@arlindopereira.com mailto:openstreet...@arlindopereira.com Wille e demais, que tal criarmos um repositório no GitHub com os mapas do IBGE e seus respectivos arquivos de calibração? []s 2012/9/18 Wille wi...@wille.blog.br mailto:wi...@wille.blog.br Olá, Gerald Tenho usado essa técnica, porém eu não sabia desse endereço novo dos mapas no site IBGE e não estava encontrando mais os mapas. Valeu por postar aqui! Muito bom também essa linha de comando do convert! On 18-09-2012 18:32, Gerald Weber wrote: Olá eu não sei vocês, mas eu sempre tive dificuldade em fazer uso dos mapas em pdf do IBGE (http://www.ibge.gov.br/mapas_ibge/bases_municipais.php). Uma solução que achei para isto foi usar um plugin do JOSM chamado PicLayer. Vou passar a receita que estou usando aqui, não sei se é do conhecimento de vocês. No JOSM, selecione editar/preferências e instale o plugin PicLayer. Baixe o mapa em pdf do seu interesse. Eu faço a conversão do pdf para jpg no linux da seguinte maneira (linha de comando) convert -density 300 mapa.pdf mapa.jpg o argumento -density 300 garante que as letras do mapa do IBGE continuem visíveis no JOSM. Se o mapa em pdf tiver mais de uma página ele geralmente cria os arquivos assim: mapa-0.jpg, mapa-1.jpg etc. O convert é um pacote do ImageMagic. No JOSM, posicione as coordenadas mais ou menos na região de onde seria o mapa, selecione a aba PicLayer e carrege o mapa.jpg. Agora vem a parte mais chatinha que é calibrar o mapa. Como os mapas do IBGE vem com as latitudes/longitudes dá para marcar os pontos e arrastá-los. Requer um pouquinho de prática, mas uma vez que está feito ele salva a calibração num arquivo mapa.jpg.cal e fica pronto. No site do PicLayer tem um tutorial de como isto é feito (http://wiki.openstreetmap.org/wiki/JOSM/Plugins/PicLayer). Agora uma pergunta: a gente teria algum lugar onde
Re: [Talk-is] Nýjar BING gervihnattamyndir
Hæ. Þetta gætu verið mistök þar sem loftmyndin hefur mögulega verið leiðrétt á rangan hátt eða alls ekki. Loftmyndir ehf. ræðir um þessa bjögun á http://3w.loftmyndir.is/index.php?option=com_contenttask=viewid=71Itemid=60 . Áhrifin eru mest, skv. síðunni, á svæðum með miklum hæðamismun eða vegna linsubjögunar. Persónulega myndi ég frekar treysta gögnum Vegagerðarinnar þar sem þau eru (líklegast) frá lágflugsmyndum og örugglega uppréttaðar. Með kveðju, Svavar Kjarrval On 03/03/13 19:07, Bjarki Sigursveinsson wrote: Halló, Ég hef verið að skoða nýju Bing myndirnar á Vestfjörðum auka nákvæmni kortagagnanna út frá þeim. Ég tók hins vegar eftir skekkju sem ég veit ekki hvernig best er að leysa úr. Í Breiðadal við Önundarfjörð (hér: http://www.openstreetmap.org/?lat=66.02713lon=-23.34796zoom=15layers=M) víkur staðsetning vegarins samkvæmt loftmyndinni talsvert frá þeim gögnum sem fyrir eru í grunninum. Sú staðsetning er fengin frá nokkuð mörgum GPS-slóðum sem virðast sammála um legu vegarins. Auk þess er staðsetning gangamunnans í dalnum samkvæmt gögnunum sem Vegagerðin gaf okkur í ágætu samræmi við veginn eins og hann er fyrir en passar ekki við Bing-myndina. Hinir gangamunnar Vestfjarðaganganna eru inni á sömu Bing-myndinni og þar eru bæði GPS-slóðir og gögn Vegagerðarinnar mun nær myndinni. Ég sendi skjáskot úr JOSM með póstinum þar sem vandamálið sést. Grænu slóðirnar eru GPS og rauða línan sem er valin sýnir legu Vestfjarðaganga samkvæmt gögnum Vegagerðar. Mér dettur í hug að þetta geti tengst því að þetta er í þröngum dal innan um há fjöll sem bjagi allar GPS-mælingar á sama hátt. Varla getur myndin verið að ljúga? kv. Bjarki On 2.3.2013 19:03, Svavar Kjarrval wrote: Hæ. Var að fá fregnir frá Moritz (MisterKanister) að það eru komin ný landsvæði inn á BING gervihnattamyndirnar. Endilega athugið uppáhaldssvæðið ykkar og setjið inn húslínur, réttið af vegi, og svo framvegis. Með kveðju, Svavar Kjarrval ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is -- Bjarki Sigursveinsson +354 8215644 Mánagötu 8 105 Reykjavík Iceland ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is signature.asc Description: OpenPGP digital signature ___ Talk-is mailing list Talk-is@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-is
Re: [Talk-de] Admin-Grenzen exportieren als Shapefiles
Hallo Marian, Konkret interessiere ich mich gerade für die Landkreise (und kreisfreie Städte) in NRW, demnächst möchte ich dies für ganz Deutschland zusammen tragen. Mit der Overpass API kannst Du die Grenzen mit http://overpass-api.de/api/interpreter?data=area[name=Nordrhein- Westfalen];rel(area)[admin_level=6];(._;;);out; bekommen. Mehr zum Thema Konvertierung von OSM XML nach SHP gibt es bei http://wiki.openstreetmap.org/wiki/Shapefiles#Obtaining_shapefiles_from_OSM_data Damit habe ich bisher allerdings noch nicht gearbeitet. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Admin-Grenzen exportieren als Shapefiles
Hallo, das auf GeoJson basierende TopoJson bietet übrigens genau diese Reduzierung der Komplexität, auf die du aus bist: https://github.com/mbostock/topojson Wenn ich es richtig verstanden habe ;-) Grüße Ralf Am 02.03.2013 18:46, schrieb Marian Steinbach: Guten Tag! Sicherlich machen das viele von Euch andauernd. Ich kann nur leider keine gute Anleitung finden, wie ich selbst recht mühelos bestimmte Grenzen aus den OSM-Daten beispielsweise als ESRI Shapefile extrahiere. Konkret interessiere ich mich gerade für die Landkreise (und kreisfreie Städte) in NRW, demnächst möchte ich dies für ganz Deutschland zusammen tragen. Die Geofabrik SHP-Exporte scheinen die Admingrenzen nicht zu enthalten. Als Endprodukt interessiert mich übrigens nicht SHP, sondern SVG. Aus SHP kann ich jedoch selbst SVG erzeugen. Und ich bin darauf aus, mittels Map Shaper (http://mapshaper.com/test/MapShaper.swf) die Komplexität von aneinander grenzenden Polygonen zu reduzieren, denn ich brauche nur einen geringen Detailgrad und und Map Shaper liest nur SHP. (Möglich, dass ich das auch z.B. mit QGis auf Basis anderer Datenquellen machen könnte. Für Hinweise bin ich dankbar.) Welche Tools könnten mir denn helfen, admin-boundaries für ein ganzes Bundesland zu exportieren? Oder schreibt man sich sowas schnell selbst, z.B. mit der Overpass API? Vielen Dank! Marian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] MasterCity im PlayStore
On Sat, 23 Feb 2013 16:20:40 +0100 Mario Danelli mario.dane...@gmail.com wrote this: I'm not a native. Sorry, you are on the wrong mailing list. This is 'Talk-de'. 'Talk-de' is for German talk only. If you want English talk, go to the 'talk' mailing-list. We have a large English-speaking community. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Cucina nei bar
Ciao a tutti. Sto inserendo il tag cuisine = * in alcuni bar, in quanto oltre al servizio classico di somministrazione bevande, hanno anche la funzione di ristorazione. Credevo di inserire cuisine=yes ma il wiki non lo prevede, almeno mi pare. Sarebbe meglio inserire cuisine=italian in mancanza di cucina tipica? Grazie. -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Fwd: [OSM-FVG] Invito a presentare OSM al Linux Arena c/o Fiera Radioamatore Pn
Il 02 marzo 2013 22:46, Damjan Gerl dam...@damjan.net ha scritto: Giro la mail anche sulla lista OSM nazionale, che forse è più letta e forse qualcuno avrebbe piacere a collaborare. mi sembra una buona occasione per pubblicizzare OSM, spero che qualcuno ci vada Saluti Damjan G. -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-se] Träff i Göteborg
Hej! Jag är också på skidresa då, men ses gärna vid annat tillfälle. Mvh, Martin 2 mar 2013 kl. 18:41 skrev Erik Lundin e...@lists.lun.nu: Hej, Det hade varit skoj! Tyvärr är jag på skidresa nästa helg, så det passar dåligt. Hoppas på fler tillfällen! Mvh Erik 2013-03-02 14:50, Tobias Johansson skrev: Hej Jag funderade på att försöka dra ihop något i Göteborg nästa söndag? Mest som en social grej och försöka lära känna varandra. Hade tänkt mig att träffas på någon pub eller café på eftermiddagen, pub kanske är bäst så kan man äta något samtidigt. Ge gärna förslag. Om ni vill men inte kan svara gärna och när ni skulle kunna. Jag har även sett att det funnits en del nya som börjat mappa i Göteborg. Eftersom de antagligen inte finns med på denna lista tänkte jag även sicka en inbjudan via OSM-mail (så skriv gärna erat alias om ni svarar och inte vill ha ett mail även på osm :) ). MvH Tobias ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se
[Talk-es] Rutas de transporte
Hola. Tenia medio puestas las rutas de bus de Salamanca y aprovechando que van hacer ahora un cambio bastante grande las estoy poniendo todas con las nuevas rutas y paradas y todas esas cosas. Aunque no sea obligatorio pero según dicen es lo mas correcto estoy siguiendo lo que pone en http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport. Por ahora he puesto las rutas de todas las lineas creo que correctamente y estoy ahora con las paradas. He puesto una para probar, que creo que esta bien, pero si alguien ya a estado haciendolo me gustaría que me lo confirmara para no tener que cambiarlo cuando tenga puestas muchas paradas. Es un tanto lioso hasta que le coges el truquillo. La parada es esta relación http://www.openstreetmap.org/browse/relation/2798038 que tiene la plataforma, la parada en la carretera y esta añadida a las relaciones de las rutas de bus que usan la parada. Un saludo -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Rutas de transporte
Sin mirar muy en detalle los cambios que has hecho/pretendes hacer... Sí, si pretendes rehacer/crear desde cero las líneas de transporte, usa directamente el esquema nuevo. El antiguo sólo se debería mantener por compatibilidad hacia atrás. Sí que es cierto que el nuevo sistema, al ser más detallado, es más arduo de introducir. Lo que no entiendo es por qué has creado la relación sólo para las paradas. Para 2 nodos los vería innecesario (creo que está pensado más bien para, por ejemplo, estaciones de metro con 10 salidas). El día 3 de marzo de 2013 15:38, Jorge Sanz Sanfructuoso sanc...@gmail.com escribió: Hola. Tenia medio puestas las rutas de bus de Salamanca y aprovechando que van hacer ahora un cambio bastante grande las estoy poniendo todas con las nuevas rutas y paradas y todas esas cosas. Aunque no sea obligatorio pero según dicen es lo mas correcto estoy siguiendo lo que pone en http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport. Por ahora he puesto las rutas de todas las lineas creo que correctamente y estoy ahora con las paradas. He puesto una para probar, que creo que esta bien, pero si alguien ya a estado haciendolo me gustaría que me lo confirmara para no tener que cambiarlo cuando tenga puestas muchas paradas. Es un tanto lioso hasta que le coges el truquillo. La parada es esta relación http://www.openstreetmap.org/browse/relation/2798038 que tiene la plataforma, la parada en la carretera y esta añadida a las relaciones de las rutas de bus que usan la parada. Un saludo -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Rutas de transporte
El 3 de marzo de 2013 17:39, Jaime Crespo jy...@jynus.com escribió: Sin mirar muy en detalle los cambios que has hecho/pretendes hacer... Sí, si pretendes rehacer/crear desde cero las líneas de transporte, usa directamente el esquema nuevo. El antiguo sólo se debería mantener por compatibilidad hacia atrás. Sí que es cierto que el nuevo sistema, al ser más detallado, es más arduo de introducir. Esa era la idea. Menos las paradas que lo que había lo he dejado todavía con lo antiguo, lo demás ya lo he creado con las 2 rutas de cada dirección y con el route_master. Tiene sus partes buenas y malas. Prefiero hacer 2 rutas, una de cada dirección que andar poniendo la dirección en la que pasaba en cada vía. Lo que no entiendo es por qué has creado la relación sólo para las paradas. Para 2 nodos los vería innecesario (creo que está pensado más bien para, por ejemplo, estaciones de metro con 10 salidas). Como en uno de los ejemplos que vienen es solo con los 2 nodos por eso lo hecho aunque veo entonces mucho trabajo por delante. Ahora que lo comentas me sale otra duda de esto. En salamanca solo tenemos el bus urbano y luego la estación de autobuses y de tren. En una plaza grande que tiene varias paradas de diferentes lineas que puede que este cada parada en un lado de la plaza ¿habría que hacer esta relación con todas las parada? Y en el caso de la estación de tren que tiene una parada de bus fuera también ¿habría que hacer una relación conjunta? Mucha información y encima en ingles que no se me da exactamente bien que digamos. El día 3 de marzo de 2013 15:38, Jorge Sanz Sanfructuoso sanc...@gmail.com escribió: Hola. Tenia medio puestas las rutas de bus de Salamanca y aprovechando que van hacer ahora un cambio bastante grande las estoy poniendo todas con las nuevas rutas y paradas y todas esas cosas. Aunque no sea obligatorio pero según dicen es lo mas correcto estoy siguiendo lo que pone en http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport. Por ahora he puesto las rutas de todas las lineas creo que correctamente y estoy ahora con las paradas. He puesto una para probar, que creo que esta bien, pero si alguien ya a estado haciendolo me gustaría que me lo confirmara para no tener que cambiarlo cuando tenga puestas muchas paradas. Es un tanto lioso hasta que le coges el truquillo. La parada es esta relación http://www.openstreetmap.org/browse/relation/2798038 que tiene la plataforma, la parada en la carretera y esta añadida a las relaciones de las rutas de bus que usan la parada. Un saludo -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Rutas de transporte
Que responda más gente, pero creo que la idea es trabajar lo menos posible si ya queda claro. Sobre todo si eso implica crear demasiadas relaciones. Nadie que conozca, por ejemplo, mapea la relación portales-calle. -- Jaime Crespo On Mar 3, 2013 6:32 PM, Jorge Sanz Sanfructuoso sanc...@gmail.com wrote: El 3 de marzo de 2013 17:39, Jaime Crespo jy...@jynus.com escribió: Sin mirar muy en detalle los cambios que has hecho/pretendes hacer... Sí, si pretendes rehacer/crear desde cero las líneas de transporte, usa directamente el esquema nuevo. El antiguo sólo se debería mantener por compatibilidad hacia atrás. Sí que es cierto que el nuevo sistema, al ser más detallado, es más arduo de introducir. Esa era la idea. Menos las paradas que lo que había lo he dejado todavía con lo antiguo, lo demás ya lo he creado con las 2 rutas de cada dirección y con el route_master. Tiene sus partes buenas y malas. Prefiero hacer 2 rutas, una de cada dirección que andar poniendo la dirección en la que pasaba en cada vía. Lo que no entiendo es por qué has creado la relación sólo para las paradas. Para 2 nodos los vería innecesario (creo que está pensado más bien para, por ejemplo, estaciones de metro con 10 salidas). Como en uno de los ejemplos que vienen es solo con los 2 nodos por eso lo hecho aunque veo entonces mucho trabajo por delante. Ahora que lo comentas me sale otra duda de esto. En salamanca solo tenemos el bus urbano y luego la estación de autobuses y de tren. En una plaza grande que tiene varias paradas de diferentes lineas que puede que este cada parada en un lado de la plaza ¿habría que hacer esta relación con todas las parada? Y en el caso de la estación de tren que tiene una parada de bus fuera también ¿habría que hacer una relación conjunta? Mucha información y encima en ingles que no se me da exactamente bien que digamos. El día 3 de marzo de 2013 15:38, Jorge Sanz Sanfructuoso sanc...@gmail.com escribió: Hola. Tenia medio puestas las rutas de bus de Salamanca y aprovechando que van hacer ahora un cambio bastante grande las estoy poniendo todas con las nuevas rutas y paradas y todas esas cosas. Aunque no sea obligatorio pero según dicen es lo mas correcto estoy siguiendo lo que pone en http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport. Por ahora he puesto las rutas de todas las lineas creo que correctamente y estoy ahora con las paradas. He puesto una para probar, que creo que esta bien, pero si alguien ya a estado haciendolo me gustaría que me lo confirmara para no tener que cambiarlo cuando tenga puestas muchas paradas. Es un tanto lioso hasta que le coges el truquillo. La parada es esta relación http://www.openstreetmap.org/browse/relation/2798038 que tiene la plataforma, la parada en la carretera y esta añadida a las relaciones de las rutas de bus que usan la parada. Un saludo -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jaime Crespo ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-at] S; Javascript Framework, um lokale .osm-Dateien darzustellen
Hallo! Ich helfe mit, um ein Kunstprojekt[1], das mit Papierkarten[2] gestaltet wurde, zu digitalisieren und als Slippy Map zur Verfügung zu stellen. Wir sind gerade dabei, die Icons nach Tags klassifiziert in lokale .osm.xml-Dateien einzutragen. Diese sollen dann in einer Slippy Map dargestellt werden. Ich kenne das so ähnlich mit KML[3], würde aber für jeden Punkt gerne ein eigenes Icon haben (Dateiname entspricht Wert eines Tags), sowie wie bei dem KML-Beispiel ein Foto im Popup anzeigen. Kennt jemand ein JavaScript-Framework, bei dem das einfach mit .osm-Dateien geht? Danke, lg Michi [1] http://demograzya.mur.at/ [2] http://s8472.dyndns.org/photos/2012/demograzya/ [3] http://openlayers.org/dev/examples/sundials-spherical-mercator.html -- 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 http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] S; Javascript Framework, um lokale .osm-Dateien darzustellen
Hallo! On Sun, 2013-03-03 at 13:55 +0100, Michael Maier wrote: Ich helfe mit, um ein Kunstprojekt[1], das mit Papierkarten[2] gestaltet wurde, zu digitalisieren und als Slippy Map zur Verfügung zu stellen. Verstehe ich das richtig, dass ihr POIs auf einer Slippy Map darstellen wollt und die POIs nicht auf der OSM-Datenbank abgefragt werden sollen? Warum habt ihr euch für lokale OSM-Dateien entschieden? Eine POI-Karte lässt sich beispielsweise mit Leaflet recht einfach realisieren [LL-Tutorial]. Die einzelnen POIs ließen sich beispielsweise serverseitig entsprechend aufbereitet via jQuery asynchron nachladen. Bei konkreteren Informationen kann ich das gerne noch etwas genauer beschreiben. Grüße Simon [LL-Tutorial] http://leafletjs.com/examples/custom-icons.html ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-cu] mapeando Cub
Estimado Hedel, pregúntale directamente a PB, el te actualizará sobre el estado de OpenStreetMap para Cuba. Saludos WQB El domingo, 3 de marzo de 2013, Hédel Nuñez Bolívar escribió: Hace unos días conocí de la existencia de OpenStreetMap. He mapeado un poco, sobre todo en la zona de La Habana, pero ahora descubrí también esta lista de distribución, así que me gustaría saber si hay algún plan concreto, alguna tarea, o lo que sea en lo que pueda colaborar. Saludos Hédel Nuñez ___ Talk-cu mailing list Talk-cu@openstreetmap.org javascript:; http://lists.openstreetmap.org/listinfo/talk-cu ___ Talk-cu mailing list Talk-cu@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cu
Re: [Talk-cu] mapeando Cub
Hola Walfrido, gracias por la respuesta tan rápida :) Disculpe el desconocimiento, es que soy realmente nuevo con OSM, pero quien es PB? persona, es un foro? gracias de antemano Sds H On Mar 3, 2013, at 7:23 PM, Walfrido Sebastian Quiñones Bencomo walfridoquino...@gmail.com wrote: Estimado Hedel, pregúntale directamente a PB, el te actualizará sobre el estado de OpenStreetMap para Cuba. Saludos WQB El domingo, 3 de marzo de 2013, Hédel Nuñez Bolívar escribió: Hace unos días conocí de la existencia de OpenStreetMap. He mapeado un poco, sobre todo en la zona de La Habana, pero ahora descubrí también esta lista de distribución, así que me gustaría saber si hay algún plan concreto, alguna tarea, o lo que sea en lo que pueda colaborar. Saludos Hédel Nuñez ___ Talk-cu mailing list Talk-cu@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cu ___ Talk-cu mailing list Talk-cu@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cu ___ Talk-cu mailing list Talk-cu@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cu
Re: [Talk-ca] Montréal v. Toronto :-)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Le 13-03-02 04:40 PM, Richard Weait a écrit : Which Montréal-based OpenStreetMap contributors and developers will be coming to Toronto for the Hack Weekend (and to mock the Maple Leafs) ? It's only a quick trip along the autoroute. Please pass the Hack Weekend details along to your local groups of potentially-interested developers. Hey. Ottawa too. http://wiki.openstreetmap.org/wiki/Toronto_Hack_Weekend_March_2013 http://www.meetup.com/OpenStreetMap-Toronto/ Thanks for the nth reminder :) I've forwarded this to several places, hopefully it will reach more people around Montreal. F. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: PGP/Mime available upon request Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlEzSnIACgkQfUcTXFrypNWvMgCgk59zjYXhD57Z3VeJaoOUhexu tR0AoNQ0lmX/OAH5IePyUiq5JiHxewrb =R3oA -END PGP SIGNATURE- ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Licence de données ouvertes, Montréal
On Sat, Mar 2, 2013 at 3:58 PM, Paul Norman penor...@mac.com wrote: Lastly, cadastral data is probably the least exciting type of data for OSM. Other data like roads, addresses and even buildings is more useful. Oh, I thought cadastral data would include building outlines? At least that's the case with the somewhat controversial French cadastre imports. Did I get excited prematurely? Cheers, Harald. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Licence de données ouvertes, Montréal
Harald, It seems that these are property only an not house plans. But this can surely help for contiguous houses where it is hard to delimit. See U. of McGill description http://www.mcgill.ca/library/library-findinfo/maps/cadast There is also the landuse file See U. of McGill description http://www.mcgill.ca/library/library-findinfo/maps/occupsol The Geomatic service of city of Montreal already provides for research the cadastral plans (1 : 500) and landuse plans (1 : 1000). Laval city has an online map with cadastral plan and ortophoto. Bluffing when you zoom-in and see street level plans. We see both property and building delimitations. Plus other infos. see http://www.info.ville.laval.qc.ca/geomatique/citoyens/viewer.htm?Service=Citoyens_hv Communaute urbaine of Montreal (The great Montreal) also have orthophotos. I think that it would be worth looking more closely at this, see what is usefull and find solutions on how to exploit this information. Pierre De : Harald Kliems kli...@gmail.com À : Paul Norman penor...@mac.com Cc : Pierre Béland pierz...@yahoo.fr; talk-ca talk-ca@openstreetmap.org Envoyé le : Dimanche 3 mars 2013 10h28 Objet : Re: [Talk-ca] Licence de données ouvertes, Montréal On Sat, Mar 2, 2013 at 3:58 PM, Paul Norman penor...@mac.com wrote: Lastly, cadastral data is probably the least exciting type of data for OSM. Other data like roads, addresses and even buildings is more useful. Oh, I thought cadastral data would include building outlines? At least that's the case with the somewhat controversial French cadastre imports. Did I get excited prematurely? Cheers, Harald. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Master City: Let's play with OpenStreetMap
Dear Fabian, Has this been released as free open source software ? I just developed app versions for single countries (at the moment Italy, Germany and France) with more cities (about 1000 for every country), more detailed zoom level and a bonus level (very difficult). I'll publish this versions of the app the next week. I think could be interesting to release this version (one of three) as base source that everyboy can enhance and customize with proper data/tiles for a specific country. In case which are the sources that I have to share? With which license? Must I have to sign the sources (with a specific header or others)? Please, explain me in detail my rights/constraints? Thanks. Mario Danelli ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] New Bing imagery in Montreal
Hey everyone, I've just noticed that the Bing aerial imagery in my neighborhood has changed. We used to have pretty good images but they were from 2007. While doing some edits I noticed that the quality suddenly has gotten much worse and looking at the tile info it now shows that the imagery is from 2011. It seems to be only small patches, however, as you can see if you download this area in JOSM and look at the imagery http://osm.org/go/cIrM_9DE1-- I'm reasonably sure that this was not the case up until two weeks ago. Anybody else notice any Bing changes in their areas? Harald. -- Please use encrypted communication whenever possible! Key-ID: 0x34cb93972f186565 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] New Bing imagery in Montreal
Oh, nevermind. This appears to depend on the zoom level. If you zoom in further you still get the good 2006/2007 pictures. Nonetheless I think the 2011 data must have been added fairly recently. Harald. On Sun, Mar 3, 2013 at 12:43 PM, Harald Kliems kli...@gmail.com wrote: Hey everyone, I've just noticed that the Bing aerial imagery in my neighborhood has changed. We used to have pretty good images but they were from 2007. While doing some edits I noticed that the quality suddenly has gotten much worse and looking at the tile info it now shows that the imagery is from 2011. It seems to be only small patches, however, as you can see if you download this area in JOSM and look at the imagery http://osm.org/go/cIrM_9DE1-- I'm reasonably sure that this was not the case up until two weeks ago. Anybody else notice any Bing changes in their areas? Harald. -- Please use encrypted communication whenever possible! Key-ID: 0x34cb93972f186565 -- Please use encrypted communication whenever possible! Key-ID: 0x34cb93972f186565 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] New Bing imagery in Montreal
You are lucky then. Just the other day Saint John area got updated with stuff from late 2012. its great that they are getting around to updating it but the imagery is more oblique than vertical making it very difficult to trace. As well they are really low quality compared to their predecessors. The new ones are faded out where the old ones were sharp and colourful. These look like an instagrammer got at them! On Sun, Mar 3, 2013 at 1:44 PM, Harald Kliems kli...@gmail.com wrote: Oh, nevermind. This appears to depend on the zoom level. If you zoom in further you still get the good 2006/2007 pictures. Nonetheless I think the 2011 data must have been added fairly recently. Harald. On Sun, Mar 3, 2013 at 12:43 PM, Harald Kliems kli...@gmail.com wrote: Hey everyone, I've just noticed that the Bing aerial imagery in my neighborhood has changed. We used to have pretty good images but they were from 2007. While doing some edits I noticed that the quality suddenly has gotten much worse and looking at the tile info it now shows that the imagery is from 2011. It seems to be only small patches, however, as you can see if you download this area in JOSM and look at the imagery http://osm.org/go/cIrM_9DE1-- I'm reasonably sure that this was not the case up until two weeks ago. Anybody else notice any Bing changes in their areas? Harald. -- Please use encrypted communication whenever possible! Key-ID: 0x34cb93972f186565 -- Please use encrypted communication whenever possible! Key-ID: 0x34cb93972f186565 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] New Bing imagery in Montreal
With the new Montreal open data, perhaps they have aerial photography they can release? Or perhaps they already have, but I couldn't find any. If someone can get it, I can host it. From: nicholas ingalls [mailto:nicholas.inga...@gmail.com] Sent: Sunday, March 03, 2013 11:18 AM To: Harald Kliems; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] New Bing imagery in Montreal You are lucky then. Just the other day Saint John area got updated with stuff from late 2012. its great that they are getting around to updating it but the imagery is more oblique than vertical making it very difficult to trace. As well they are really low quality compared to their predecessors. The new ones are faded out where the old ones were sharp and colourful. These look like an instagrammer got at them! ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Licence de données ouvertes, Montréal
From: Harald Kliems [mailto:kli...@gmail.com] Sent: Sunday, March 03, 2013 7:28 AM Subject: Re: [Talk-ca] Licence de données ouvertes, Montréal On Sat, Mar 2, 2013 at 3:58 PM, Paul Norman penor...@mac.com wrote: Lastly, cadastral data is probably the least exciting type of data for OSM. Other data like roads, addresses and even buildings is more useful. Oh, I thought cadastral data would include building outlines? At least that's the case with the somewhat controversial French cadastre imports. Did I get excited prematurely? The exact definition varies, but the generally accepted definition in North America is the zoning, tax or property lot information. It does not include buildings, roads, waterways, sewer infrastructure, etc. It does not generally contain addresses because there is not a one to one relationship between cadastral areas and addresses. I was talking with several people last week about an integrated cadastral fabric for BC. Cadastral information is actually fairly useful as open data, but most people who would want to use it would be forced to get it from the city anyways. There can be some information useful to OSM in it, but generally most of the information is not relevant to us. I tried extracting useful information from Surrey's cadastral layer and found it a lot of work. I did a presentation on open data and OSM to an audience with many open data publishers and I ranked the most useful data as orthophotos, addresses and roads. Orthos because good ones are hard or expensive to get and cities often have excellent ones. Addresses because they're useful for geocoding, annoying to collect manually, and well suited to conflating with existing data. Roads because the road network is generally considered to be one of the most important parts of OSM, so even if the roads are only marginally better than CanVec they can still be useful. ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Out of date or incomplete NRCan-CanVec-7.0 data
On Sat, Mar 2, 2013 at 6:38 PM, Tony Toews t...@tonytoews.com wrote: I'm just a casual editor who cleans up things I know first hand in a few small towns and a small city.So I went to Landmark, Manitoba and saw an interesting, irregularly shaped out-of-date/incomplete polygon that was added. I don't recall seeing it when I last visited there several months ago but who knows. Residential Area - Source - NRCan-CanVec-7.0 This appears to display a shaded area on the user viewable map. Follow the links to dig deeper into the information available. http://www.openstreetmap.org/browse/way/106216638 The problem is that this is very much out of date or incomplete. Furthermore, for that village/hamlet it's mostly nonsense. Main street, which is the highway running north/south through Landmark is the commercial/industrial road through town although there are houses interspersed among the retail and commercial buildings and feed mill. Furthermore the residential area goes 1.5 blocks west and a few blocks east. So it might as well not even exist. Or you could update it to reflect reality. It is difficult to ensure that every landuse is perfectly represented, but it can be done. In Sherwood Park the residential areas are mapped out, but sometimes the corner store is sitting in a residential landuse, rather than being in a commercial landuse area. Should we delete all landuse polygons because some aren't perfect? Now judging on my memories of that village/hamlet it is probably at least ten years out of date. Fix it today and tomorrow it will only be one day out of date. Ten years from now someone else will be able to complain about it being 10 years out of date! :) Does it serve any useful purpose? Define useful purpose. When you zoom out and look at Winnipeg, do the various coloured areas provide you with any information? Is it safe to delete that polygon or will it come back on some re-import in the future. Would it be better to remove all the inaccurate information from OSM, or to correct/update the inaccurate information? If you look at the history, the polygon was imported by sammuell from CanVec in an effort to correct data provided by vreimer. vreimer was a very prolific OSM user that touched a great deal of the OSM database. Much of the information provided by vreimer was looked upon by locals as being of dubious quality. All attempts to contact vreimer failed, and when a block was put on the account, vreimer disappeared. During the licence change, we lost a lot of valid data that vreimer had touched, and we are still working to replace much of that data to this day. So, delete the information, and someone else *may* come by and replace what you deleted. Update the information, and make a note in the database as to what you did and why, and others can benefit from your updates. Deletion should be reserved for removal of obviously false information. Out of date, or incorrect information should be updated or corrected. We've had some people create towns in the middle of nowhere, and those change sets have been reverted, and removed from the database. Buildings, roads, or other features that have been demolished, or otherwise removed from reality obviously should be removed from the database, but something like the out of date residential area in Landmark Manitoba should be updated, not removed. -- James VE6SRV ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Out of date or incomplete NRCan-CanVec-7.0 data
At 04:52 PM 2013-03-03, James Ewen wrote: I'm just a casual editor who cleans up things I know first hand in a few small towns and a small city.So I went to Landmark, Manitoba and saw an interesting, irregularly shaped out-of-date/incomplete polygon that was added. I don't recall seeing it when I last visited there several months ago but who knows. Residential Area - Source - NRCan-CanVec-7.0 This appears to display a shaded area on the user viewable map. Follow the links to dig deeper into the information available. I didn't realize you could dig that much deeper into who did what. http://www.openstreetmap.org/browse/way/106216638 Or you could update it to reflect reality. Updated. I probably should've joined the nodes to the wooded area polygon or the park so the boundaries are contiguous but I'll figure that out another day. I assumed school yards are part of the residential areas. Is it safe to delete that polygon or will it come back on some re-import in the future. Would it be better to remove all the inaccurate information from OSM, or to correct/update the inaccurate information? If you look at the history, the polygon was imported by sammuell from CanVec in an effort to correct data See that's my problem. When I take a look at that polygon I don't know if it's valid out of date data or someone mucking about or what. So I'm glad I asked. something like the out of date residential area in Landmark Manitoba should be updated, not removed. Updated. Thanks muchly for the detailed explanation. Tony ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Sewage dump stations
Folks One object that is of significant interest to RVs is the location of sewage dump stations. I know of two in my small town one of which is hidden away behind a gas station on a main highway and the other more logically placed in the provincial park campground. I don't see any way to add dump stations as a discrete object. Or am I wrong? Should I put them in as public toilets? Just kidding. Tony ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk-fr] projection antarctique
Le 25/02/2013 16:56, Guillaume Allegre a écrit : Salut, Je cherche s'il existe un projet pour un rendu polaire (antarctique) des données OSM, et je ne trouve rien, ce qui m'étonne. Sans parler pour l'instant de style, la projection standard (Mercator sphérique) n'est pas du tout adaptée. Je cherche un rendu où le pôle est au centre. Déjà, j'ai du mal à déterminer la projection idéale. On trouve notamment : - EPSG:3031 WGS 84 / Antarctic Polar Stereographic - la projection Lambert azimuthale http://cartographie.sciences-po.fr/fr/globe-projection-lambert-p-le-nord-et-p-le-sud - la projection Lambert conique conforme (avec quels paramètres ?) http://wiki.openstreetmap.org/wiki/Antarctica parle des sources mais reste muet sur les rendus. Des pistes ? Salut Guillaume, Je pense à toi en voyant cette nouvelle page : https://wiki.openstreetmap.org/wiki/Antarctica/Creating_a_map liée à partir de : http://lists.openstreetmap.org/pipermail/josm-dev/2013-March/006479.html Il semble que l'UPS (Universal Polar Stereographic), EPSG:3031 pour le Pôle Sud, soit le complément habituel de l'UTM. Les deux systèmes sont d'ailleurs associés dans mon GPS Garmin, qui passe apparemment d'UTM en UPS quand il s'approche d'un pôle (http://www.gpsinformation.net/main/utm-faq.html). Cordialement, Jean-Guilhem -- gpg 0x5939EAE2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] projection antarctique
Grand merci à toi pour la veille et pour ces deux liens. - Mail original - Salut Guillaume, Je pense à toi en voyant cette nouvelle page : https://wiki.openstreetmap.org/wiki/Antarctica/Creating_a_map liée à partir de : http://lists.openstreetmap.org/pipermail/josm-dev/2013-March/006479.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] projection antarctique
Il me semble que ta proposition EPSG:3031 ne répond pas à la question : sa latitude d'origine est à 70 degrés Sud et non 90 degrés Sud. Autrement dit c'est pour des cartes côtières de l'Antarctique et non des cartes centrées au pôle, et c'est pour ça qu'il y a en fait une série de projections similaires selon le méridien d'origine (EPSG:3031 c'est centré sur le méridien de Greenwich, mais EPSG:3032 est centré sur un méridien Australien à 110°E, etc. La projection centrée sur le pôle Sud (avec le méridien central sur la méridien de Greenwich est plutôt EPSG:102019 (mais elle est de type Azimuthal_Equidistant au lieu de Polar_Stereographic). On n'a visiblement pas de projection Mercator standard sur un cylindre tangeant aux pôles (pour la conformité des angles, au prix des surfaces et distances) comme la Mercator standard d'OSM et Google ou Bing, très probablement à cause du fait que le conformité exigerait que ce soit non pas un cylindre à section circulaire mais un cylindroïde à section elliptique du fait de l'excentricité de l'ellipsoïde terrestre). Dans ce cas si ce cylindroiïde étant choisi tangeant au méridien de Greenwich et son antiméridien, il y aurait des allongements à l'Est et à l'Ouest de la carte. La projection azimuthale équidistante semble un meilleur choix et elle est presque conforme pour les angles, mais respecte distnaces et surfaces. Jaimerais bien en revanche comprendre l'intérêt de la projection stéréographique, non centrée aux pôles mais sur un parallèle à 71° Sud, hormis pour la gestion cartographique des divers secteurs revendiqués dans l'Antarctique, où le pôle Sud apparaît tout en bas de la Carte, et le haut de la carte tombe très en deçà delà du cercle polaire (sur les continents sud-américain, africain et australien) à une latitude plus tempérée (même si par convention on coupe les cartes à 60° Sud sur la ligne définissant internationalement l'Antarctique protégé) ! Visiblement ces projections sont des projections politiques nationales, pas adaptées à une carte internationale couvrant tous les secteurs revendiqués. Le 3 mars 2013 11:36, Jean-Guilhem Cailton j...@arkemie.com a écrit : Le 25/02/2013 16:56, Guillaume Allegre a écrit : Salut, Je cherche s'il existe un projet pour un rendu polaire (antarctique) des données OSM, et je ne trouve rien, ce qui m'étonne. Sans parler pour l'instant de style, la projection standard (Mercator sphérique) n'est pas du tout adaptée. Je cherche un rendu où le pôle est au centre. Déjà, j'ai du mal à déterminer la projection idéale. On trouve notamment : - EPSG:3031 WGS 84 / Antarctic Polar Stereographic - la projection Lambert azimuthale http://cartographie.sciences-po.fr/fr/globe-projection-lambert-p-le-nord-et-p-le-sud - la projection Lambert conique conforme (avec quels paramètres ?) http://wiki.openstreetmap.org/wiki/Antarctica parle des sources mais reste muet sur les rendus. Des pistes ? Salut Guillaume, Je pense à toi en voyant cette nouvelle page : https://wiki.openstreetmap.org/wiki/Antarctica/Creating_a_map liée à partir de : http://lists.openstreetmap.org/pipermail/josm-dev/2013-March/006479.html Il semble que l'UPS (Universal Polar Stereographic), EPSG:3031 pour le Pôle Sud, soit le complément habituel de l'UTM. Les deux systèmes sont d'ailleurs associés dans mon GPS Garmin, qui passe apparemment d'UTM en UPS quand il s'approche d'un pôle (http://www.gpsinformation.net/main/utm-faq.html). Cordialement, Jean-Guilhem -- gpg 0x5939EAE2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Conditions de mise à dispo de données par une municipalité
Am 01.03.2013 15:24, schrieb Romain MEHUT: Il y a matière à réflexion ici: http://libertic.wordpress.com/2013/02/28/projet-pilote-douverture-des-petites-communes/ Merci pour ce lien (bien que je ne classe pas Perpignan dans les petites communes;)). Ce site me donne déjà plein d'info sur le sujet. Comme je crains que mon interlocuteur et la ville de Perpignan en général ne se sont pas encore trop penché sur le sujet de l'OpenData, je cherche surtout une information compacte, orienté OSM, sur les aspects juridiques, par exemple: - Quels licences utilisés par les communes sont compatibles avec l'OdBL? - En absence de licence, faut-il demander un accord écrit pour éviter tout risque du coté d'OSM et quels seraient les termes d'un tel accord? Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Conditions de mise à dispo de données par une municipalité
Le 3 mars 2013 13:01, RainerU ra...@sfr.fr a écrit : Am 01.03.2013 15:24, schrieb Romain MEHUT: Il y a matière à réflexion ici: http://libertic.wordpress.com/2013/02/28/projet-pilote-douverture-des-petites-communes/ Merci pour ce lien (bien que je ne classe pas Perpignan dans les petites communes;)). Ce site me donne déjà plein d'info sur le sujet. Comme je crains que mon interlocuteur et la ville de Perpignan en général ne se sont pas encore trop penché sur le sujet de l'OpenData, je cherche surtout une information compacte, orienté OSM, sur les aspects juridiques, par exemple: - Quels licences utilisés par les communes sont compatibles avec l'OdBL? En gros, les deux choix les plus courants sont: - ODbL (Ville de Paris, CU Bordeaux, Région PACA, Toulouse, Agglo. de Pau, Région Aquitaine, Grand Lyon, Ville de Nantes, CG44, Ville d'Angers, CG49... - LO/OL (la licence d'etalab), encore plus permissive (pas de share-alike): Montpellier, Istres, Ville de Bordeaux, Loir et Cher, CG71... - En absence de licence, faut-il demander un accord écrit pour éviter tout risque du coté d'OSM et quels seraient les termes d'un tel accord? Oui, si les données ne sont pas disponibles publiquement sous une licence compatibles et qu'elles sont fournies pour être versées dans OSM il faut un écrit le validant. -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Conditions de mise à dispo de données par une municipalité
Le 3 mars 2013 13:22, Christian Quest cqu...@openstreetmap.fr a écrit : - Quels licences utilisés par les communes sont compatibles avec l'OdBL? En gros, les deux choix les plus courants sont: - ODbL (Ville de Paris, CU Bordeaux, Région PACA, Toulouse, Agglo. de Pau, Région Aquitaine, Grand Lyon, Ville de Nantes, CG44, Ville d'Angers, CG49... - LO/OL (la licence d'etalab), encore plus permissive (pas de share-alike): Montpellier, Istres, Ville de Bordeaux, Loir et Cher, CG71... Il y aurait aussi: - la licence CC-BY (et non pas CC-BY-SA, donc sans Share-Alike) pour juste préserver l'attribution des données (mention de la source) - les licences similaires (de type BSD, mais pas GPL ou LGPL à cause de l'aspect viral imposant la licence à toute oeuvre dérivée composite comme OSM, qui permettrait alors de supprimer la licence ODBL) - une licence sans Share-Alike, qui si elle permet de mentionner la source, [Souvent la mention de la source ou de l'auteur est une obligation légale, marquée par une ligne de copyright par exemple ou par une annexe recensant les auteurs, et c'est une partie du droit d'auteur exclusif n'étant pas une option, ni transférable en France, qui rend quasiment impossible légalement de **créer** quelque chose pour le publier la première fois dans le domaine public, ce dernier n'existant qu'à partir de la date de fin légale de ces droits exclusifs], oblige alors à indiquer que les données sont modifiées (pour le respect de la réputation de la source d'origine contre les altérations ultérieures dont elle n'est pas l'auteur). avec ou sans clauses de non-garantie et de déni de responsabilité (en général c'est inclus avec ces licences, comme pour le domaine public, et OSM non plus n'offre aucune garantie d'adéquation à un usage particulier, ni même obligation de correction des erreurs dans les autres publications ou mises à jour ultérieures de la même source, même si elle en a été avisée) : les données sont fournies alors en l'état, et chaque utilisateur ou réémetteur des données assume lui-même cette responsabilité ou peut prendre conseil auprès d'un tiers pour obtenir de lui une garantie séparée (avec ou sans paiement et dans les limites que précisera ce tiers dans son contrat de service). Noter que la licence ODbL elle-même ne donne aucune paternité. Celle-ci, les contributeurs d'OpenStreetmap en fait une oeuvre collective, ce qui n'est possible qu'à partir du moment où chacun accepte les Contributor Terms pour transférer ses propres droits individuels en tant que travail collectif vers cette communauté (avec aussi pour effet une réduction de la période légale de droits exclusifs, par rapports aux droits exclusifs individuels). En conséquence la licence utilisée par une source doit permettre la réduction éventuelle des droits exclusifs (cela peut exclure des données dont les auteurs ne sont que des individus qui utilisent une autre licence source permettant la conservation sur une durée supérieure à la durée maximale légale). Si les sources ne sont pas des individus, mais une collectivité ou une organisation, cela ne pose pas de problème, la licence d'origine ne devrait pas mentionner de durée maximale des droits exclusifs (pour s'appuyer sur la définition légale applicable de cette durée maximale). A la fin de cette période, il n'y a plus obligation de mentionner la source (dont la réputation n'est aussi plus protégée). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Conditions de mise à dispo de données par une municipalité
Le 3 mars 2013 14:09, Philippe Verdy verd...@wanadoo.fr a écrit : Le 3 mars 2013 13:22, Christian Quest cqu...@openstreetmap.fr a écrit : - Quels licences utilisés par les communes sont compatibles avec l'OdBL? En gros, les deux choix les plus courants sont: - ODbL (Ville de Paris, CU Bordeaux, Région PACA, Toulouse, Agglo. de Pau, Région Aquitaine, Grand Lyon, Ville de Nantes, CG44, Ville d'Angers, CG49... - LO/OL (la licence d'etalab), encore plus permissive (pas de share-alike): Montpellier, Istres, Ville de Bordeaux, Loir et Cher, CG71... Il y aurait aussi: - la licence CC-BY (et non pas CC-BY-SA, donc sans Share-Alike) pour juste préserver l'attribution des données (mention de la source) - les licences similaires (de type BSD, mais pas GPL ou LGPL à cause de l'aspect viral imposant la licence à toute oeuvre dérivée composite comme OSM, qui permettrait alors de supprimer la licence ODBL) La question était licences compatibles avec l'OdBL, on parle donc de données, de bases de données, pas d'œuvre de l'esprit pour lesquelles CC et les différentes licences open-source s'appliquent et qui sont inadaptées, c'est d'ailleurs pour ça qu'OSM est passé de CC à ODbL. Autant faire simple et conseiller à des collectivités les deux seuls choix (ODbL ou LO/OL) adoptés par la quasi totalité de leurs collègues (ce qui va les rassurer). A vouloir être trop exhaustif, on risque de les embrouiller alors qu'au final ils en viendront à choisir entre ces deux là. J'ai éliminée l'APIE qui est une licence jugée incompatible avec l'ODbL d'OSM. Rainer, n'hésite pas à te rapprocher de LiberTIC qui pourra t'aider dans l'argumentaire à développer. Claire est une championne ! -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Tracé de projets
Du coup j'ai repris la suggestion de Nicolas, à savoir : et pourquoi
pas u{Map} pour montrer cette info et la partager ?
En 2mn ça donne ça :
http://umap.fluv.io/m/410/
Voilà, on trouve des compromis :) Merci pour l'info !
Teuxe
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Conditions de mise à dispo de données par une municipalité
Am 03.03.2013 15:03, schrieb Christian Quest: Autant faire simple et conseiller à des collectivités les deux seuls choix (ODbL ou LO/OL) adoptés par la quasi totalité de leurs collègues (ce qui va les rassurer). A vouloir être trop exhaustif, on risque de les embrouiller alors qu'au final ils en viendront à choisir entre ces deux là. Je suis tout à fait d'accord là-dessus. De toute façon, comme personne n'a jamais entendu parler de la ville de Perpignan et Opendata et on ne trouve rien sur le sujet sur leur site, je pense que pour les noms des rues cela se fera par un accord spécifique. A moyen terme, comme on a d'autres besoins opendata, le but est de les faire bouger dans ce sens. Le plus simple serait de leur présenter Montpellier comme exemple positif, mais vu les rivalités locales ça risque d'avoir l'effet contraire. Rainer, n'hésite pas à te rapprocher de LiberTIC qui pourra t'aider dans l'argumentaire à développer. Claire est une championne ! Ok. Rainer ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Conditions de mise à dispo de données par une municipalité
Le 3 mars 2013 15:42, RainerU ra...@sfr.fr a écrit : Le plus simple serait de leur présenter Montpellier comme exemple positif, mais vu les rivalités locales ça risque d'avoir l'effet contraire. Même si l'opendata dépasse les clivages politiques, les sensibilités politiques locales (UMP?) sont à prendre en compte dans les exemples à donner... -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Comment traiter des bâtiments détruits ?
Bonjour, Comment traiter des bâtiments détruits ? J'ai fais des photos d'un bâtiment maintenant détruit : http://commons.wikimedia.org/wiki/File:Courtab%C5%93uf_2011_059.jpg situé ici : http://www.openstreetmap.org/?lat=48.681342lon=2.198424zoom=18layers=M J'ai changé le nom du bâtiment pour marquer bâtiment détruit mais je n'ai pas effacé la trace du bâtiment car je me dis qu'il serait intéressant d'en conserver une trace. Qu'en pensez-vous ? Librement, -- Lionel Allorge April : http://www.april.org Lune Rouge : http://www.lunerouge.org Découvrez le court métrage de science-fiction Tears of steel http://mango.blender.org/ « Le travail d'équipe est essentiel. En cas d'erreur, ça permet d'accuser quelqu'un d'autre. » Tristan Bernard ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Conditions de mise à dispo de données par une municipalité
Le 3 mars 2013 15:03, Christian Quest cqu...@openstreetmap.fr a écrit : La question était licences compatibles avec l'OdBL, on parle donc de données, de bases de données, pas d'œuvre de l'esprit pour lesquelles CC et les différentes licences open-source s'appliquent et qui sont inadaptées, c'est d'ailleurs pour ça qu'OSM est passé de CC à ODbL. Non, on est passé de CC-BY-SA à ODbL (la précision BY ne change pas, mais la restriction SA est très différente, et c'est justement là que la partie base de données intervient ; sans la restriction SA, CC-BY reste adapté aux bases de données). CC-BY (et non CC-BY-SA) est compatible ODbL. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment traiter des bâtiments détruits ?
Et s'il se construit autre chose à la place, cela ne risque pas de surcharger la carte et compliquer l'édition ? Je veux bien qu'on conserve les anciennes communes (après tout elles persistent encore sur les actes d'Etat-civil, les contrats, les décisions de tribunaux encore applicables, ou certains traités internationaux dont le texte n'est pas amendé par les parties mais gardé tel quel ; le seul amendement c'est la déclaration de la nouvelle entité qui en assure la succession). Mais pour un bâtiment qui a de grandes chances d'être replacé par autre chose : autre(s) batiment(s) de forme différente, parcs, jardins, rues ou allées... est-ce que ça vaut le coup ? Il sera vite oublié, il n'a pas de successeurs lui-même, contrairement aux parcelles de terrains qu'il occupait (mais ce terrain peut ensuite être loti et divisé en plusieurs propriétaires ou copropriétaires, ou en partie occupé par la collectivité pour sa voirie. Le 3 mars 2013 19:45, Lionel Allorge (lionel.allo...@lunerouge.org) lionel.allo...@lunerouge.org a écrit : Bonjour, Comment traiter des bâtiments détruits ? J'ai fais des photos d'un bâtiment maintenant détruit : http://commons.wikimedia.org/wiki/File:Courtab%C5%93uf_2011_059.jpg situé ici : http://www.openstreetmap.org/?lat=48.681342lon=2.198424zoom=18layers=M J'ai changé le nom du bâtiment pour marquer bâtiment détruit mais je n'ai pas effacé la trace du bâtiment car je me dis qu'il serait intéressant d'en conserver une trace. Qu'en pensez-vous ? Librement, -- Lionel Allorge April : http://www.april.org Lune Rouge : http://www.lunerouge.org Découvrez le court métrage de science-fiction Tears of steel http://mango.blender.org/ « Le travail d'équipe est essentiel. En cas d'erreur, ça permet d'accuser quelqu'un d'autre. » Tristan Bernard ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment traiter des bâtiments détruits ?
Bonjour Le 03/03/2013 19:45, Lionel Allorge (lionel.allo...@lunerouge.org) a écrit : Qu'en pensez-vous ? Lorsqu'une nouvelle route efface une ancienne, l'ancienne n'existe plus, comme cela l'est réellement, pour ma part, je l'appliquerai sur la base également -- Cordialement David Crochet http://fr.wikiversity.org : Communauté pédagogique libre à laquelle chacun peut prendre part ! http://www.wikimedia.fr : Aidons la diffusion de la connaissance libre ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Comment traiter des bâtiments détruits ?
On 03/03/2013 19:45, Lionel Allorge (lionel.allo...@lunerouge.org) wrote: Qu'en pensez-vous ? Un simple building=no, ça evite que quelqu'un le rajoute si il est toujours sur le cadastre/bing. Au pire avec une note=* ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet du mois de Mars : Wikipedia
Le 02/03/2013 15:55, Black Myst a écrit : Bonjour, Je vous propose le thème Wikipedia comme projet du mois de Mars 2013. Pour les personnes qui seraient intéressé, je vous invite à lire la page de présentation: http://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/Wikipedia Il y a environ 2800 erreurs osmose lié au tag wikipedia dans le monde, dont 1200 en France. Sans compter tous les nouveaux liens que l'on pourrait ajouter. Bonne correction, Black Myst PS: Je vous invite également à proposer et préparer d'autres thèmes pour les mois à venir sur la page: http://wiki.openstreetmap.org/wiki/FR:Project_of_the_month ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr Bonjour, Il y a plein d'erreurs concernant wikipedia:image dans Osmose. Est-ce fondé ? La page wiki citée en exemple n'en parle pas. A+ -- Marc Sibert mailto:m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Projet du mois de Mars : Wikipedia
Ces tags sont mal fichus. Il n'y a pas d'images réellement sur Wikipédia, elles sont sur Commons (pour la plupart). De plus y mettre une URL est incorrect (cela pointe selon les cas vers diverses versions thumnails à différentes tailles, ou bien vers la page de description. Enfin quelle image choisir ? A mon avis il est largement préférable de revoir ces tags pour ne pas indiquer ces URLs mal fichues. Et mettre alors ces images sous une forme : image:commons=Category:Page Name image:commons=Gallery Page Name sans indiquer aucune URL mais le nom de la catégorie ou galerie, avec le nom directement lisible (ce nom est très explicite pour les catégories et galeries de Commons). Et s'il n'y a ni catégorie ni galerie existante sur Commons (notamment pour un objet cartographié particulier), utiliser alors : image:commons=File:Image File Name.jpg (là encore pas d'URLencodage du nom de ces fichiers avec des %nn, pas de soulignés, utiliser les espaces). Il me semble aussi qu'on peut s'en passer facilement : les images appropriées pour un objet existant dans OSM devraient toutes êtres géolocalisées sur Commons. Il existe déjà des outils sur Commons pour les afficher sous forme d'icônes sur la carte OSM. Cependant cette géolocalisation est parfois imprécise et il est difficile d'associer une image ou plusieurs correspondant exactement à la position ou l'objet recherché. Pour ces raisons, il vaut mieux se fier aux liens interwikis existants sur une page Wikipédia qui pointe vers la collection (galerie ou catégorie) appropriée pour l'article. Il y a des modèles qui existent déjà pour cela, et cela génère une référence qu'on peut interroger par une requête de base de données pour lister les références externes vers Commons. Il n'est même pas nécessaire de parser la page wiki (MediaWiki le fait déjà pour nous). Regardez un peu du côté des outils déjà développés sur le ToolServer pour obtenir des infos sur n'importe quelle page, notamment ses liens internes et externes. En plus de présenter cela sur la carte, si on clique les icones d'images, cela affiche automatiquement un panneau décrivant l'image, avec aussi les attributions nécessaires. Si c'est une vidéo ou une image très haute résolution, on a des lecteurs en Flash ou Javascript permettant de naviguer dedans. Noter aussi que sur Commons on peut aussi trouver dans les mêmes catégories des enregistrements audio (pas inutile dans le contexte de l'accessibilité). Ainsi que des documents PDF et divers autres formats (y compris des scans de cartes ou de livres libres). Ce qui fait que le tag image:commons=* pourrait en fait être medias:commons=* (noter le pluriel de medias). On pourrait alors aussi mettre des collections de médias catégorisés d'autres sites (medias:flickr=*, ...) sous une forme simplifiée de leur URL (réduite à la partie identifiante, sans nom de domaine, ni chemin d'accès), afin de laisser les outils générer l'URL vers une présentation donnée des médias vers différentes tailles ou méthodes de rendus, ou vers les métadonnées associées (nécessaire pour respecter les licences). Les URL directes vers les thumbnails générés à la demande par le serveur d'images de Commons pour inclusion dans une page Wikipédia ne respectent pas les licences. Raison de plus pour ne PAS les garder sous cette forme. Wikipédia d'ailleurs ne se contente pas d'afficher l'image et fournit aussi le lie ndirect vers la page de description. OSM ne devrait aussi ne rien faire qui évite la référence à la page de description. Le 3 mars 2013 21:15, Marc Sibert m...@sibert.fr a écrit : Le 02/03/2013 15:55, Black Myst a écrit : Bonjour, Je vous propose le thème Wikipedia comme projet du mois de Mars 2013. Pour les personnes qui seraient intéressé, je vous invite à lire la page de présentation: http://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/Wikipedia Il y a environ 2800 erreurs osmose lié au tag wikipedia dans le monde, dont 1200 en France. Sans compter tous les nouveaux liens que l'on pourrait ajouter. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] projection antarctique
Philippe, https://en.wikipedia.org/wiki/Universal_Polar_Stereographic_coordinate_system (y compris des références détaillées si tu veux des détails) Le système de coordonnées UPS est bien centré sur les pôles, et conforme (c'est-à-dire qu'il respecte localement les angles, donc les formes, ce qui est important pour la navigation - un des principaux usages pour lesquels il a été choisi). Patiemment, Jean-Guilhem PS 1 : je répète ce lien, qui contenait aussi un exemple de 3031, au cas où tu lui accorderais plus d'intérêt la deuxième fois : https://wiki.openstreetmap.org/wiki/Antarctica/Creating_a_map PS 2 : à propos, c'est quoi ta projection préférée ? https://xkcd.com/977/ ;) Le 03/03/2013 12:11, Philippe Verdy a écrit : Il me semble que ta proposition EPSG:3031 ne répond pas à la question : sa latitude d'origine est à 70 degrés Sud et non 90 degrés Sud. Autrement dit c'est pour des cartes côtières de l'Antarctique et non des cartes centrées au pôle, et c'est pour ça qu'il y a en fait une série de projections similaires selon le méridien d'origine (EPSG:3031 c'est centré sur le méridien de Greenwich, mais EPSG:3032 est centré sur un méridien Australien à 110°E, etc. La projection centrée sur le pôle Sud (avec le méridien central sur la méridien de Greenwich est plutôt EPSG:102019 (mais elle est de type Azimuthal_Equidistant au lieu de Polar_Stereographic). On n'a visiblement pas de projection Mercator standard sur un cylindre tangeant aux pôles (pour la conformité des angles, au prix des surfaces et distances) comme la Mercator standard d'OSM et Google ou Bing, très probablement à cause du fait que le conformité exigerait que ce soit non pas un cylindre à section circulaire mais un cylindroïde à section elliptique du fait de l'excentricité de l'ellipsoïde terrestre). Dans ce cas si ce cylindroiïde étant choisi tangeant au méridien de Greenwich et son antiméridien, il y aurait des allongements à l'Est et à l'Ouest de la carte. La projection azimuthale équidistante semble un meilleur choix et elle est presque conforme pour les angles, mais respecte distnaces et surfaces. Jaimerais bien en revanche comprendre l'intérêt de la projection stéréographique, non centrée aux pôles mais sur un parallèle à 71° Sud, hormis pour la gestion cartographique des divers secteurs revendiqués dans l'Antarctique, où le pôle Sud apparaît tout en bas de la Carte, et le haut de la carte tombe très en deçà delà du cercle polaire (sur les continents sud-américain, africain et australien) à une latitude plus tempérée (même si par convention on coupe les cartes à 60° Sud sur la ligne définissant internationalement l'Antarctique protégé) ! Visiblement ces projections sont des projections politiques nationales, pas adaptées à une carte internationale couvrant tous les secteurs revendiqués. Le 3 mars 2013 11:36, Jean-Guilhem Cailton j...@arkemie.com a écrit : Le 25/02/2013 16:56, Guillaume Allegre a écrit : Salut, Je cherche s'il existe un projet pour un rendu polaire (antarctique) des données OSM, et je ne trouve rien, ce qui m'étonne. Sans parler pour l'instant de style, la projection standard (Mercator sphérique) n'est pas du tout adaptée. Je cherche un rendu où le pôle est au centre. Déjà, j'ai du mal à déterminer la projection idéale. On trouve notamment : - EPSG:3031 WGS 84 / Antarctic Polar Stereographic - la projection Lambert azimuthale http://cartographie.sciences-po.fr/fr/globe-projection-lambert-p-le-nord-et-p-le-sud - la projection Lambert conique conforme (avec quels paramètres ?) http://wiki.openstreetmap.org/wiki/Antarctica parle des sources mais reste muet sur les rendus. Des pistes ? Salut Guillaume, Je pense à toi en voyant cette nouvelle page : https://wiki.openstreetmap.org/wiki/Antarctica/Creating_a_map liée à partir de : http://lists.openstreetmap.org/pipermail/josm-dev/2013-March/006479.html Il semble que l'UPS (Universal Polar Stereographic), EPSG:3031 pour le Pôle Sud, soit le complément habituel de l'UTM. Les deux systèmes sont d'ailleurs associés dans mon GPS Garmin, qui passe apparemment d'UTM en UPS quand il s'approche d'un pôle (http://www.gpsinformation.net/main/utm-faq.html). Cordialement, Jean-Guilhem -- gpg 0x5939EAE2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- gpg 0x5939EAE2 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Un noeud pour un tableau...
Hello, En corrigeant des tags wikipedia, je suis tombé sur ce point: http://www.openstreetmap.org/browse/node/1359955172 D'après ce que j'en comprends, il désigne un tableau de Van Gogh ! Je ne trouve pas particulièrement utile d'avoir un noeud pour une oeuvre dans un musée... J'imagine mal le nombre de point qu'il faudrait pour le Louvre par exemple. Qu'en pensez-vous ? Black Myst ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un noeud pour un tableau...
si je comprends bien c'est un panneau d'info, disant que cette peinture à été peint à cet endroit? Jo 2013/3/4 Black Myst black.m...@free.fr Hello, En corrigeant des tags wikipedia, je suis tombé sur ce point: http://www.openstreetmap.org/browse/node/1359955172 D'après ce que j'en comprends, il désigne un tableau de Van Gogh ! Je ne trouve pas particulièrement utile d'avoir un noeud pour une oeuvre dans un musée... J'imagine mal le nombre de point qu'il faudrait pour le Louvre par exemple. Qu'en pensez-vous ? Black Myst ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] projection antarctique
Ce n'était pas la peine de donner les liens je connais déjà et j'avais déjà lu ces articles Wikipédia (qui survolent à peine le sujet dans leur version française). Justement oui, cette projection stéréographique est bien pour la navigation (de 60 à 82° environ), mais j'ai des doutes concernant la projection des terres jusqu'au pôle, justement car son plan de référence est à 71°Sud, ce qui me parait trop au nord. De plus cette projection dépend de deux paramètres : - le choix du plan de projection (parallèle au plan équatorial) donc de sa latitude je ne suis pas convaincu que le plan à 71°C soit le meilleur pour l'ellipsoïde) - le choix du centre de projection (sur l'axe des pôle): si on le place au Pôle Nord directement à la surface du géoïde, il produit des déformations importantes (pour moi étant donné l'excentricité de la Terre, ce point devrait être élevé en altitude au dessus de la surface du pôle, afin de mieux approcher l'ellipsoïde, avec des glissements moins importants des points (ceux entre le plan de projection et le pôle) sur la carte vers le pôle (l'erreur est maximale autour de 82°S avec la projection actuelle) Personnellement j'aurais choisi pour représenter tout le continent une projection plus simple utilisant comme référence directement la vraie distance d'un point du géoïde jusqu'au pôle (longueur d'arc elliptique) et le vrai angle de cap vers le pôle (autrement dit la longitude). Cela restait adapté aussi bien sur le continent que dans la zone maritime. Si la distance elliptique est trop compliquée à calculer à partir de la latitude, on peut aussi bien utiliser la projection sur la sphère tangeante au pôle au lieu de l'ellipsoïde de référence (cela restera de toute façon bien meilleur que la projection stéréographique qui n'a de vrai usage que maritime). Dans ce cas la conversion est simple (projection sur la sphère) : x = cos(longitude * pi/180°) * R/échelle * (90°+latitude)*pi/180° y = sin(longitude * pi/180°) * R/échelle * (90+latitude)*pi/180° Le dernier facteur (90°+latitude)*pi/180° est une mesure de l'arc de cercle le long d'un méridien d'une sphère. C'est là qu'on peut l'ajuster avec un arc elliptique pour plus de précision, en tenant compte de l'excentricité constante du géoïde et de la seule latitude. Certes cela entraine aussi des déformations (surtout des étirements de surface le long des parallèles), mais on préserve toutes les distances le long des méridiens et tous les angles. Il n'y a aucun moyen d'être conforme pour tout sur une carte plane. Pour la navigation avec EPSG 3031 on préfère conserver tous les angles mais cette fois les distances le long des parallèles, même si les distances le long des méridiens ne sont pas uniformes (et on a donc aussi étirement des surfaces selon la latitude). Etant donné que ce sont les régions maritimes qui sont les plus utilisées (le pôle est très difficile d'accès), on peut comprendre que EPSG 3031 soit préféré mais on doit tout de même savoir que si cela marche bien jusqu'à la côte, on n'ira pas au pôle (mais a-t-on beaucoup de choses à cartographier précisément sur cette terre de glace dont la surface est très changeante, et tout ce qui y est construit, par exemple une piste, peut disparaître sous des mètres de neige ?). Ce petit continent n'est malgré tout pas une mer de glace, il a un relief important, la glace s'écoule aussi lentement vers les rivages (causant les icebergs), et se crevasse, la fonte en surface crée des cours d'eaux sous-glaciaires se faufilant par les crevasses. De fait tout ce qu'on y construit peut bouger sauf si on a choisi un promontoire rocheux (ce qui est le cas pour les installations côtières), ou si on est très loin des côtes sur le plateau hors des lits glaciaires. Le 4 mars 2013 00:08, Jean-Guilhem Cailton j...@arkemie.com a écrit : Philippe, https://en.wikipedia.org/wiki/Universal_Polar_Stereographic_coordinate_system (y compris des références détaillées si tu veux des détails) Le système de coordonnées UPS est bien centré sur les pôles, et conforme (c'est-à-dire qu'il respecte localement les angles, donc les formes, ce qui est important pour la navigation - un des principaux usages pour lesquels il a été choisi). Patiemment, Jean-Guilhem PS 1 : je répète ce lien, qui contenait aussi un exemple de 3031, au cas où tu lui accorderais plus d'intérêt la deuxième fois : https://wiki.openstreetmap.org/wiki/Antarctica/Creating_a_map PS 2 : à propos, c'est quoi ta projection préférée ? https://xkcd.com/977/ ;) Le 03/03/2013 12:11, Philippe Verdy a écrit : Il me semble que ta proposition EPSG:3031 ne répond pas à la question : sa latitude d'origine est à 70 degrés Sud et non 90 degrés Sud. Autrement dit c'est pour des cartes côtières de l'Antarctique et non des cartes centrées au pôle, et c'est pour ça qu'il y a en fait une série de projections similaires selon le méridien d'origine (EPSG:3031 c'est centré sur le méridien de Greenwich, mais EPSG:3032 est centré sur un
[OSM-talk-fr] Taguer les zones de sismicité françaises
5 niveaux de sismicité sont définis en France dans la loi, inscrite dans l'article R563-1 du Code de l'environnement, sur la prévention des risques sismiques : 1 (très faible) ; 2 (faible) ; 3 (modérée) ; 4 (moyenne) ; 5 (forte). http://www.legifrance.org/affichCode.do;jsessionid=F89FAA30D2B8818F7A0607AF5CD773AD.tpdjo02v_3?idSectionTA=LEGISCTA06177010cidTexte=LEGITEXT06074220dateTexte=20121104 Le risque fort ne concerne actuellement que les Antilles françaises (Guadeloupe, Martinique et Saint-Martin, et devrait inclure Saint-Barthélemy mais la loi ne le liste pas). La Réunion par exemple a un risque faible (niveau 2), malgré son volcanisme, plus faible par exemple que le massif du Jura, une bonne partie des Alpes et des Pyrénées françaises, et une partie de la Provence (sismicité moyenne, niveau 4). Le risque très faible (niveau 1) se situe essentiellement dans le Val de Loire, la bassin parisien, la Picardie, la Champagne-Ardennes, la Bourgogne et la Lorraine Je n'envisage pas directement de dessiner ces zones, la loi définit les zones en listant, département par département, les cantons ou communes concernées pour chaque niveau de risque. Quand des cantons sont utilisés, les communes fractionnes ne sont pas découpées et incluses en entier dans la zone. Bref cela consisterait à porter cette info : * soit dans un tag supplémentaire dans les communes (risk:sismicity:FR=1 à 5) ; == l'ennui étant que cela fait plus de 36000 relations à modifier (si on le fait au niveau des communes (et il manque encore près de 4000 communes dans la base) * soit dans 5 nouvelles relations se contentant de lister les départements, cantons ou communes membres sous forme uniquement relationelle (pas besoin de mettre les frontières, au moins pas pour l'instant, cela en permanence impacterait la maintenance dès qu'une frontière administrative est modifiée quelquepart), avec des membres de rôle include par défaut, ou exclude ; == impact nettement plus limité, et peu de maintenance (5 nouveaux objets seulement, indépendants, en référençant le minimum d'objets, ceux définis par la loi, donc des communes, cantons, départements, ou COM ; noter que la loi ne classifie pas tout l'outre-mer, par exemple la Nouvelle-Calédonie, la Polynésie française, Wallis-et-Futuna, et Saint-Barthélémy, mais classifie tous les DOM ainsi que les COM de Saint-Pierre-et-Miquelon et Saint-Martin). Certes il manque dans la base encore un certain nombre de cantons, mais on pourrait en attendant leur création, les ajouter en notes FIXME des 5 relations. Qu'en pensez-vous ? NB: Il y a sans doute d'autres définitions légales similaires sur la prévention des risques (zones inondables, zones de sécurité nucléaires...). Ce devrait être des données de long terme (pas les simples classements en état de catastrophe naturelle ou industrielle, même si ces zones sont très étendues, comme les zones historiques de sécheresse, ou de risques sanitaires spécifiques comme les épizooties, également temporaires, à moins que ce classement soit destiné à être permanent et révisé régulièrement). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un noeud pour un tableau...
Bonjour, Le 04/03/2013 01:09, Jo a écrit : si je comprends bien c'est un panneau d'info, disant que cette peinture à été peint à cet endroit? 2013/3/4 Black Myst black.m...@free.fr mailto:black.m...@free.fr En corrigeant des tags wikipedia, je suis tombé sur ce point: http://www.openstreetmap.org/browse/node/1359955172 D'après ce que j'en comprends, il désigne un tableau de Van Gogh ! Je ne trouve pas particulièrement utile d'avoir un noeud pour une oeuvre dans un musée... J'imagine mal le nombre de point qu'il faudrait pour le Louvre par exemple. C'est bien un noeud pour un panneau, et un panneau pour un tableau :-) Cette photo confirme : http://goo.gl/maps/JyqUF (Et à la rigueur, il lui manque un ref=23) vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Un noeud pour un tableau...
Le 4 mars 2013 07:31, Vincent de Chateau-Thierry v...@laposte.net a écrit : Bonjour, Le 04/03/2013 01:09, Jo a écrit : si je comprends bien c'est un panneau d'info, disant que cette peinture à été peint à cet endroit? 2013/3/4 Black Myst black.m...@free.fr mailto:black.m...@free.fr En corrigeant des tags wikipedia, je suis tombé sur ce point: http://www.openstreetmap.org/**browse/node/1359955172http://www.openstreetmap.org/browse/node/1359955172 D'après ce que j'en comprends, il désigne un tableau de Van Gogh ! Je ne trouve pas particulièrement utile d'avoir un noeud pour une oeuvre dans un musée... J'imagine mal le nombre de point qu'il faudrait pour le Louvre par exemple. C'est bien un noeud pour un panneau, et un panneau pour un tableau :-) Cette photo confirme : http://goo.gl/maps/JyqUF (Et à la rigueur, il lui manque un ref=23) Pourtant le lien wikipedia wikipedia = fr:Portrait d'Adeline Ravoux ou wikipedia:en = Paintings of Children (Van Gogh series)#Adeline_Ravoux issu du point donné ne correspond pas du tout à la photo ? D'après la photo ça devrait plutot être La mairie d'Auvers sur Oise le 14 juillet ; ce tableau est bien listé dans la liste des tableaux de Van Gogh ( http://fr.wikipedia.org/wiki/Liste_des_tableaux_de_Vincent_van_Gogh ), mais il n'a pas sa page wikipedia fr. Faites au mieux :-) -- Les dérives de rue : Des textes à promenades http://drivrsdu.fr/des-textes-a-promenades/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Taguer les zones de sismicité françaises
On 03/04/2013 05:53 AM, Philippe Verdy wrote: Qu'en pensez-vous ? [..] Il y a sans doute d'autres définitions légales similaires sur la prévention des risques (zones inondables, zones de sécurité nucléaires...). Ce devrait être des données de long terme (pas les simples classements en état de catastrophe naturelle ou industrielle, même si ces zones sont très étendues, comme les zones historiques de sécheresse, ou de risques sanitaires spécifiques comme les épizooties, également temporaires, à moins que ce classement soit destiné à être permanent et révisé régulièrement). C'est bien, mais ça se relève comment sur le terrain ? Encore plus que pour les zones de crues (qui étaient un cas méritant discussion), il me semble qu'on sort de la définition des données géographiques vérifiables sur le terrain. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-ja] 月間OSMJサマリー 2013/2月号(Vol.10)
主に日本でのOSMに関わるあらゆる動きをひと月分まとめてお知らせします。 ― 【コミュニティ】 ― ◆2/8 住所 http://lists.openstreetmap.org/pipermail/talk-ja/2013-February/007107.html ◆2/9 OSC2013浜松 OSMより出展 http://www.ospn.jp/osc2013-hamamatsu/ ◆2/11 OSM Node Viewer をバージョンアップしました http://lists.openstreetmap.org/pipermail/talk-ja/2013-February/007115.html ◆2/11 UI 翻訳レビューのお願い http://lists.openstreetmap.org/pipermail/talk-ja/2013-February/007117.html ◆2/15 交差点の名前の表示 http://lists.openstreetmap.org/pipermail/talk-ja/2013-February/007118.html ◆2/20 broken motorway in Kiyosu http://lists.openstreetmap.org/pipermail/talk-ja/2013-February/007123.html ◆2/21 マッピングパーティの企画のしかたについて http://lists.openstreetmap.org/pipermail/talk-ja/2013-February/007125.html ◆2/22 石巻復興マッピングのご協力お願い！ http://wiki.openstreetmap.org/wiki/JA:Ishinomaki_mapping_party_20130413 ◆2/22 OpenStreetMap 利用アプリ開発入門 http://atnd.org/events/35653 ◆2/22-23 OSC2013Tokyo Spring OSMより企画セミナーと出展 http://www.ospn.jp/osc2013-spring/ ◆2/23 OSC会場での話題(Android版でよいOSMツール) http://lists.openstreetmap.org/pipermail/talk-ja/2013-February/007130.html ◆2/24 【OSM関西】妙見山ハイキングマッピングパーティ http://atnd.org/events/36860 ― 【調査・研究】 ― ― 【OSMF/OSMFJからのお知らせ】 ― ◆3/30(土) 東京、駒込でマッピングパーティを行います。 ちょっと桜の時期には早いかもしれませんが、これからの桜を思いながらの商店街の食べ歩きとマッピング、いかがでしょう？ ガチでマッピングしたいかたは六義園でTree Mappingが視野ですよ！？ http://connpass.com/event/1953/ ― 【イベント案内】 ― ◆4/13(土)石巻復興マッピングパーティ http://wiki.openstreetmap.org/wiki/JA:Ishinomaki_mapping_party_20130413 ― 【報道・ブログ・その他】 ― ◆東京カートグラフィック社が「伊能図を持ち歩こう！伊能図A5サイズリングノート」発売。伊能忠敬の歩いた軌跡とOSMを重ねることができます（東京中心部のみ）。 http://www.tcgmap.jp/product/goods/goods1/522.html ◆2/6 OpenStreetMapは新しいマップエディタを取得 http://oss.doorblog.jp/archives/24035060.html ◆2/9 AndroidでOpenStreetMapを使ってみる http://foonyan.sakura.ne.jp/wisteriahill/openstreetmap/ ― 日本でのOSMに関わるニュースなどを募集しています。 osmj.news(at)osmf.jp までお知らせください。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-us] Park Boundary tagging
I'm not sure it's useful to continue, but (ignoring wiki and existing practice) I think of a boundary as closed line, not as an area. Yes, you can talk about inside and outside, but really that's it. The notion of all land inside this closed way has this property is distinct from this line is a boundary (which the two-relation approach makes very clear). What I don't like about the boundary tag is that I don't see any reason why this area has property X won't end up with boundary=X, and that result seems broken, especially since boundary=X seems to be shorthand for certain tags on the area. Probably the root of the issue is that OSM blurs closed linear features and areas. pgpvVwVx8NshA.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
Perhaps we can both be correct simultaneously, while holding in reserve multiple foci about what we mean. For example, Paul Norman shares with me that his greater meaning in his previous post includes that it depends what you mean by boundary. He goes on to describe (Paul Norman writes): A type=boundary relation is generally interpreted to be an area by all software I am aware of that makes the distinction between a LINESTRING and a POLYGON (linear vs area). I have some code that treats it as a linear feature, but then it treats everything as a linear feature or a point at that stage because it only cares about building bounding boxes. Keep in mind that just because a feature is an area doesn't mean you display it like one. For example, no one would disagree that a closed building=yes way is an area, but many renderings put a line around the outside. Similarly, if you're only rendering the outside line of the area it doesn't matter if you represent it as a linear feature or an area because it looks the same. A way with boundary=* is completely different. These are generally is not closed and therefore obviously cannot be an area. The standard reference for a tag describing a polygon or a linear feature is http://svn.openstreetmap.org/applications/utils/export/osm2pgsql/default.stylehttp://svn.openstreetmap.org/applications/utils/export/osm2pgsql/default.style but it does not apply to type=* which is handled at a lower level. In short, these are muddy waters. Nobody should start to assert absolutes, unless simultaneous perspectives have been eliminated. In the context of type being one thing (and handled e.g. as a software implementation along a path to render mapnik) and boundary meaning (in a wide semantic sense) another, we do indeed have multiple perspectives. So my or any other absolutism is likely premature. I'm not sure it's useful to continue, but (ignoring wiki and existing practice) I think of a boundary as closed line, not as an area. Yes, you can talk about inside and outside, but really that's it. The notion of all land inside this closed way has this property is distinct from this line is a boundary (which the two-relation approach makes very clear). What I don't like about the boundary tag is that I don't see any reason why this area has property X won't end up with boundary=X, and that result seems broken, especially since boundary=X seems to be shorthand for certain tags on the area. Probably the root of the issue is that OSM blurs closed linear features and areas. You've summed up nicely a perspective which is valuable. I think the big take-away we blur much, and there now exist (as implied behavior by the mapnik visual-render path) shorthand for certain tags on the area. Succinctly: tags which imply semantic meaning must be untangled from the syntax of what we do mean. So, a better direction for this thread to continue might be for it to examine and discuss the syntax of park tagging. What might be an ideal tagging today (for various park entities upon which we agree have a standardized semantic understanding), what might we expect from tagging but do not get with mapnik today, and what might we posit as slight changes to mapnik style sheets which cause to happen interesting, consensus-reached and beautiful renderings which visually convey a lot more than is conveyed today? Terrific thread so far! SteveA California___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
It might be useful to look at existing GIS practice to see how boundary objects are treated in terms of being LINESTRING vs POLYGON (thanks Paul for reminding us of OGC simple features defined terminology). But, I suspect that the GIS world has a layer and a text description of it, and that has let them avoid what OSM is doing: building a coherent representation of everything (which leads to all the trouble). pgp3_DeBjdknT.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
stevea stevea...@softworkers.com writes: So, a better direction for this thread to continue might be for it to examine and discuss the syntax of park tagging. What might be an ideal tagging today (for various park entities upon which we agree have a standardized semantic understanding), what might we expect from tagging but do not get with mapnik today, and what might we posit as slight changes to mapnik style sheets which cause to happen interesting, consensus-reached and beautiful renderings which visually convey a lot more than is conveyed today? I suggest that the tags for parks/etc. be defined so that if there are no boundary tags, everything still makese sens. (I'll further suggest that once this is done, there is no need for boundary tags.)) I'll start with landuse=conservation (because at least a co-primary purpose is to preserve the land for the future, and usually this is primary.) leisure=nature_reserve (because a co-primary, but really not quite-as-high-as-conservation is to allow access to the public) Then we get into tags that refer to the administrator of an area. One can consider a tag that is administrator=government:admin_level=2 administrator_name=National Park Service (for a national park) administrator=government:admin_level=4 administrator_name=Massachusetts Department of Conservation and Recreation or administrator=charitable:admin_level=2 (for a national-level charitable non-profit) administrator=charitable:admin_level=8 administrator_name=Westborough Community Land Trust (for a local non-profit) Or perhaps break that up into two. And of course name of the park. My bias is that the nature of the land use is more important than the identity of the manager. Another similar area is a wildlife refuge. Ones that allow humans are perhaps appropriately tagged as above. Ones that do not allow humans as perhasp landuse=conservation and some other special wildlife_refuge tag. pgpa2bCcfX84b.pgp Description: PGP signature ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
There are some anomalous cases that are of particular concern to me. Consider the Adirondack and Catskill Parks in New York. These are enormous tracts of land with intensive conservation restrictions placed on them - but many lands within the parks remain in private hands; in fact, there are entire villages within the confines of these huge parks. These areas are often shown on New York State maps with a blue outline - in fact, the Blue Line is the conventional name for the boundary. Mostly within these areas, and sometimes but not always coterminous with them, are a collection of Wilderness Area, Wild Forest, State Reforestation Area, Wildlife Management Area, Canoe Area, Primitive Bicycle Corridor, State Campground, State Unique Area, and so on, that are actually State-owned lands allowing public access for different types of activity. There are also similar conserved lands outside the Adirondack and Catskill Parks. Certainly in the Catskills, and likely elsewhere, there are Wild Forest and State Reforestation Area parcels that cross the Blue Line. Entirely separate from this system and administered by a different arm of the State government are a set of State Park, State Historic Site, State Recreation Area, and so on. These range from sites that would be best described as recreation ground to backcountry preserves that take days to hike across. There is a possible administrative hierarchy here, too: for instance, the Anthony Wayne recreation area is entirely within the confines of the Harriman State Park. What's the point of all this? Merely to indicate that the tagging scheme: - most likely ought not to presume that all 'state parks' are entirely state-owned: in New York, the two large parks are partially private, and the public's right of access varies. - must not assume that state parks do not overlap, nor that overlap among them is a strict containment relationship. - must not assume that a state park has a single purpose (e.g., leisure=nature_reserve): many of New York's large state parks contain campgrounds, youth camps, recreation grounds, swimming beaches, and other developed amenities as well as large tracts of backcountry reserve. By the way, these lands must not be dismissed as insignificant: the Adirondack park is larger than Yellowstone, Glacier, Cascade, and Everglades National Parks - combined. The Catskill Park is about of a size with the larger National Parks. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Park Boundary tagging
While Greg describes what might be, I'll describe what is. I'm only scratching a surface or two as I do. I described uploading both Forest Service boundaries for National Forests and Wilderness areas. As we were using USFS data from a particular source: source=http://fsgeodata.fs.fed.us/vector/lsrs.php For Wilderness, these tags: leisure=nature_reserve boundary=national_park boundary:type=protected_area protect_class=1b protection_title=Wilderness ownership=national And change WILDERNE_1 tag to: name=Name of Wilderness For National Forests, these tags: landuse=forest boundary=national_park boundary:type=protected_area protect_class=6 protection_title=National Forest ownership=national Adding a tag like: park:type=national_forest;wilderness is optional, but park:type is a tag gaining widespread use (starting in California) to distinguish between national_forest, state_park, state_beach, county_park, city_park, etc. When doing this, use the correct value, with underscores for spaces, and separating with semicolon any conflated areas (such as national_forest and wilderness). For example, you might add (for a National Grassland): park_type=national_grassland I suggest that the tags for parks/etc. be defined so that if there are no boundary tags, everything still makese sens. (I'll further suggest that once this is done, there is no need for boundary tags.) I'm OK with positing that we need not use the boundary tag. But then what will render a boundary, if any? Yes, we can point to mapnik rules that say if name key of a polygon or multipolygon = a value, display it being the reason that you see black text saying Sequoia National Park. But it is key=value pair boundary=national_park that renders pretty green text out to z=6. We also notice that if leisure=park mapnik renders a nice light-green fill color or if landuse=forest we get dark-green with little trees. Likewise leisure=nature_reserve gives us the little NR overlay. Yes, landuse=forest (on national forest) and leisure=nature_reserve (on wilderness) yields dark-green + NR (to pleasing effect) and well-represents a wilderness inside of a national forest. But the edge between these is difficult to see without a boundary (=national_park) tag. So, I like using it, and think it is a good idea to do so, as it sharpens that boundary where it is appropriate to see that boundary. But I am open to better tags to achieve these or similar desired results. landuse=conservation (because at least a co-primary purpose is to preserve the land for the future, and usually this is primary.) leisure=nature_reserve (because a co-primary, but really not quite-as-high-as-conservation is to allow access to the public) The landuse and leisure keys are separate, and they have multiple possible values. Before we get into the specifics (or maybe AS we get into them, so that we may untangle them properly) let us ask first if there are any mutually exclusive values. Then we get into tags that refer to the administrator of an area. I will temporarily ask us to conflate administrator into administrator + operator + ownership as it may be possible that we can agree upon certain tag groups for certain semantically identical objects. (Though I could be wrong). Tangled up is admin_level but that may (strongly?) imply boundary=administrative. I'd like to see what happens with mapnik rendering when admin_level is used with other boundary values, like boundary=national_park. Maybe I'll play a bit with some boundary values and admin_levels, non-destructively of course. I just want to see what mapnik is doing, vs. what we mean to happen. And of course name of the park. Agreed, this seems fairly straightforward as a text string in the name= key. Just a caution that what paints the name of an object (polygon, multipolygon) might be distinct from what its boundary tags (if any) do. My bias is that the nature of the land use is more important than the identity of the manager. Another similar area is a wildlife refuge. Ones that allow humans are perhaps appropriately tagged as above. Ones that do not allow humans as perhasp landuse=conservation and some other special wildlife_refuge tag. So, a short catalog for possible tags to untangle semantics regarding parks: landuse [forest, wood, conservation...] leisure [park, nature_reserve...] name=[Text String for name of park] boundary=[administrative, national_park] boundary:type=[protected area] protect_class=[many alphanumeric values possible, among them 1b=US Wilderness, 6=US National Forest) protection_title=[] ownership=[national, state, county, city, neighborhood_association, private] park:type=[state_park, county_park, city_park, private_park, state_beach, county_beach, national_forest, national_wilderness, state_wilderness, national_monument, state_historic_monument, many others] I already see a slight problem with
Re: [Talk-us] Park Boundary tagging
Most know this, but it can't hurt to point out some distinctions. When I say semantic(s) I mean what we wish to convey. Or, higher-level meaning. When I say syntax I mean how we say it; the grammar and characters we type to utter it in a well-formed way. Here, it is a particular semantic thing to convey. So, semantic structures include: various ways humans use land and groupings of vegetative or rocky/sandy/muddy/watery land coverings and category-names that political bodies give to areas of land for human, plant or animal conservation Syntactic structures include: The : as a way for the more general tag park (not used as an OSM key to the best of my knowledge) to be extended into park:type as the name of a key holding values like county_park or state_wilderness. Grouping, in general. So, landuse=[farm, forest, meadow, industrial...] is a syntactic structure for putting RELATED things into a container that holds them, BECAUSE they are related. Numbering, but with some careful distinctions: integers used as values in a key-value pair are syntax, AND have semantic meaning. An example: 2, 4, 6 and 8 are admin_level values to mean nation, state, county and city. The numbers in the key-value pair are syntax, but what they mean are semantic. Also helpful to keep in mind is the concept of a rendering toolchain that starts with a semantic idea in the mind of a human (I want to see Acme Park on the map), this falls into one (and should be only one) semantic bucket of means this and only this, this gets turned into a syntactic sentence (grammatically correct in OSM-speak), like landuse=forest + name=Acme Park as tags on a simply polygon, this utterance goes through some behind-the-scenes server magic (like how osm2pgsql allows OSM - PostgreSQL - mapnik) and eventually Acme appears as named, colored park on rendered map. Item in real world - sensible semantic object - syntactic OSM utterance - toolchain - map rendering. Again, I know it may be obvious, but we are talking about many things on many levels here. This is a useful hierarchy/nomenclature, and these paths really do exist. Let's try to keep them straight. SteveA California ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
