Re: [talk-ph] armchair mapping Quiapo area
Dear everyone, The initial tracing for Quiapo Church is done [0]. Thanks to caior and ianlopez1115 for helping out. Our partner decided to extend the mapping to the neighboring parishes around Quiapo. I created another task [1] for this extending the area to Binondo and San Miguel districts. You can read the tutorial on how to use the tasking manager here [2] As always we appreciate any help. Thanks. [0] http://tasks.hotosm.org/job/52 [1] http://tasks.hotosm.org/job/56 [2] https://wiki.openstreetmap.org/wiki/OSM_Tasking_Manager On Mon, Sep 3, 2012 at 5:39 PM, maning sambale emmanuel.samb...@gmail.com wrote: Dear everyone, We have finished the initial pass of road, waterway and building tracing over Quiapo area. Thanks to caior for helping out. We will verify and validate the data with the local community by Thursday (September 6). We still need your help in validating the individual job task via the Tasking Manager. http://tasks.hotosm.org/job/52 The purpose of validating a task is to confirm that the task has been mapped according to the job description. If you are happy the task has been mapped correctly then click the validate button. More instructions on validating is here: https://wiki.openstreetmap.org/wiki/OSM_Tasking_Manager#Validating_a_task Thanks again! On Thu, Aug 30, 2012 at 12:05 PM, maning sambale emmanuel.samb...@gmail.com wrote: Dear everyone, In preparation for mapping next week in Quiapo, may I request everyone to help in the preliminary mapping of the area? I created a task job using the HOT Tasking Manager. The link is here: http://tasks.hotosm.org/job/52 A tutorial on how to use the Tasking Manager here: https://wiki.openstreetmap.org/wiki/OSM_Tasking_Manager Priorities for mapping are roads, waterways/estero and buildings. We will add more attributes in the map during the field mapping activities. Advance thank you to all! -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] bikeToWork
That seems fine to me. Cheers, Jo Op 24 september 2012 16:02 schreef Sander Deryckere sander...@gmail.comhet volgende: On the site http://www.biketowork.be, the tiles of OSM are used, but Georges noticed that there is no mention of OSM. So I'm planning of sending them the following mail in the name of OSM Belgium: Beste, Het is duidelijk dat jullie site (http://www.biketowork.be) gebruik maakt van OpenStreetMap data, via tiles die rechtstreeks van de osm.orgwebsite genomen zijn. Wij danken je voor het gebruik van onze data, maar helaas is er nergens een vermelding van OpenStreetMap, terwijl dit volgens onze licentie verplicht is. Volgens de richtlijnen gegeven op osm.org/copyright/enhttp://www.openstreetmap.org/copyright/enis het voldoende om, op een plaats waar gebruikers dit verwachten, de tekst © OpenStreetMap contributors, met een link naar http://osm.org/copyright te zetten. Mogen wij u vragen om de website aan te passen? Mvg, OpenStreetMap Belgium Is this good? 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
[OSM-talk-be] BikeToWork, OpenStreetMap kaart
Beste, Het is duidelijk dat jullie site (http://www.biketowork.be) gebruik maakt van OpenStreetMap data, via tiles die rechtstreeks van de osm.org website genomen zijn. Wij danken je voor het gebruik van onze data, maar helaas is er nergens een vermelding van OpenStreetMap, terwijl dit volgens onze licentie verplicht is. Volgens de richtlijnen gegeven op osm.org/copyright/enhttp://www.openstreetmap.org/copyright/enis het voldoende om, op een plaats waar gebruikers dit verwachten, de tekst © OpenStreetMap contributors, met een link naar http://osm.org/copyrightte zetten. Mogen wij u vragen om de website aan te passen? Mvg, Sander Deryckere, in naam van OpenStreetMap Belgium ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
[OSM-talk-be] Knooppuntennetwerken
Ik kom bij het nakijken en corrigeren van de knooppuntennetwerken mappers tegen die andere opvattingen hebben over het mappen van knooppuntennetwerken, dan wat ik hierover geleerd heb. Aangezien het bevorderlijk zou zijn, dat we allemaal op dezelfde manier mappen, zou ik willen vragen om uw mening hierover te geven op deze wiki-overlegpagina: http://wiki.openstreetmap.org/wiki/Talk:Cycle_Node_Network_Tagging mvg, Polyglot ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Routing view
For major roads : I fixed the rest of the unconnected roads in Belgium, and some in NL and FR. http://tools.geofabrik.de/osmi/?view=routinglon=5.02744lat=50.79917zoom=9overlays=unconnected_major1,unconnected_major2,unconnected_major5 I begin now for minor roads... I work first around my zone : Charleroi. You see the work for Belgium... I come back to you at 2014... If someone could also work on this project, I would be pleased... Thanks to Maarten. @+ __Teddy__ 2012/9/13 Jo winfi...@gmail.com 2012/9/13 Maarten Deen md...@xs4all.nl On 2012-09-13 12:10, Joren DC wrote: I fixed almost all problems in the state Antwerp. I only have 4 red dots left. Can somebody take a look at this strange situation: http://tools.geofabrik.de/**osmi/?view=routinglon=4.** 47035lat=51.38314zoom=16**overlays=unconnected_major1,** unconnected_major2,**unconnected_major5http://tools.geofabrik.de/osmi/?view=routinglon=4.47035lat=51.38314zoom=16overlays=unconnected_major1,unconnected_major2,unconnected_major5 [6] I don't know how to solve it, and what happened to the roads. It is just as the OSM inspector indicated: the roads were close to eachother but not connected. In addition, De Eendracht had an extra node which made the way overlap itself. In JOSM these things are easy to fix: select the two nodes and merge them. It's now fixed. I also fixed the development tags. General use for roads that are not there yet is highway=construction and construction=living_street (or whatever tag the highway tag is going to get) I tried to fix it too and got many conflicts. You're too fast for me, Maarten :-) I must be getting old. Cheers, Polyglot ___ 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] Routing view
Hi, I fixed whole province Antwerp a while ago. I'll take sometimes a look, to see if there is not a conflict in my zone. I'll also look at the minor roads, in Antwerp. Kind regards, Joren Op 25/09/12 15:04, Teddy schreef: For major roads : I fixed the rest of the unconnected roads in Belgium, and some in NL and FR. http://tools.geofabrik.de/osmi/?view=routinglon=5.02744lat=50.79917zoom=9overlays=unconnected_major1,unconnected_major2,unconnected_major5 I begin now for minor roads... I work first around my zone : Charleroi. You see the work for Belgium... I come back to you at 2014... If someone could also work on this project, I would be pleased... Thanks to Maarten. @+ __Teddy__ 2012/9/13 Jo winfi...@gmail.com mailto:winfi...@gmail.com 2012/9/13 Maarten Deen md...@xs4all.nl mailto:md...@xs4all.nl On 2012-09-13 12:10, Joren DC wrote: I fixed almost all problems in the state Antwerp. I only have 4 red dots left. Can somebody take a look at this strange situation: http://tools.geofabrik.de/osmi/?view=routinglon=4.47035lat=51.38314zoom=16overlays=unconnected_major1,unconnected_major2,unconnected_major5 [6] I don't know how to solve it, and what happened to the roads. It is just as the OSM inspector indicated: the roads were close to eachother but not connected. In addition, De Eendracht had an extra node which made the way overlap itself. In JOSM these things are easy to fix: select the two nodes and merge them. It's now fixed. I also fixed the development tags. General use for roads that are not there yet is highway=construction and construction=living_street (or whatever tag the highway tag is going to get) I tried to fix it too and got many conflicts. You're too fast for me, Maarten :-) I must be getting old. Cheers, Polyglot ___ Talk-be mailing list Talk-be@openstreetmap.org mailto: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] Routing view
Hi, I fixed a lot of conflicts in Vlaams Brabant: arround Tienen, Landen, Zoutleeuw, St Truiden. Guy Vanvuchelen Van: Joren DC [mailto:joren.libreoff...@telenet.be] Verzonden: dinsdag 25 september 2012 15:22 Aan: talk-be@openstreetmap.org Onderwerp: Re: [OSM-talk-be] Routing view Hi, I fixed whole province Antwerp a while ago. I'll take sometimes a look, to see if there is not a conflict in my zone. I'll also look at the minor roads, in Antwerp. Kind regards, Joren Op 25/09/12 15:04, Teddy schreef: For major roads : I fixed the rest of the unconnected roads in Belgium, and some in NL and FR. http://tools.geofabrik.de/osmi/?view=routing http://tools.geofabrik.de/osmi/?view=routinglon=5.02744lat=50.79917zoom= 9overlays=unconnected_major1,unconnected_major2,unconnected_major5 lon=5.02744lat=50.79917zoom=9overlays=unconnected_major1,unconnected_maj or2,unconnected_major5 I begin now for minor roads... I work first around my zone : Charleroi. You see the work for Belgium... I come back to you at 2014... If someone could also work on this project, I would be pleased... Thanks to Maarten. @+ __Teddy__ 2012/9/13 Jo winfi...@gmail.com 2012/9/13 Maarten Deen md...@xs4all.nl On 2012-09-13 12:10, Joren DC wrote: I fixed almost all problems in the state Antwerp. I only have 4 red dots left. Can somebody take a look at this strange situation: http://tools.geofabrik.de/osmi/?view=routing http://tools.geofabrik.de/osmi/?view=routinglon=4.47035lat=51.38314zoom= 16overlays=unconnected_major1,unconnected_major2,unconnected_major5 lon=4.47035lat=51.38314zoom=16overlays=unconnected_major1,unconnected_ma jor2,unconnected_major5 [6] I don't know how to solve it, and what happened to the roads. It is just as the OSM inspector indicated: the roads were close to eachother but not connected. In addition, De Eendracht had an extra node which made the way overlap itself. In JOSM these things are easy to fix: select the two nodes and merge them. It's now fixed. I also fixed the development tags. General use for roads that are not there yet is highway=construction and construction=living_street (or whatever tag the highway tag is going to get) I tried to fix it too and got many conflicts. You're too fast for me, Maarten :-) I must be getting old. Cheers, Polyglot ___ 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 _ Geen virus gevonden in dit bericht. Gecontroleerd door AVG - www.avg.com Versie: 2012.0.2221 / Virusdatabase: 2441/5290 - datum van uitgifte: 09/24/12 _ I am using the Free version of SPAMfighter http://www.spamfighter.com/len . SPAMfighter has removed 725 of my spam emails to date. Do you have a slow PC? http://www.spamfighter.com/SLOW-PCfighter?cid=sigen Try free scan! ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] Bad (wrong?) OSM publicity?
Hi, 1) Is Apple using OSM data for Japan? - Apple is using little bit of OSM data in Japan. Mainly they are using iPC data and original data by tracing. That is hybrid data set. ex. leisure=park https://www.facebook.com/photo.php?fbid=505426332819676set=a.313949581967353.87430.10569420263type=1 2) If they are, I can't believe this is a correct statement. I thinks so, Mr. Yamagishi should explain about iPC data and apple's original data. We have strong relationship to Mapion. I have already started to talk with members of Mapion. Regards, from Taichi 2012/9/25 maning sambale emmanuel.samb...@gmail.com For reference: Shinjuku in iOS6 Maps - http://theamazingios6maps.tumblr.com/post/31930288525/shinjuku-station-the-busiest-train-station-in-the in OSM - http://www.openstreetmap.org/?lat=35.689408lon=139.700825zoom=18layers=M I don't think Apple's Maps is using OSM. In addition, they also didn't use OSM in the Philippines. On Tue, Sep 25, 2012 at 1:37 PM, Pēteris Krišjānis pec...@gmail.com wrote: Sounds like nice smear from competition, except it can be truth and wrong in same time - it's very old data, first, it's not all OSM. Nice try tough. Peter. P , 2012-09-24 23:32 -0600, Martijn van Exel rakstīja: From https://www.nytimes.com/2012/09/25/technology/apple-maps-errors-send-japanese-to-homegrown-app.html?emc=tnttntemail0=y_r=0moc.semityn.www The biggest problem with Apple’s map, Mapion’s Mr. Yamagishi said, is that much of its data appears to be drawn from OpenStreetMap Japan, a Wikipedia-like service that contains a lot of incorrect and outdated information. 1) Is Apple using OSM data for Japan? 2) If they are, I can't believe this is a correct statement. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- ## Taichi FURUHASHI(MAPconcierge Inc. President) ## MAPconcierge satellite office at http://goo.gl/VgWD6 in NOMAD NEW'SBASE ## Vice-President of OpenStreetMap Foundation Japan with sinsai.info project ## Director of the OSGeo Foundation Japan ## Researcher of the center for spatial info. science, univ.of Tokyo ## TEL/SkypeTwitterLIFB: 070-6401-5963 / http://about.me/mapconcierge ## URL/Mail: http://www.mapconcierge.jp tai...@mapconcierge.jp ## GPS/GigaPan/UAV Shop: http://gpsconcierge.jp ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
Hi all, I also agree with the opinion of Taichi-san. The Japanese famous incorrect case is, for example Se Den Koku Ku Ritsu Ou Taku To Sho Kan. http://tosseto.info/blog/wp-content/uploads/1fce26a763cfad94eef6cc8f77c0fee2.png This place is the public library of Setagaya (Okusawa blanch), of cource OSM is correct information. http://www.openstreetmap.org/browse/node/1420766049 http://www.openstreetmap.org/?lat=35.603596lon=139.672736zoom=18layers=M Additionally, this bug is not included iPC (one of the Japanese map agency), I guess. I think, we are continue to compare to Apple's map and OSM data and we need to certificate the correctness of the OSM data other place. 2012/9/25 Taichi Furuhashi tai...@osmf.jp: Hi, 1) Is Apple using OSM data for Japan? - Apple is using little bit of OSM data in Japan. Mainly they are using iPC data and original data by tracing. That is hybrid data set. ex. leisure=park https://www.facebook.com/photo.php?fbid=505426332819676set=a.313949581967353.87430.10569420263type=1 2) If they are, I can't believe this is a correct statement. I thinks so, Mr. Yamagishi should explain about iPC data and apple's original data. We have strong relationship to Mapion. I have already started to talk with members of Mapion. Regards, from Taichi 2012/9/25 maning sambale emmanuel.samb...@gmail.com For reference: Shinjuku in iOS6 Maps - http://theamazingios6maps.tumblr.com/post/31930288525/shinjuku-station-the-busiest-train-station-in-the in OSM - http://www.openstreetmap.org/?lat=35.689408lon=139.700825zoom=18layers=M I don't think Apple's Maps is using OSM. In addition, they also didn't use OSM in the Philippines. On Tue, Sep 25, 2012 at 1:37 PM, Pēteris Krišjānis pec...@gmail.com wrote: Sounds like nice smear from competition, except it can be truth and wrong in same time - it's very old data, first, it's not all OSM. Nice try tough. Peter. P , 2012-09-24 23:32 -0600, Martijn van Exel rakstīja: From https://www.nytimes.com/2012/09/25/technology/apple-maps-errors-send-japanese-to-homegrown-app.html?emc=tnttntemail0=y_r=0moc.semityn.www The biggest problem with Apple’s map, Mapion’s Mr. Yamagishi said, is that much of its data appears to be drawn from OpenStreetMap Japan, a Wikipedia-like service that contains a lot of incorrect and outdated information. 1) Is Apple using OSM data for Japan? 2) If they are, I can't believe this is a correct statement. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- ## Taichi FURUHASHI(MAPconcierge Inc. President) ## MAPconcierge satellite office at http://goo.gl/VgWD6 in NOMAD NEW'SBASE ## Vice-President of OpenStreetMap Foundation Japan with sinsai.info project ## Director of the OSGeo Foundation Japan ## Researcher of the center for spatial info. science, univ.of Tokyo ## TEL/SkypeTwitterLIFB: 070-6401-5963 / http://about.me/mapconcierge ## URL/Mail: http://www.mapconcierge.jp tai...@mapconcierge.jp ## GPS/GigaPan/UAV Shop: http://gpsconcierge.jp ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Toshikazu SETO Postdoctoral Fellow Ritsumeikan University e-mail: t...@lt.ritsumei.ac.jp / toss...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
Here in France, we can read similar complains about poor quality Apple's iOS6 map data coming from OSM ! A lot of people are convinced that the bad state of the Apple data is related to the usage of source like OSM... But it seems that Apple is using very few, perhaps nothing from OSM for the french area, even more, if they have used OSM data the quality of their maps would have increased ! Vlad. On 25 sept. 2012, at 07:32, Martijn van Exel m...@rtijn.org wrote: From https://www.nytimes.com/2012/09/25/technology/apple-maps-errors-send-japanese-to-homegrown-app.html?emc=tnttntemail0=y_r=0moc.semityn.www The biggest problem with Apple’s map, Mapion’s Mr. Yamagishi said, is that much of its data appears to be drawn from OpenStreetMap Japan, a Wikipedia-like service that contains a lot of incorrect and outdated information. 1) Is Apple using OSM data for Japan? 2) If they are, I can't believe this is a correct statement. -- martijn van exel http://oegeo.wordpress.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
This is a game anybody can play. Could you we collect a couple of (best well known places) examples of iOS maps and how good they would have looked if they had really used OSM data, and forward them to the CWG (it probably takes too long to whip up a Apple look a like style in Tilemill or Maperitive, but that would make it even better)? They may whip up a blog post or similar. Simon Am 25.09.2012 10:57, schrieb Vladimir Vyskocil: Here in France, we can read similar complains about poor quality Apple's iOS6 map data coming from OSM ! A lot of people are convinced that the bad state of the Apple data is related to the usage of source like OSM... But it seems that Apple is using very few, perhaps nothing from OSM for the french area, even more, if they have used OSM data the quality of their maps would have increased ! Vlad. On 25 sept. 2012, at 07:32, Martijn van Exel m...@rtijn.org wrote: From https://www.nytimes.com/2012/09/25/technology/apple-maps-errors-send-japanese-to-homegrown-app.html?emc=tnttntemail0=y_r=0moc.semityn.www The biggest problem with Apple’s map, Mapion’s Mr. Yamagishi said, is that much of its data appears to be drawn from OpenStreetMap Japan, a Wikipedia-like service that contains a lot of incorrect and outdated information. 1) Is Apple using OSM data for Japan? 2) If they are, I can't believe this is a correct statement. -- martijn van exel http://oegeo.wordpress.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
The biggest problem with Apple’s map, Mapion’s Mr. Yamagishi said, is that much of its data appears to be drawn from OpenStreetMap Japan, a Wikipedia-like service that contains a lot of incorrect and outdated information. I'd like to know what the hell the New York Times is doing allowing these sorts of ignorant comments to get published. Nick ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple Layers for OSM
This is nice, in my manifesto I even have an item on supporting research in to some kind of layer functionality, and now the discussion has started on its own :-). My thoughts - GIS-like layers are a no no, they increase dependencies in the data and we want to achieve the opposite. - any implementation will have to conserve the most scarce resource we have: developer time. This applies equally to core infrastructure as to the myriad of tools and editors. - at least for any layers/databases operated by the OSMF we should not depart from the any user can edit anything principle. - any implementation should a allow conflict free merging of data and synchronizing of data from multiple sources IMHO the easiest, but very hackish, way to achieve this would be to split the (64bit) object ID space up in to sub-spaces (a la CIDR). All tools will have to support 64bit IDs rsn and we are currently throwing away half of the ID space for no real good reason except convenience. The main concern is that 64bits may not be enough ID space long term: for example 63 bits for OSM proper would allow ~18'000 nodes per square meter of the earth's surface (~62'000 without oceans), which may not be enough for detailed multi-storey indoor mapping :-). Such a scheme would not preclude switching to larger IDs down the road (the ID size is essentially just a practical limitation of the databases and tools we are currently using) the individual layers would simply get non-continuous ID spaces allocated if necessary . Simon PS: all calculations errors etc are mine :-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [possibly OT] Apples IOS 6 Maps and the response
On 22 September 2012 15:18, Lester Caine les...@lsces.co.uk wrote: I feel we should all be pressing to Apple to produce an overview of the sources of the data on their 'mashup'. My son has a copy and it does seem that you can 'easily see the joins' between different sources, but identifying what data IS attributable to OSM seems difficult? And where other data comes from. +1 this mashup of theirs without clear explanation on which data is coming from where is creating some bad publicity for openstreetmap . I hope atleast some volunteers who havse ios6 can check and report their countries/regions are carrying/not carrying OSM data . What about the license ? Does no one bother about it anymore ? Regards, Pavithran -- pavithran sakamuri http://look-pavi.blogspot.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Any OSM social activities in Europe in the next 2 weeks?
If you were in London on a week day evening you might get the pub meet moved to coincide with a visit (they sometimes do for me!). Harry Wood or @OSMLondon are the ones to contact to ask about meetups there. If you're passing through well mapped areas or places with strong OSM communities, you might want to try Guerilla Mapping. http://www.livingwithdragons.com/2010/09/guerilla-mapping Enjoy your trip to Europe, next time you should visit North East England! On 21 September 2012 11:55, Michael Kugelmann michaelk_...@gmx.de wrote: Hello Toby, I'm about to leave for a 2 week trip to Europe and wondered if there were any local OSM gatherings I could drop in on. the only general hint that I can provide is to have a look at the calender in the wiki: http://wiki.openstreetmap.org/**wiki/Template:Calendarhttp://wiki.openstreetmap.org/wiki/Template:Calendar A lot of regular meetings e.g. in Germany are listed there. Best regards, Michael. __**_ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk -- Gregory o...@livingwithdragons.com http://www.livingwithdragons.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
I think that even the image of the week on the wiki is somewhat misleading http://wiki.openstreetmap.org/wiki/Iotw (Apple showing possibly OSM on their new map application on iOS 6.) ok there is the possibly but still ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
Is there a way to see Apple maps if you don't have an iphone? Janko ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
2012/9/25 eMerzh merz...@gmail.com: I think that even the image of the week on the wiki is somewhat misleading http://wiki.openstreetmap.org/wiki/Iotw (Apple showing possibly OSM on their new map application on iOS 6.) ok there is the possibly but still Yes, maybe we could remove the possibly? It contains definitely OSM, or is there anybody who thinks that having the same street with the strange name Muncipal Road; Post Office Road; Muncipal Road could also be a coincidence? ;-) cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
You can use the iOS simulator from Xcode if you have a Mac… or at least Mac OS X. ;) /Joakim On 25 sep 2012, at 14:41, Janko Mihelić jan...@gmail.com wrote: Is there a way to see Apple maps if you don't have an iphone? Janko ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
OpenStreetMap Japan, a Wikipedia-like service that contains a lot of incorrect and outdated information. that is really awful. We can't let that kind of statement stand! It affects the credibility of all OSM efforts, and is like the kind of FUD Wikipedia saw early on. Any possibility of getting a retraction? Though really that doesn't even cover it. Some kind of very public rebuttal. jeff On Tue, Sep 25, 2012 at 11:51 AM, Joakim Fors joa...@joakimfors.org wrote: You can use the iOS simulator from Xcode if you have a Mac… or at least Mac OS X. ;) /Joakim On 25 sep 2012, at 14:41, Janko Mihelić jan...@gmail.com wrote: Is there a way to see Apple maps if you don't have an iphone? Janko ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
2012/9/25 Joakim Fors joa...@joakimfors.org: You can use the iOS simulator from Xcode if you have a Mac… or at least Mac OS X. ;) AFAIK you need at least OS X 10.7. I got recently an old Mac Book (2006) which would probably be sufficiently performant but Apple decided that you cannot install their newer OS on it. So I also can't install a recent XCode onto it... cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
Richard Fairhurst wrote: bot_source_licence=machine-readable licence name ... - encouraging a machine-readable licence tag helps to avoid the issues identifying changesets that were encountered in the redaction. I don't like the name of this tag, it seems ambiguous. From it's name I would guess that it's the license for the source code of the bot itself, but your description suggest it's meant for the data. In that case I would suggest using simple source_license (or source:license ?) or something similar, the bottom line is that the word bot should not be used. Best regards, Petr Morávek aka Xificurk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
I think the additional tags on the changeset are a good approach... and when used properly they make the dedicated account useless (whatever the size of the changeset) as they provide much more details. The API could even reject changesets that are above a given size if these tags are not present. The tag names should not be too much bot related. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
From the thread it appears OSM is not the culprit of bad data, at least in many cases. Nonetheless it certainly makes sense thinking about data accuracy. I am not aware of a widespread organized system of making sure OSM data is up to date. We know the time of the last change to a feature. It might be a good idea to have a way of stating a feature remains valid (and placing a time stamp on it). The easiest thing to do would be add a tag like validated::MM:DD. There could also be a web map that loads an area of data and lets a user mark the features as valid or label them for fixing (at which point an editor could open or a marker tag could be set). When a feature is overdue to be validated, it can be highlighted on the map so the user knows it should be checked. Features of different types have different lifetimes. Businesses can change very often, whereas something like the ocean is less likely to change month to month (well, in a way significant for mapping). Different feature types can given different timeouts before they are flagged as overdue of validation. This is not a complete solution. It would also be nice to be able to validate the absence of something. Suggestions? At the very least, this would give mappers something to do once their local area runs out of necessary edits. Dave On Mon, Sep 24, 2012 at 10:32 PM, Martijn van Exel m...@rtijn.org wrote: From https://www.nytimes.com/2012/09/25/technology/apple-maps-errors-send-japanese-to-homegrown-app.html?emc=tnttntemail0=y_r=0moc.semityn.www The biggest problem with Apple’s map, Mapion’s Mr. Yamagishi said, is that much of its data appears to be drawn from OpenStreetMap Japan, a Wikipedia-like service that contains a lot of incorrect and outdated information. 1) Is Apple using OSM data for Japan? 2) If they are, I can't believe this is a correct statement. -- martijn van exel http://oegeo.wordpress.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
On Tue, Sep 25, 2012 at 06:11:35PM +0100, Richard Fairhurst wrote: [...] An 'automated edit' is one where the editing is not carried out by manual drawing actions. This includes (but is not limited to): - imports of external data - search-and-replace tag changes - automated geometry fixup - reverting edits and applies equally to scripted edits and to those carried out within an editor program. [...] What exactly is meant with reverting edits? Bringing back deleted objects in Potlatch is something I have done during normal OSM editing. Thats certainly not an automated edit. I think it is rather difficult do exactly define what an automated edit is and what not. And trying to define this better and better is just an invitation to language lawyers to argue about minutiae. I suggest we have an example section in this policy document that describes several common cases that are and several that aren't automated edits. Thats easier for most people to understand than complex rules. And the policy should have a clear guideline on what to do if you think your case falls into the grey area between those cases. Something like this: If you are unsure whether something you want to do falls under this 'automated edit' guideline we encourage you to discuss your case on the mailing list at ... or ... . If you can not get the information you need from there you can also contact the Data Working Group at ... Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple Layers for OSM
Matt Amos wrote: On Mon, 2012-09-24 at 09:36 +0200, Jochen Topf wrote: It turns out there are many other interesting uses of multiple layers but also many technical and social questions around them. I have written down my thoughts on this subject in a (rather lengthy) blog post: http://blog.jochentopf.com/2012-09-23-multiple-layers-for-osm.html what do you think of the Potlatch 2 vector backgrounds [1] and snapshot server [2] as steps in the direction of fixing this? [1]http://wiki.openstreetmap.org/wiki/Potlatch_2_merging_tool [2]http://wiki.openstreetmap.org/wiki/Snapshot_Server Certainly the 'problem' can be broken down into several elements. The editing tools certainly have most of what is needed to display multiple layers, and merge data between layers. JOSM is obviously geared to handling multiple layers and it looks like potlatch2 is heading down the same path? But what is really needed is a viewer that can combine layers from different sources in the same way? Problem here is I think that it does need to be able to handle vector as well as raster layers? But isn't that what http://layers.openstreetmap.fr/ does anyway? So IS there any development work needed here? Other than making the base layers and overlays configurable? I'd like to set up my own 'server' although 'rails' puts me off as it's something else I'd have to learn. Being PHP based, having to cope with java and python simply to repair the tools I'm using is bad enough! I've been running mapserver for years so perhaps I need to look at that, or is there an alternatively? OK LAYERS http://wiki.openstreetmap.org/wiki/OSM_Layers lists 'pluses and minuses' but I'm not sure I agree with many of the points on that. http://blog.jochentopf.com/2012-09-23-multiple-layers-for-osm.html seems more down the right line. Lets split the problem into three. Private secondary layers simply need to be geo-referenced and perhaps provide a 'limit' to the pan function? This is just a rendering problem in the viewer. An example of this would be 'bird-migrations' overlay which would not use ways and nodes from the base layers. Public secondary layers would be such things as 'low water/highwater/marine' or 'contour' which are essentially ways that do not 'naturally' need to be constructed using the SAME way segments that construct the main map data. Actually I don't see the advantage of splitting up even border ways into hundreds of small segments simply because a border segment may consist of numerous small bits of existing ways? A boundary like 'The cotswolds' is to my mind a complete nightmare to edit and consists of hundreds of 'little fixes' to join up elements that don't naturally join themselves. So I think that boundaries fit more naturally at this level with their own ways! The base map is essentially a single layer, and some of the 'Why have layers' points simply require improved filtering of the data. Perhaps only downloading a subset of the raw data. Much as the renderers only display selective subsets. Import datasets are essentially stand alone base map layers from which data is either extracted and merged directly, or just used as a tracing source. Having said that boundaries should have their own ways, I don't see any problem with the likes of JOSM importing from several layers and managing those layers 'in parallel' rather than flattening to a single layer. One can switch layers on and off easily, and perhaps tag between layers where track details should be locked between 'layers' so that editing can handle changes that need to affect all layers using the SECTIONS of the same way. The important thing to bear in mind here is Do you actually ALLOW editing of the details of an import? While we may be able to provide updates in advance of that appearing in a later import, retaining the historic data may be better managed by tagging the relevant elements of an update as 'end_date=xxx' and adding new segments that provide the correction. THIS also fits in better with also maintaining the fine detail underlying a change ... but begs the question 'is this a fix to faulty data' or @an historic change to the object' While I accept that the change log does maintain this data, accessing it can be problematic, while a major API change may be that 'delete' simply mirrors the details to the 'historic' database with the correct end_date flag, and changes to details result in a copy of the original being archived. Having just written that, I am thinking that we need two mechanisms for this. One takes everything flagged with a end_date and moves it to a linked historic database, while the other simply adds the correct end_date flag. SO for border layers you have the option to select a date - past or future - for the rendering we want? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk
Re: [OSM-talk] Multiple Layers for OSM
On Tue, Sep 25, 2012 at 12:38:20PM +0200, Simon Poole wrote: IMHO the easiest, but very hackish, way to achieve this would be to split the (64bit) object ID space up in to sub-spaces (a la CIDR). All tools will have to support 64bit IDs rsn and we are currently throwing away half of the ID space for no real good reason except convenience. The main concern is that 64bits may not be enough ID space long term: for example 63 bits for OSM proper would allow ~18'000 nodes per square meter of the earth's surface (~62'000 without oceans), which may not be enough for detailed multi-storey indoor mapping :-). Such a scheme would not preclude switching to larger IDs down the road (the ID size is essentially just a practical limitation of the databases and tools we are currently using) the individual layers would simply get non-continuous ID spaces allocated if necessary . Currently the IDs are rather dense in the ID space. (There are holes from deleted objects, but not that many.) This is a very good thing, because it allows efficient implementations, for instance all node locations can be put into an array which needs only 8 bytes * max_node_id. If you give out part of the ID space to different databases this approach does not work any more. Thats not the end of the world, but we have to really start looking into the consequences of these kinds of decisions because we are not a small database any more... Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple Layers for OSM
Hi! Using GUIDs is problematic because they are so large (compared to a simple ID) and the GUIDs are not dense in the GUID space. This would probably mean another redirection when finding data inside an application. Jochen On Mon, Sep 24, 2012 at 11:31:55PM +0700, Jais Pedersen wrote: Date: Mon, 24 Sep 2012 23:31:55 +0700 From: Jais Pedersen j...@pedersens.net To: talk@openstreetmap.org Subject: Re: [OSM-talk] Multiple Layers for OSM Or we could use GUIDs, but if we use the linking approach, then each layer could have its own IDs and if the links are implemented as tags would it be possible to do it without changes to the API? /Jais On Mon, Sep 24, 2012 at 11:11 PM, Dave Sutter sut...@intransix.com wrote: This is a very interesting thread and I need a little more time to understand what is in it so far. I do want to make one technical comment. It is possible to to have multiple databases and still have unique IDs across them. An ID server can be set up to create the IDs. When one database creates a new object it requests an ID from the ID server rather than creating an ID locally. (And of course, if you are creating a lot of IDs, you would make one request to the ID server in bulk to get all the IDs needed.) Dave On Mon, Sep 24, 2012 at 12:36 AM, Jochen Topf joc...@remote.org wrote: In the recent discussion about the the imports in France and DWG governance the issue of multiple layers in OSM came up again. If we had some kind of layer system we could stage imports through them instead of adding all data to the OSM database directly and this would help finding problems etc. It turns out there are many other interesting uses of multiple layers but also many technical and social questions around them. I have written down my thoughts on this subject in a (rather lengthy) blog post: http://blog.jochentopf.com/2012-09-23-multiple-layers-for-osm.html If anybody wants to comment, I think this mailing list is the right place. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple Layers for OSM
On Mon, Sep 24, 2012 at 09:11:34AM -0700, Dave Sutter wrote: This is a very interesting thread and I need a little more time to understand what is in it so far. I do want to make one technical comment. It is possible to to have multiple databases and still have unique IDs across them. An ID server can be set up to create the IDs. When one database creates a new object it requests an ID from the ID server rather than creating an ID locally. (And of course, if you are creating a lot of IDs, you would make one request to the ID server in bulk to get all the IDs needed.) Yes, but it makes the whole system harder to build and less robust. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
Le 25/09/2012 17:59, Jeffrey Warren a écrit : OpenStreetMap Japan, a Wikipedia-like service that contains a lot of incorrect and outdated information. that is really awful. We can't let that kind of statement stand! It affects the credibility of all OSM efforts, and is like the kind of FUD Wikipedia saw early on. Any possibility of getting a retraction? Though really that doesn't even cover it. Some kind of very public rebuttal. jeff First they ignore you, then they laugh at you, then they fight you, then you win. -- FrViPofm ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple Layers for OSM
On Mon, Sep 24, 2012 at 03:28:50PM +0100, Matt Amos wrote: On Mon, 2012-09-24 at 09:36 +0200, Jochen Topf wrote: It turns out there are many other interesting uses of multiple layers but also many technical and social questions around them. I have written down my thoughts on this subject in a (rather lengthy) blog post: http://blog.jochentopf.com/2012-09-23-multiple-layers-for-osm.html what do you think of the Potlatch 2 vector backgrounds [1] and snapshot server [2] as steps in the direction of fixing this? [...] [1] http://wiki.openstreetmap.org/wiki/Potlatch_2_merging_tool [2] http://wiki.openstreetmap.org/wiki/Snapshot_Server Those are good pieces of the puzzle. I think we need to bring those and other different pieces together into something conceptually hole. 1. First we need a way for everybody to host their own data layers. The Snapshot server is one option, the RailsPort another. Ideally I would like to see one server software that everybody can install and configure according to their needs. 2. Then we need a way of adressing those layers globally. I proposed using URLs with meta data behind them and some registration service in my blog post. 3. Then we need tools to bring those layers together in different ways. All major editors already support some kind of layering. They need to support this adressing. And we need to support extract, copy, merging, etc. of the data. What I am thinking about here is really not that big of a step. It is just a more integrated way of thinking about the pieces and formalizing some interfaces so that the pieces fit well together. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple Layers for OSM
On Mon, Sep 24, 2012 at 05:04:29PM -0700, Dave Sutter wrote: I liked the Tag Central presentation. I have searched for more information but I can't find much. Has there been any more development on the Tag Central idea? Thats a bit offtopic in this thread, but... Although Tag Central sounds good at first, in my opinion it is the wrong approach. Centralizing control in one point is counter to the way OSM works. Taginfo takes the opposite approach and, unlike Tag Central, it does exist and it is used every day by many mappers. :-) http://wiki.openstreetmap.org/wiki/Taginfo Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple Layers for OSM
On Mon, Sep 24, 2012 at 11:35:45AM +0200, Martin Koppenhoefer wrote: Another similar concern I have with layers is that of fragmentation of the data which currently is all in the one main layer. In the past there were some people asking for separate thematic layers like landuse (e.g. in order to not show them in their editor), and introducing a layer-system might likely lead to fullfilling this desire. I see this as a problem because landuse is strongly tied to other objects like streets, building lots, and other polygons (e.g. amenity, leisure, place-polygons) and moving or editing only part of this data will also lead to out-of-sync-geometry between layers (won't fit one over the other). To avoid this people would have to look at all layers, which in the end eliminates the benefits of separate layers. Yes, this is the biggest concern I have with this approach, too. We need to develop an idea what data should be in different layers and what data shouldn't. And this has to be something the whole project has to agree on. We don't want a situation where we have to known that to get landcover in France you'll have to add the corinne layer, but in Germany, the landcover is inside the main layer! Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple Layers for OSM
On Mon, Sep 24, 2012 at 08:54:08PM +0700, Jais Pedersen wrote: The problem with lengthy blog posts is that they result in lengthy replies and probably a long thread :-) Thats not a problem. Thats good! :-) I think most users never look at the edit history and most of us that occasionally do look at it, do it mainly to get some idea about the validity of the data. To use our data to make historical maps, we have to finish making the current snapshot of the world first, then it might be possible to start looking at a way of making different more or less linked snapshots in time. I agree it might not be easy, but I think that just because it is difficult to build a space shuttle, that should not stop us from trying to build the car that most of us actually need first. The problem is that there are people out there that want to make historical maps today. You can't tell them to go away and come back in ten years when we come around to help them. What I want to give them is some minimal tool so that they *can* work on their stuff without disturbing the OSM mainstream. The rendering performance problem for lower zoom levels, is probably better handled during import/update. If apmon keeps improving the performance of osm2pgsql, then it might be realistic to have a normal high zoom database and a separate low zoom database where only the tags need for low zoom levels are imported and the geometries are simplified (it might be as simple as using ST_simplify, but I have no experience with that and currently no access to capable hardware for testing). From Frederics SOTM slides it looks like the sweet spot is around zoom level 8. This is much more difficult than simplifying some geometries. We already have some low zoom data in an extra table in osm2pgsql und many people have already done line simplification in their data. I wrote software myself that can extract simplified motorways etc. from OSM data for use in small scale maps. But that is really hard to do properly and it doesn't always work. Having humans in the loop makes nicer maps more feasible. All I am talking about an option here. If you don't want to use this for your map, thats fine. But I certainly would have needed that option many times already. I do share Martins concerns about how to handle updates to linked data, but maybe that can be solved by having both hard and soft links, so the user that creates the link makes the decision. That will also force you to think about if these two areas are actually linked or did you just reuse the nodes that were conveniently already there? If you have both layers open, you could have a also update soft links mode for those that know what they are doing and in the historic layer we could keep the soft links in an un-linked, but not yet completely destroyed state, where somebody can manually check if the link should be restored or removed. That will not completely solve the problem with historic maps, but if that is the only issue, I don't think that should stop us. Frankly I don't think we can ever solve the linked data problem. Linking structured data to other structured data in a meaningful way is hard to do. Of course we can have some kind of link between the data and I think we should. But the link will only link between generic objects and that doesn't really help us much. Most of the semantic information in OSM is inside the tags and they are not really accessible for linking. What I mean is this: Say you have a node today with an address tag. You then create a building outline and move the address tag to that building. Conventional wisdom is to at least re-use the node inside your new building outline way, to create some kind of connection. But that might not be possible in all cases and, anyway, not everybody does it that way. So there is some connection lost here. But this is a very specialized case anway. How would we design generic tools that allow us to find corresponding data in the same database over time or in different databases? I think a possible approach in this case is similar to what we have been doing for a long time with our semi-automated quality management tools: We use the data itself and especially redundancies in our data to find corresponding data. We tell the mapper about those cases and let them work out the details and fix the data. So if we have several databases and extra tables that link objects ids from one database to the other we can write tools that tell us: Object x changed in this database in some possibly important way but object y in the other database did not change in a correspoding way. Please look into that. The important thing is that those tools can be implemented outside the databases themselves, which makes development much easier. And they can be implemented specially for many different use cases by the interested parties themselves. This approach is by no means perfect, but I fear thats all we can get.
Re: [OSM-talk] Proposal for import guidelines
I like this proposal - from my very personal point of view it safeguards all the conflicting interests and reaffirms essential inflexible principles while cutting some slack to users who perform small local imports : The bot=yes tag identifies the import as such, to help moderators focus on that class of potentially widely damaging changes. bot_url=link to a page describing the automated edit provides all the necessary context about the import, including quality and methodology issues specific to the source of data. The bot_source_licence tag clarifies the license status of the source at that point in time. The specific conditions (imports of more than a given number of nodes, continuously running scripts, edits affecting more than one country) for changesets for which a separate account is necessary are clear and non-equivocal, reaffirming the current requirement for a separate account while letting the users of occasional small-scale imports at a local level perform them with their personal account. The need to keep these conditions open-ended is a weakness that lets detractors claim that they are arbitrary, but I'm guessing that this is necessary to prevent users gaming the rules with stupid technical loopholes... Not quite transparent but practical. This proposal hits all the goals I have seen stated so far... Or are there others that are not satisfied by this proposal ? On the French list, some contributors are complaining that the changeset-level tagging makes the separate account requirement entirely obsolete. Technically, I believe they are right... But I hope they'll see that this proposal could be a fair meeting ground for an opportunity to improve the import process with better metadata and make it more flexible where necessary while not messing too much with the current international consensus. On 09/25/2012 07:11 PM, Richard Fairhurst wrote: A propos of the recent contretemps about Cadastre imports and separate accounts (excessive use of French in this sentence is unintentional), I'd like to propose the following modification to the import/bulk edit guidelines: == An 'automated edit' is one where the editing is not carried out by manual drawing actions. This includes (but is not limited to): - imports of external data - search-and-replace tag changes - automated geometry fixup - reverting edits and applies equally to scripted edits and to those carried out within an editor program. All changesets including automated edits MUST have the following additional tags: bot=yes bot_url=link to a page describing the automated edit Users are also encouraged to add these tags: bot_type=machine-readable description of the edit type bot_source_licence=machine-readable licence name For example, bot_type=import, bot_source_licence=public_domain; or bot_type=revert. The tags should be added to the changeset, not the individual objects. Authors of software facilitating such edits (e.g. editor plugins) should provide relevant tags as a default. In addition, all automated edits of a high-volume, sustained or continuous nature MUST also be carried out from a separate OSM account. This includes (but is not limited to): - large-scale imports (for example, 20,000 nodes or greater) - continuously running scripts - edits affecting more than one country Like all other mappers, authors of automated edits must monitor the OSM inbox for any accounts they use, and be prepared to respond to messages and queries about their edits. We recognise that complying with this rule may seem onerous, but we would remind authors of automated edits that with great power comes great responsibility. OpenStreetMap's value, and differentiation from other data providers, comes from the local knowledge, skill and enthusiasm of its community, rather than from simply agglomerating data available elsewhere. These guidelines are designed to retain visibility of automated edits and thereby safeguard our most precious resource. == (end of proposed text) I hope you can see the intentions behind this proposal, but in essence: - requiring particular tags makes visibility easier, so that DWG et al have a better view of automated edits; - it also helps to spread awareness of automated edits through the community, since these edits can be easily visualised by client software - thereby bringing many eyeballs to the edits; - encouraging a machine-readable licence tag helps to avoid the issues identifying changesets that were encountered in the redaction. A brief clarification on this message: This is a personal posting. I have already proposed to the OSMF board that the three similar sets of guidelines on the wiki (imports, automated edits, mechanical edits) be combined into one, and that the result is endorsed as an OSMF policy. If this suggestion is received reasonably positively, then I'll bring it forward for incorporation into such a policy.
Re: [OSM-talk] Multiple Layers for OSM
It is harder to build because there is added functionality. You have to replace auto ID generation, which isn't too complicated. I'm not sure what you mean about robustness. Another issue this would cause is a bigger time delay on the server. I don't think it would be a good idea unless we really need common ids across servers. If so this has the benefit that no code changes except in the assignment of ids on the server. Sent from my iPhone On Sep 25, 2012, at 11:36 AM, Jochen Topf joc...@remote.org wrote: On Mon, Sep 24, 2012 at 09:11:34AM -0700, Dave Sutter wrote: This is a very interesting thread and I need a little more time to understand what is in it so far. I do want to make one technical comment. It is possible to to have multiple databases and still have unique IDs across them. An ID server can be set up to create the IDs. When one database creates a new object it requests an ID from the ID server rather than creating an ID locally. (And of course, if you are creating a lot of IDs, you would make one request to the ID server in bulk to get all the IDs needed.) Yes, but it makes the whole system harder to build and less robust. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
Jochen Topf wrote: I think it is rather difficult do exactly define what an automated edit is and what not. And trying to define this better and better is just an invitation to language lawyers to argue about minutiae. I've deliberately take this out of context because I'm beginning to see plan coming together - at least in my shrinking brain. The starting point is the discussion on 'Multiple Layers' I'd like to propose that every import is made available as a complete geo-referenced that we can all select and view. Layers will all be date stamped, so that we can select particular point in time. Registering the layer will also record all of the licensing details and where the material has come form. Along with documenting the steps taken to process the source into the correct format and alignment. This will give us a 'layer number' which will be used as part of any unique object ID's and when merging that data into other layers, the 'source' tag simply contains the layer number - automatically. I am seeing tools in qgis to run diffs between layers? But basically when a new version of an import arrives we can copy the conversion details from the existing version, and generate a new layer. Then diff tools allow easy identification of new elements that can simply be imported into a 'staging layer' ... HOW that is imported is something that needs to be fine tuned, but potentially could simply be an automatic import? But all of this is 'automated edit' process. Since the original source element can be identified, MANUAL edits can be referenced back. And deletes simply tag 'end_date=xxx' so information is still accessible. However I would anticipate that the manual processing is simply grouping and identifying ways from the source layer and tagging each created object with a source of the layer number and either an inherited id or one generated within the staging layer. At this stage I'm sure that 'source' layer should be read only, but there should be an additional object table which provides a cross reference to any merged data? I'm sure that we do not need to break things down as much as http://wiki.openstreetmap.org/wiki/OSM_Layers proposes, since selecting a view of the data that just has a particular sub set of objects is not difficult, but I can see the advantage of secondary caches of data in a layer framework. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
My main machine is down at the moment so this isn't as detailed as I'd like, but I have a few thoughts.On Sep 25, 2012, at 10:11 AM, Richard Fairhurst rich...@systemed.net wrote:A propos of the recent contretemps about Cadastre imports and separate accounts (excessive use of French in this sentence is unintentional), I'd like to propose the following modification to the import/bulk edit guidelines: == An 'automated edit' is one where the editing is not carried out by manual drawing actions. This includes (but is not limited to): - imports of external data - search-and-replace tag changes - automated geometry fixup - reverting edits and applies equally to scripted edits and to those carried out within an editor program. All changesets including automated edits MUST have the following additional tags: bot=yes bot_url=link to a page describing the automated edit Users are also encouraged to add these tags: bot_type=machine-readable description of the edit type bot_source_licence=machine-readable licence name For example, bot_type=import, bot_source_licence=public_domain; or bot_type=revert. The tags should be added to the changeset, not the individual objects. Authors of software facilitating such edits (e.g. editor plugins) should provide relevant tags as a default.I'd like to see a standardized tag to indicate reverted changesets. The redaction bot usedredacted_changesets=*, perhaps reverted_changesets=cs1;cs2;cs3 (etc) could be used as a standard way to indicate changesetsIn addition, all automated edits of a high-volume, sustained or continuous nature MUST also be carried out from a separate OSM account. This includes (but is not limited to): - large-scale imports (for example, 20,000 nodes or greater) - continuously running scripts - edits affecting more than one countryAlthough I agree that these should or do require a separate account, I wouldn't classify large-scale imports as automated edits, I'd classify them both as types of bulk edits.I see bulk edits as falling into two groups- Mechanical edits, some of which would be automated edits- ImportsIn theory you can have edits which blur the boundaries (e.g. recent Czech edits) but in practice these are infrequent. Most bulk edits clearly fall into one group or another.Like all other mappers, authors of automated edits must monitor the OSM inbox for any accounts they use, and be prepared to respond to messages and queries about their edits.Speaking as someone who both maintains multiple (four) accounts and frequently has to contact separate accounts, I prefer a link to the person's main account, either to /user/name or /message/user/new. In theory all messages sent to any of my accounts result in an email to my main account but in practice I've found these sometimes get routed to spam. I regularly check my main account but I normally only check the others on demand. Even if I was checking these daily my main account has more detailed contact information and information on how to get in touch with me quickly.We recognise that complying with this rule may seem onerous, but we would remind authors of automated edits that "with great power comes great responsibility". OpenStreetMap's value, and differentiation from other data providers, comes from the local knowledge, skill and enthusiasm of its community, rather than from simply agglomerating data available elsewhere. These guidelines are designed to retain visibility of automated edits and thereby safeguard our most precious resource. == (end of proposed text) I hope you can see the intentions behind this proposal, but in essence: - requiring particular tags makes visibility easier, so that DWG et al have a better view of automated edits; - it also helps to spread awareness of automated edits through the community, since these edits can be easily visualised by client software - thereby bringing "many eyeballs" to the edits; - encouraging a machine-readable licence tag helps to avoid the issues identifying changesets that were encountered in the redaction. A brief clarification on this message: This is a personal posting. I have already proposed to the OSMF board that the three similar sets of guidelines on the wiki (imports, automated edits, mechanical edits) be combined into one, and that the result is endorsed as an OSMF policy. If this suggestion is received reasonably positively, then I'll bring it forward for incorporation into such a policy. I would welcome your comments. :)___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Réf.: Re: Proposal for import guidelines
Le mar. 25 sept. 2012 21:22 HAEC, Jean-Marc Liotier a écrit : I like this proposal - from my very personal point of view it safeguards all the conflicting interests and reaffirms essential inflexible principles while cutting some slack to users who perform small local imports : The bot=yes tag identifies the import as such, to help moderators focus on that class of potentially widely damaging changes. bot_url=link to a page describing the automated edit provides all the necessary context about the import, including quality and methodology issues specific to the source of data. The bot_source_licence tag clarifies the license status of the source at that point in time. The specific conditions (imports of more than a given number of nodes, continuously running scripts, edits affecting more than one country) for changesets for which a separate account is necessary are clear and non-equivocal, reaffirming the current requirement for a separate account while letting the users of occasional small-scale imports at a local level perform them with their personal account. The need to keep these conditions open-ended is a weakness that lets detractors claim that they are arbitrary, but I'm guessing that this is necessary to prevent users gaming the rules with stupid technical loopholes... Not quite transparent but practical. This proposal hits all the goals I have seen stated so far... Or are there others that are not satisfied by this proposal ? On the French list, some contributors are complaining that the changeset-level tagging makes the separate account requirement entirely obsolete. Technically, I believe they are right... But I hope they'll see that this proposal could be a fair meeting ground for an opportunity to improve the import process with better metadata and make it more flexible where necessary while not messing too much with the current international consensus hi, The proposal of changeset tags seems also good for me but I consider that the arbitrary criteria of node number is a weakness that fall in the trap of stupid technical loopholes mentionnedby Jean Marc. it will be quite easy to split changesets to stay under the limit and avoid the use of a separated account. geographical area limitation (by example country scale) could also be hacked by splitting. that's why I personnally think that purely automatic script without manual refinement are better criteria to justify the use of a dedicated account unless there are some other reasons I'm not aware of that make the only use of tags unsufficiant best regards Julien ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multiple Layers for OSM
Jochen Topf wrote: Another similar concern I have with layers is that of fragmentation of the data which currently is all in the one main layer. In the past there were some people asking for separate thematic layers like landuse (e.g. in order to not show them in their editor), and introducing a layer-system might likely lead to fullfilling this desire. I see this as a problem because landuse is strongly tied to other objects like streets, building lots, and other polygons (e.g. amenity, leisure, place-polygons) and moving or editing only part of this data will also lead to out-of-sync-geometry between layers (won't fit one over the other). To avoid this people would have to look at all layers, which in the end eliminates the benefits of separate layers. Yes, this is the biggest concern I have with this approach, too. We need to develop an idea what data should be in different layers and what data shouldn't. And this has to be something the whole project has to agree on. We don't want a situation where we have to known that to get landcover in France you'll have to add the corinne layer, but in Germany, the landcover is inside the main layer! I'm seeing an interface to the raw data that automatically filters which objects are passed to the outgoing data stream. Theoretically there is no reason that the data FEEDING the filter could not be in separate databases. But alternatively separate tables within the one database may allow the faster access to 'layers' of data? Personally I don't see this as a particular reason to be 'layering' data. I've commented elsewhere on the 'out-of-sync' geometry problem between layers, and some potential layers such as contours do lend themselves to being isolated from other data? I'm not too worried about differences as I'm sure it can be managed if essential, but the 'difference' may also be legitimate and pulling that apart at the moment is an even more interesting problem. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
I'm worried about the ongoing push to extend the reach of rules originally designed (and supported by the community) for imports and scripts to actions initiated by human mappers using editor software. Even though your mail's subject mentions import guidelines, your proposed text switches to the much wider term automated edit and includes such things as ... On 25.09.2012 19:11, Richard Fairhurst wrote: - search-and-replace tag changes - automated geometry fixup - reverting edits In my opinion, none of that (if performed though editing software on a moderate amount of data) is something that should require the same amount of discussion and bureaucracy as a country-wide import. These are simply different things than imports and scripts, should be considered separately, and there should be much lower barriers for performing these actions. Tobias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Réf.: Re: Proposal for import guidelines
THEVENON Julien wrote: The proposal of changeset tags seems also good for me but I consider that the arbitrary criteria of node number is a weakness that fall in the trap of stupid technical loopholes mentionnedby Jean Marc. it will be quite easy to split changesets to stay under the limit and avoid the use of a separated account. geographical area limitation (by example country scale) could also be hacked by splitting. that's why I personnally think that purely automatic script without manual refinement are better criteria to justify the use of a dedicated account unless there are some other reasons I'm not aware of that make the only use of tags unsufficiant The 'reason' for a separate account should be 'designed out' and I see providing the base import as a public accessible layer as a stepping stone to providing other tools to managing the data. If the import process maintains a source tag of the relevant layer, then we can see what has come from that source, and can hopefully over time develop a 'history' of the imports objects into the base 'layer' and archive deleted data into an historic layer. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Réf.: Proposal for import guidelines
On Sep 25, 2012, at 01:00 PM, THEVENON Julien julien_theve...@yahoo.fr wrote: The need to keep these conditions open-ended is a weakness that lets detractors claim that they are arbitrary, but I'm guessing that this is necessary to prevent users gaming the rules with stupid technical loopholes... Not quite transparent but practical. This proposal hits all the goals I have seen stated so far... Or are there others that are not satisfied by this proposal ? On the French list, some contributors are complaining that the changeset-level tagging makes the separate account requirement entirely obsolete. Technically, I believe they are right... But I hope they'll see that this proposal could be a fair meeting ground for an opportunity to improve the import process with better metadata and make it more flexible where necessary while not messing too much with the current international consensus hi, The proposal of changeset tags seems also good for me but I consider that the arbitrary criteria of node number is a weakness that fall in the trap of "stupid technical loopholes" mentionnedby Jean Marc. it will be quite easy to split changesets to stay under the limit and avoid the use of a separated account. geographical area limitation (by example country scale) could also be hacked by splitting. that's why I personnally think that purely automatic script without manual refinement are better criteria to justify the use of a dedicated account unless there are some other reasons I'm not aware of that make the only use of tags unsufficiant I believe RichardF is talking about over 20k objects total, not per changeset. Going much over about 25k per changeset is a bad practice for other reasons.___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
Thank you for making this constructive proposal. My feeling is that it would constitute a positive change to the current DWG import guidelines, which are greatly lacking in subtlety. Allow me to point out, and illustrate with the French cadastre case, a problem posed by the wish strictly to separate the import component of a bulk edit (corrected/checked building geometries) from the integration component (resolving conflicts with existing building geometries and their tags, improving highway geometries using the high resolution cadastre information, etc.). Under the current (French) community guidelines for integrating this data, these two steps are combined in a single changeset. Separating them would lead to a situation where, during the period between these two changesets, the database is in an inconsistent state (overlapping buildings, highways passing through buildings, etc.). Whilst this temporary inconsistency in the data is not as severe as it would be in a software development project, for instance (the dreaded FTBFS), it is rather dirty and could lead to false alerts in error checking software. Whether this data consistency problem is more or less significant than the improved tracability of data source copyright that is afforded by the proposed import/integration separation is debatable. In my view, the costs of the proposed change outweigh its benefits (at least as far as the French cadastre situation is concerned -- other bulk edits/imports will likely have different tradeoffs). -- Eric Marsden ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Message forwarding within accounts (was: Re: Proposal for import guidelines)
On 25.09.2012 21:55, Paul Norman wrote:
Speaking as someone who both maintains multiple (four) accounts and
frequently has to contact separate accounts,
[...]
I regularly check my main account but I normally only check the others
on demand.
this triggers an idea at my side: wouldn't it be possible to forward
messages from one account to another? E.g. in Email-Systems you can set
up a forwarding rule. The idea is to have the forwarding directly within
the Rails-Port/Api/Web-Page/... and not within any Email system.
Example: B establishes a forward rule to A. If C writes a message within
via http://www.openstreetmap.org/message/new/{username} to B it should
be received at A.
Just my 2 cents,
Michael.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
I'm off to bed but would just like to respond to this one before I do. Tordanik wrote: On 25.09.2012 19:11, Richard Fairhurst wrote: - search-and-replace tag changes - automated geometry fixup - reverting edits In my opinion, none of that (if performed though editing software on a moderate amount of data) is something that should require the same amount of discussion and bureaucracy as a country- wide import. Hang on, you've got this completely wrong. There is no extra discussion involved in this proposal. No extra bureaucracy. None. This proposal is _purely_ about how edits (that are already happening) are flagged up. The proposal is just to add two extra tags, on the changeset, that permit extra visibility. It's not much. I run a revert bot (http://www.openstreetmap.org/user/General%20Dreedle) and would be very happy to add one line of Perl to add these tags and thereby flag up this is an automated edit. It doesn't seem onerous to me. And no - this isn't intended to hit restoring a single way via P1 (while it still exists) or whatever. Though I have to admit I'm rather flattered that Jochen has admitted to using Potlatch. ;) cheers Richard -- View this message in context: http://gis.19327.n5.nabble.com/Proposal-for-import-guidelines-tp5727448p5727548.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bad (wrong?) OSM publicity?
On Wed, Sep 26, 2012 at 12:59 AM, Jeffrey Warren j...@unterbahn.com wrote: OpenStreetMap Japan, a Wikipedia-like service that contains a lot of incorrect and outdated information. that is really awful. We can't let that kind of statement stand! It affects the credibility of all OSM efforts, and is like the kind of FUD Wikipedia saw early on. Any possibility of getting a retraction? Though really that doesn't even cover it. Some kind of very public rebuttal. OSMF Japan (the local Japanese chapter) has already contacted the writer as well as the interviewed person and I think there will be an appropriate update/correction of the statement. Anyway, it's just a matter of time until OSM will be the reference map in Japan. We're working on it ;-) Daniel -- Georepublic UG Georepublic Japan eMail: daniel.ka...@georepublic.de Web: http://georepublic.de ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposal for import guidelines
Richard Fairhurst wrote Hang on, you've got this completely wrong. . Seems what you mean and what you wrote differ somehow Richard Fairhurst wrote And no - this isn't intended to hit restoring a single way via P1 (while it still exists) or whatever. But I read it so. Also selecting 10 buildings in JOSM and pressing Q would fall below your proposal (automated geometry fixup) and require me to add these extra tags. -- View this message in context: http://gis.19327.n5.nabble.com/Proposal-for-import-guidelines-tp5727448p5727552.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Knooppuntennetwerken
Ik kom bij het nakijken en corrigeren van de knooppuntennetwerken mappers tegen die andere opvattingen hebben over het mappen van knooppuntennetwerken, dan wat ik hierover geleerd heb. Aangezien het bevorderlijk zou zijn, dat we allemaal op dezelfde manier mappen, zou ik willen vragen om uw mening hierover te geven op deze wiki-overlegpagina: http://wiki.openstreetmap.org/wiki/Talk:Cycle_Node_Network_Tagging mvg, Polyglot ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [Project073_general] OpenStreetMap presentatie bij Den Bosch Linux Users Group?
2012/9/20 Milo van der Linden m...@dogodigi.net: Zal ik het doen? Ik woon om de hoek en zit toch al bij jullie cluppie! Hey Milo, lijkt me een goed idee. Zou de november presentatie (dinsdag 6 november om 20u) lukken? Op 20 sep. 2012 22:51 schreef Andre Engels andreeng...@gmail.com het volgende: Ik heb wel zin, maar niet echt ervaring met presentaties geven, zeker niet over OSM. En het scheelt natuurlijk een stuk dat ik zelf ook uit Den Bosch kom. André Hey André, het zou fijn zijn als je erbij kan komen. Ik zal je laten weten waneer dit plaats zal nemen. @Robert Elsenaar: Ik heb net een PM aan ToffeHoff gestuurd, dus wij zien het wel! Groeten, +Emilien ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] [Project073_general] OpenStreetMap presentatie bij Den Bosch Linux Users Group?
Ik laat de honeurs graag aan Milo over. Hij woont veel dichter in de buurt. En daarnaast gaat me oktober en november niet lukken Gr, Henk 2012/9/25 Emilien Klein emilien+...@klein.st 2012/9/20 Milo van der Linden m...@dogodigi.net: Zal ik het doen? Ik woon om de hoek en zit toch al bij jullie cluppie! Hey Milo, lijkt me een goed idee. Zou de november presentatie (dinsdag 6 november om 20u) lukken? Op 20 sep. 2012 22:51 schreef Andre Engels andreeng...@gmail.com het volgende: Ik heb wel zin, maar niet echt ervaring met presentaties geven, zeker niet over OSM. En het scheelt natuurlijk een stuk dat ik zelf ook uit Den Bosch kom. André Hey André, het zou fijn zijn als je erbij kan komen. Ik zal je laten weten waneer dit plaats zal nemen. @Robert Elsenaar: Ik heb net een PM aan ToffeHoff gestuurd, dus wij zien het wel! Groeten, +Emilien ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] Deutsch-tschechisches Problem.
Am 25.09.2012 00:00, schrieb Walter Nordmann: Martin Koppenhoefer wrote Finde ich auch eine gute Überlegung. Du schreibst doch ziemlich gut auf deutsch, hast Du ihn schonmal direkt angeschrieben? er hat: Ich habe ihn schon mehrmals darauf aufmerksam gemacht, am Anfang hatte er damit argumentiert, dass er das so braucht so dass es in seinem Gerät [entsprechend] angezeit wird und solche Reden, jetzt ignoriert er mich völlig und macht weiter. Steht in seiner Eröffnung. Gruss walter Ich denke hier handelt es sich um den übersetzten Teil des nicht deutschsprachigen tschechischen Nutzers. MfG Andreas -- Andreas Neumann http://stadtplan-ilmenau.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Image of the week?!
Gehling Marc m.gehl...@gmx.de wrote: In Laos hat Apple OSM Daten verwendet. Routing funktioniert in Laos aber gar nicht. Wenn man z.B. die Route von Vientiane nach Thakek sucht (beides in Laos), dann startet die Route in Thailand und endet in Thailand. Auch in Islamabad funktioniert kein Routing. Also keine Vermischung von Daten. Sven -- It's easier for our software to compete with Linux when there's piracy than when there's not. (Bill Gates) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien
Hallo zusammen, unser Tileserver für den deutschen Stil (http://openstreetmap.de/karte.html) bzw. (a-d.)tile.openstreetmap.de läuft dank Mithilfe von Frederik Ramm ab sofort mit ODbL Daten. Desweiteren werden nun immer die atuellen Küstenlinien von http://openstreetmapdata.com/data/land-polygons fürs rendering verwendet, sodass auch Inseln und Küstenlinien ebenfalls zeitnah (bestenfalls täglich) aktualisiert werden sollten. Da der Server nicht so oft neu rendert wie der osm.org Tileserver kann man ggf. den Trick mit der /dirty URL anwenden um ein Neurendern einzelner tiles zu erzwingen. Derzeit sind die Daten der Küstenlinien vom 23. September, d.h. gestern Nacht war wohl wieder was etwas kaputt. Die anderen Daten sollten typischerweise weniger als 30 Minuten hinter der API liegen. Gruss Sven -- Das Internet wird vor allem von Leuten genutzt, die sich Pornografie ansehen, während sie Bier trinken, es ist daher für Wahlen nicht geeignet (Jaroslaw Kaczynski) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien
Hallo Sven, freut mich zu hören. Darf ich dem Lizenzhinweis entnehmen, dass die Tiles auch ODbL sind? Viele Grüße Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien
aighes o...@aighes.de wrote: freut mich zu hören. Darf ich dem Lizenzhinweis entnehmen, dass die Tiles auch ODbL sind? Tja, das ist eine gute Frage. Ich bin nach wie vor der Meinung, dass Tiles lediglich ein Endprodukt des Kartenstils sind, so wie etwa ein compiliertes Binary ein Endprodukt seines Quellcodes ist. Nehmen wir mal an, der Stil wäre GPL, Dann dürfte man unter Mitlieferung des Quellcodes (sprich in diesem Fall dem Mapnik Style) die Tiles selbstverständlich beliebig verbreiten. Leider ist die Lizenz des deutschen Kartenstils aber nach wie vor unklar, weil er ein Derivat des internationalen Stils darstellt und dessen Lizenz ebenfalls unklar ist. Ich selbst würde unser Derivat gerne unter GPL oder besser noch AGPL stellen. Wichtiger als die Lizenz der Tiles ist aber ohnehin die tile usage policy, denn unsere Bandbreite ist begrenzt. Gruss Sven -- Der wichtigste Aspekt, den Sie vor der Entscheidung für ein Open Source-Betriebssystem bedenken sollten, ist, dass Sie kein Windows-Betriebssystem erhalten. (von http://www.dell.de/ubuntu) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] openlayer-example komplett downloaden
HI ! ich versuche mit an einem refresh meiner smartphone-Karte und wollte auf dem Beispiel von OL aufbauen. Leider hakte es immer und immer wieder so das ich von 0 anfangen will. Das Problem ist nun das ich es irgendwie nicht gelingen will das Beispiel [1] komplett herunterzuladen. Wenn ich im FF10 Dateispeichern sage - dann kommt so ein Mist raus [2]. Kann mir einer weiterhelfen - auch wenn die Frage d klingt. Gruß Jan :-) [1] http://openlayers.org/dev/examples/mobile-jq.html#mappage [2] www.tappenbeck.net/osm/sandbox/jquery/mobile-jq.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ÖPNVKarte, ODbL Daten
Hallo zusammen, die ÖPNV-Karte läuft seit ein paar Tagen mit ODbL Daten. Ich habe mich entschieden, die Tiles weiterhin unter CC-BY-SA zur Verfügung zu stellen. Somit ändert sich für alle, die die Tiles nutzen nicht viel, außer dass die Attribution entsprechend auf die ODbL angepasst werden muss. Momentan hat der Server noch ein paar Tage rückstand zur OSM-DB, die aber hoffentlich bald aufgeholt werden. Vielleicht können die, die die Karte nutzen die Attribution entsprechend anpassen. Gibt es eigentlich irgendwo eine deutsche Musterattribution? Die Attribution auf openstretmap.de scheint mir nicht 100% korrekt, da die Lizenz der Tiles fehlt oder? Gruß, Melchior -- View this message in context: http://gis.19327.n5.nabble.com/OPNVKarte-ODbL-Daten-tp5727510.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien
Moin Sven! Zunächst möchte ich mich für deinen Einsatz bedanken. Am 25.09.2012 16:35, schrieb Sven Geggus: Da der Server nicht so oft neu rendert wie der osm.org Tileserver kann man ggf. den Trick mit der /dirty URL anwenden um ein Neurendern einzelner tiles zu erzwingen. Bei osm.org ist der dirty-Trick schon mühsam. Mit Firefox muss ich auf Openstreetmap.de zusätzlich die Grafikadresse über Seiteninformation anzeigen - Medien und Suchen in der Liste ermitteln. Wäre es viel Arbeit einen Button hinzuzufügen, mit dem man das Tile in Bildmitte mit einem Klick als dirty markieren kann? Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNVKarte, ODbL Daten
Am 25.09.2012 22:14, schrieb nimix: Hallo zusammen, die ÖPNV-Karte läuft seit ein paar Tagen mit ODbL Daten. Ich habe mich entschieden, die Tiles weiterhin unter CC-BY-SA zur Verfügung zu stellen. Somit ändert sich für alle, die die Tiles nutzen nicht viel, außer dass die Attribution entsprechend auf die ODbL angepasst werden muss. Momentan hat der Server noch ein paar Tage rückstand zur OSM-DB, die aber hoffentlich bald aufgeholt werden. Vielleicht können die, die die Karte nutzen die Attribution entsprechend anpassen. Gibt es eigentlich irgendwo eine deutsche Musterattribution? Die Attribution auf openstretmap.de scheint mir nicht 100% korrekt, da die Lizenz der Tiles fehlt oder? Gruß, Melchior Das liegt aber wohl daran, dass die Lizenz des deutschen Kartenstils unklar ist. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNVKarte, ODbL Daten
Ein verbindliche Aussage wäre für die OSM-Anwendungen innerhalb der Wikipedia auch sehr lieb. Laut einem legal-talk Beitrag[1] würde folgende reichen: (c) OpenStreetMap contributors: license Stimmt das? Die Autoren des Standard-Mapnik-Stils haben sich meines Wissens mehrheitlich für die CC0-Lizenz entschieden. Ein Hauptargument der Lizenzänderung war ja, dass ja proprietäre Daten (z.B. von Forschern) über OSM gelegt werden können sollen, daher würde ich gerne die freiest mögliche Lizenz für die Tiles vom Toolserver wählen. Wäre CC-0 + ODBL-Nennung für die Tiles ok? Da ich in meiner Karte auch noch andere Layer mit abweichender Attribution habe und die Karte nur in einem relativ kleinen Frame läuft, sollte die Lizenzangabe möglichst kurz sein. Am liebsten wäre es mir, wenn osm.org mit einer ordnunggemäßen Lizenzangabe unter der Karte als Beispiel für alle dienen würde. Grüße Tim alias Kolossos [1] http://gis.19327.n5.nabble.com/OSM-legal-talk-Mapnik-attribution-td5724875.html#a5724876 Am 25.09.2012 22:14, schrieb nimix: Hallo zusammen, die ÖPNV-Karte läuft seit ein paar Tagen mit ODbL Daten. Ich habe mich entschieden, die Tiles weiterhin unter CC-BY-SA zur Verfügung zu stellen. Somit ändert sich für alle, die die Tiles nutzen nicht viel, außer dass die Attribution entsprechend auf die ODbL angepasst werden muss. Momentan hat der Server noch ein paar Tage rückstand zur OSM-DB, die aber hoffentlich bald aufgeholt werden. Vielleicht können die, die die Karte nutzen die Attribution entsprechend anpassen. Gibt es eigentlich irgendwo eine deutsche Musterattribution? Die Attribution auf openstretmap.de scheint mir nicht 100% korrekt, da die Lizenz der Tiles fehlt oder? Gruß, Melchior -- View this message in context: http://gis.19327.n5.nabble.com/OPNVKarte-ODbL-Daten-tp5727510.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNVKarte, ODbL Daten
Am 25.09.2012 23:24, schrieb Kolossos: Laut einem legal-talk Beitrag[1] würde folgende reichen: (c) OpenStreetMap contributors: license Stimmt das? Ja...wobei license ein Link auf osm.org/copyright sein muss oder direkt auf die ODbL und zusätzlich halt noch die Lizenz der Tiles und was dafür nötig ist. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien
Am 25.09.2012 23:11, schrieb Stephan Wolff: Mit Firefox muss [...] Geht viel einfacher: die neu zu rendernde Kachel mit der RECHTEN Maustaste anklicken = Grafik anzeigen, Kachel wird angezeigt mit entsprechender URL = in die URL ein /dirty anfügen und mit return wegschicken = fertig. Das ist m.E. absolut nicht kompliziert und aufwändig. Häufig reicht sogar ein Karte passend zoomen = Permanentlink anklicken = CTRL F5 (oder auch 2 oder 3 mal) = dann wird die Kachel komplett neu geladen (caches/Proxies werden übergangen), was vom Server gemerkt wird und er sie auch neu rendert wenn sie als verändert erkannt worden ist (mir ist klar, dass das /dirty noch aggressiver ist). Wäre es viel Arbeit einen Button hinzuzufügen Ich wäre gegen einen zusätzllichen Button. Begründungen: 1) Das Hinzufügen eins zusätzlichen Buttons ist nur nützlich für Experten, den allgemeinen Besucher verwirrt dieser Button IMHO. Und: er sorgt nur für unnötigen Spieltrieb und damit unnötige Last auf dem Server. Und: der normale Besucher sieht keine Veränderung und ist enttäuscht. Und es macht einen unfertigen Eindruck von wegen da muss man manuell etwas machen, kriegen die das nicht automatisch hin?. 2) Außerdem stellt sich immer die Frage bei großen Bildschirmen: habe ich jetzt die richtige Kachel getroffen (AKA: was ist die Mitte)? Und bei einer geraden Kachel-Anzahl gibt es sowieso keine Kachel in der Mitte... Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien
Am 26.09.2012 um 0:29, schrieb Michael Kugelmann: Geht viel einfacher: die neu zu rendernde Kachel mit der RECHTEN Maustaste anklicken = Grafik anzeigen Nein, genau das geht eben bei openstreetmap.DE (darum ging es hier), zumindest mit dem genannten Firefox, nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien
Hi, On 26.09.2012 00:57, qunuxy-osmmailingli...@yahoo.com wrote: Am 26.09.2012 um 0:29, schrieb Michael Kugelmann: Geht viel einfacher: die neu zu rendernde Kachel mit der RECHTEN Maustaste anklicken = Grafik anzeigen Nein, genau das geht eben bei openstreetmap.DE (darum ging es hier), zumindest mit dem genannten Firefox, nicht. Vermutlich geht es, wenn Du den lokale Gruppen-Layer vorher abschaltest. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Kartenstil mit ODbL Daten und aktuellen Küstenlinien
Am 26.09.2012 um 1:02, schrieb Frederik Ramm: Vermutlich geht es, wenn Du den lokale Gruppen-Layer vorher abschaltest. Danke für den Hinweis, hilft aber leider auch nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Anche il parco cicloturistico dei Navigli usa OSM
Per il momento avvistato su una cartina: http://static.touringclub.it/store/document/492_file.pdf ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] condizioni utente
Il 24 settembre 2012 22:45, Paolo Pozzan pa...@z2z.it ha scritto: Ciao, poi te ne sei occupato tu delle traduzioni? Ciao, no, non ho avuto più risposta da chi doveva accettare la mia richiesta, indagherò sul perché... Paolo Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Anche il parco cicloturistico dei Navigli usa OSM
Il 25/09/2012 09:19, Federico Cozzi ha scritto: Per il momento avvistato su una cartina: http://static.touringclub.it/store/document/492_file.pdf ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it Bene, sono contento che prenda sempre più piede OSM!!! ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Visualizzazione sentieri inseriti
Am 24.09.2012 22:01, schrieb Salvatore Neglia: Salve a tutti, qualche giorno fa ho finalmente visto aggiornare la cycle map e quindi il sentierno che avevo inserito risulta visibile. La cosa strana è che risulta visibile entro un determinato livello di zoom. aumentando ancora lo zoom non si vede più. è normale? eccovi il link permanente: http://www.openstreetmap.org/?lat=37.9367lon=13.6412zoom=13layers=C Appare che i vari livelli di zoom sono renderizzati a tempi diversi. Così può capitare che impiega ancora più tempo per diffondere un cambiamento su tutti i livelli zoom. -- cheers, Alex ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] condizioni utente
a suo tempo, a me è successo che mi approvassero per la traduzione senza mai mandarmi la conferma. 2012/9/25 Stefano Pallicca palli...@gmail.com: Il 24 settembre 2012 22:45, Paolo Pozzan pa...@z2z.it ha scritto: Ciao, poi te ne sei occupato tu delle traduzioni? Ciao, no, non ho avuto più risposta da chi doveva accettare la mia richiesta, indagherò sul perché... Paolo Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] condizioni utente
2012/9/24 Paolo Pozzan pa...@z2z.it: Il 18/09/2012 12:11, Stefano Pallicca ha scritto: Il 18 settembre 2012 09:49, Simone Cortesi sim...@cortesi.com ha scritto: approfitto del thread per far notare che le traduzioni del sito openstreetmap.org hanno bisogno del nostro amore: http://translatewiki.net/wiki/Translating:OpenStreetMap soprattutto per quanto riguarda gli aggiornamenti dei testi resi necessari a seguito del cambio di licenza. Ottimo, ho appena fatto richiesta per diventare traduttore :) Ciao, poi te ne sei occupato tu delle traduzioni? Perché su translatewiki.net non vedo messaggi da sistemare ma sul sito c'è ancora la versione vecchia. Forse basta attendere l'aggiornamento... ogni tot, una volta al mese circa, vengono riversati i file delle traduzioni nella versione live di osm.org. Visto che ci siamo... Qualcuno sa se c'è un modo per ricevere un aggiornamento quando ci sono nuove traduzioni? (mailing list, feed rss, ifttt...) no, non ho mai trovato nulla. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] C'è qualcuno di Forlì?
Su provincia di Forlì c''e qualcuno che e' disposto ad effettuare l'import dai dati della regione emilia romagna ? se si mi si invi email che gli passo i files osm da importare tramite josm, mi sto' finendo la provincia di Parma e poi attacchero' con Piacenza Ciao mcheck Il 20 settembre 2012 19:06, sabas88 saba...@gmail.com ha scritto: 2012/9/20 Davide Meloni emmed...@yahoo.it per esaminare quest'area... http://www.mantellini.it/2012/09/20/mapperfavore/ Ma comunque fa un confronto Gmaps/Applemaps, OSM non c'entra per fortuna :) http://gizmodo.com/5944960/apple-maps-vs-google-maps-a-side-by-side-iphone-comparison Apple è in mezzo ad una shitstorm da appena rilasciato iOS6 ahahah! Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Linux Infinite Freedom ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Visualizzazione sentieri inseriti
Tempo fa feci delle ricerche per sapere ogni quanto e in che modo la cyclemap venga aggiornata...alcuni dicevano che si aggiorna ogni tot giorniper altri sembrerebbe che si aggiorni in base alla richiesta di generazione delle tiles...cioè più frequentemente viene visualizzata un area...più è prioritario l'aggiornamento di quella zona...non so se anche per i vari livelli di zoom funziona così... Il 24/09/2012 22:01, Salvatore Neglia ha scritto: Salve a tutti, qualche giorno fa ho finalmente visto aggiornare la cycle map e quindi il sentierno che avevo inserito risulta visibile. La cosa strana è che risulta visibile entro un determinato livello di zoom. aumentando ancora lo zoom non si vede più. è normale? eccovi il link permanente: http://www.openstreetmap.org/?lat=37.9367lon=13.6412zoom=13layers=C ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] condizioni utente
Il 25 settembre 2012 10:47, Simone Cortesi sim...@cortesi.com ha scritto: a suo tempo, a me è successo che mi approvassero per la traduzione senza mai mandarmi la conferma. Sì, ho verificato ed è successo anche a me. Ad ogni modo ho visto che le traduzioni del cambio di licenza sono state effettuate, aspettiamo il push verso il server ... Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] C'è qualcuno di Forlì?
Ciao, non sono di Forlì (sono di Treviso, del gruppo OSM Veneto) ma se nessuno si offre, posso caricarti volentieri i dati (sono uno degli importer dei dati rilasciati dalla regione Veneto). Zippa ( o meglio 7zippa) tutto e manda pure a kinetocore86 AT gmail dot com. Leonardo ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] ways e fantasia
Casualmente (maledetto routing) mi sono accorto che una rotatoria a Milano, piazza Firenze, adesso permette anche di andare contromano. :-( La way e' questa: http://www.openstreetmap.org/browse/way/45745224 Ci hanno messo le mani in parecchi nel tempo, solo che mi aspetterei che la qualita' aumenti, non diminuisca. Nel caso in oggetto ci sono particolari di pura fantasia. La way non e' chiusa ma aveva il tag roundabout. Qualcuno, anche giustamente dal punto di vista logico ha poi tolto il tag roundabout, non considerando pero' come e' fatta la via in realta' (senso unico). Inoltre nel tempo quella rotatoria che nella realta' e' fatta da piu' spezzoni e non puo' essere percorsa tutta perche', ad esempio, in corso sempione c'e' il tram in sede separata, e' stata fatta diventare un'unica way. C'e' un pezzo che attraversa via Cenisio che in realta' e' contromano ma accanto (a est) e' stata inserita una way che dovrebbe rappresentare il pezzo contromano. Mi domando: ma a prescindere dal fine che uno vuole ottenere, sia esso una mappa fatta bene, il routing, le rotte dei mezzi, i binari del tram, ma chi modifica non dovrebbe conoscere direttamente cio' che va a toccare? E non dovrebbe fare attenzione anche ai tag altrui? :-( maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Anche il parco cicloturistico dei Navigli usa OSM
Il giorno 25/set/2012 10:06, Caterpillar caterpilla...@gmail.com ha scritto: Il 25/09/2012 09:19, Federico Cozzi ha scritto: Per il momento avvistato su una cartina: http://static.touringclub.it/store/document/492_file.pdf Bene, sono contento che prenda sempre più piede OSM!!! Anch'io ma una mappa del genere non so faccia bene o male ad OSM. Io non permetterei mai l'utilizzo di una cosa simile :-) Se qualcuno ha voglia di contattarli mi rendo disponibile a migliorargliela Ciao Luca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] C'è qualcuno di Forlì?
Ciao Marco, abbiamo lavorato mesi fa all' import degli edifici delle zone terremotate in Emilia. Sono di Cesena, e Forlì la conosco abbastanza bene, ma fino al 10 ottobre devo seguire un lavoro che mi assorbe al 100%. Dopo metà ottobre massima disponibilità, se servirà ancora. PS: Per il comune di Cesena dove risiedo sto procedendo da tempo all' import degli edifici con un approccio un pò più 'conservativo' e graduale, con largo uso di immagini bing e PCN a supporto, per cui magari vi chiedo di escluderla in prima battuta. Gianmario Mengozzi sent by GNexus Il giorno 25/set/2012 11:00, marco bra marcobra.ubu...@gmail.com ha scritto: Su provincia di Forlì c''e qualcuno che e' disposto ad effettuare l'import dai dati della regione emilia romagna ? se si mi si invi email che gli passo i files osm da importare tramite josm, mi sto' finendo la provincia di Parma e poi attacchero' con Piacenza Ciao mcheck Il 20 settembre 2012 19:06, sabas88 saba...@gmail.com ha scritto: 2012/9/20 Davide Meloni emmed...@yahoo.it per esaminare quest'area... http://www.mantellini.it/2012/09/20/mapperfavore/ Ma comunque fa un confronto Gmaps/Applemaps, OSM non c'entra per fortuna :) http://gizmodo.com/5944960/apple-maps-vs-google-maps-a-side-by-side-iphone-comparison Apple è in mezzo ad una shitstorm da appena rilasciato iOS6 ahahah! Stefano ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Linux Infinite Freedom ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] condizioni utente
Il 25/09/2012 10:59, Simone Cortesi ha scritto: ogni tot, una volta al mese circa, vengono riversati i file delle traduzioni nella versione live di osm.org Qualcuno ha voglia di apportare una piccola modifica? Nella home page: *E' fatta* da persone come te. → *È realizzata* da persone come te. Grazie! Carlo -- .-. | Registered Linux User #443882| .''`. oo| | http://linuxcounter.net/ | : :' : /`'\ | Registered Debian User #9 | `. `'` (\_;/) | http://debiancounter.altervista.org/ | `- ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] Desface en imágenes satelitales.
Hola 2012/9/25 Daniel Sanchez Ramirez - .:Erunamo:. anonimato1...@gmail.com: Buenas tardes a todos/as. Primero, quiero saludarlos ya que es mi primer mensaje en la lista de correo, con ello espero poder estar más al tanto de los movimientos que hagamos en Colombia, y poder también ayudar cuando me sea posible. Por favor envíanos el link de la zona que mencionas para revisarlo. salu2 humano El motivo de este mensaje es preguntar sobre las imágenes satelitales que son tomadas de Bing: Hace tiempo (un año o más) edité algunos puntos de Medellín, más exactamente, los alrededores de la estación Hospital del Metro. En ese entonces habían construcciones y las calles no estaban aun terminadas por lo que hice el mapa con las calles que estaban funcionales en ese entonces, y todo quedó muy bien puesto. Así que hoy pasando por ahí, vi que nadie lo había actualizado, por lo que me iba a poner manos a la obra cuando... ... noté que todo estaba ligeramente corrido de como se veía en la imagen de satélite actuales. ¿Qué pudo haber sucedido?, ¿será que las imágenes de Bing están mal posicionadas?, ¿o será que algún gracioso se pudo a mover todo unos metros?[ok, esto ultimo es improbable jejeje]. Lamentablemente no tengo un GPS para poder cerciorarme si las imágenes satelitales están bien puestas, o si es que es tan corridas... o si fue que las anteriores estaban corridas... no se. Iba a ponerme a buscar en el historial de la lista si ya habían discutido esto, pero hay muchos mensajes así que preferí preguntar. Gracias por leerme :) ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. http://GaleNUx.com es el sistema de información para la salud --///-- Teléfono USA: (347) 688-4473 (Google voice) skype: llamarafredyrivera ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Desface en imágenes satelitales.
Eso se conoce como offset y sí, se requieren datos GPS para confirmarlo. El editor JOSM tiene en el menú de imágenes una función para realizar el ajuste una vez comprobado; no soy experto y nunca lo he hecho. Tal vez esto obedezca a que antes Medellín se trazó con imágenes Yahoo y ahora están las fotos Bing, pudiendo existir un desfase entre ambas. El 25 de septiembre de 2012 11:50, Daniel Sanchez Ramirez - .:Erunamo:. anonimato1...@gmail.com escribió: Buenas tardes a todos/as. Primero, quiero saludarlos ya que es mi primer mensaje en la lista de correo, con ello espero poder estar más al tanto de los movimientos que hagamos en Colombia, y poder también ayudar cuando me sea posible. El motivo de este mensaje es preguntar sobre las imágenes satelitales que son tomadas de Bing: Hace tiempo (un año o más) edité algunos puntos de Medellín, más exactamente, los alrededores de la estación Hospital del Metro. En ese entonces habían construcciones y las calles no estaban aun terminadas por lo que hice el mapa con las calles que estaban funcionales en ese entonces, y todo quedó muy bien puesto. Así que hoy pasando por ahí, vi que nadie lo había actualizado, por lo que me iba a poner manos a la obra cuando... ... noté que todo estaba ligeramente corrido de como se veía en la imagen de satélite actuales. ¿Qué pudo haber sucedido?, ¿será que las imágenes de Bing están mal posicionadas?, ¿o será que algún gracioso se pudo a mover todo unos metros?[ok, esto ultimo es improbable jejeje]. Lamentablemente no tengo un GPS para poder cerciorarme si las imágenes satelitales están bien puestas, o si es que es tan corridas... o si fue que las anteriores estaban corridas... no se. Iba a ponerme a buscar en el historial de la lista si ya habían discutido esto, pero hay muchos mensajes así que preferí preguntar. Gracias por leerme :) ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-es] Mercator-Peters
O_o¡ (¿Existe un emoticono para Me estoy mordiendo la lengua, pero bien mordida, de una de estas me provoco una hemorragia?) -- Pedro-Juan Ferrer Matoses Valencia (España) ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Mercator-Peters
On Martes, 25 de septiembre de 2012 16:09:42 Pedro-Juan Ferrer Matoses escribió: O_o¡ (¿Existe un emoticono para Me estoy mordiendo la lengua, pero bien mordida, de una de estas me provoco una hemorragia?) Para que conste, que sepas que no eres el único... -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Mercator-Peters
Pues no os cortéis, por favor. Yo no soy muy partidario de la proyección Peters que se diga, pero no domino bien el tema como para contestar. Sin embargo, una persona ha preguntado y lo mínimo es que se le conteste con unas mínimas explicaciones, sin necesidad ni de flame-wars, ni silencios incómodos ni sangre de labios mordidos. Es que si no, otro día otra persona no se atreverá a preguntar otra cosa por miedo a esto mismo, y entonces podemos cerrar esta lista de correo. Saludos Gari 2012/9/25 Cruz Enrique Borges cruz.bor...@deusto.es: On Martes, 25 de septiembre de 2012 16:09:42 Pedro-Juan Ferrer Matoses escribió: O_o¡ (¿Existe un emoticono para Me estoy mordiendo la lengua, pero bien mordida, de una de estas me provoco una hemorragia?) Para que conste, que sepas que no eres el único... -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ 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
Re: [Talk-es] Mercator-Peters
2012/9/25 Gari Araolaza g...@eibar.org: Pues no os cortéis, por favor. Yo no soy muy partidario de la proyección Peters que se diga, pero no domino bien el tema como para contestar. Sin embargo, una persona ha preguntado y lo mínimo es que se le conteste con unas mínimas explicaciones, sin necesidad ni de flame-wars, ni silencios incómodos ni sangre de labios mordidos. Es que si no, otro día otra persona no se atreverá a preguntar otra cosa por miedo a esto mismo, y entonces podemos cerrar esta lista de correo. Saludos Gari Yo solo me he acordado de esto, un clásico https://www.youtube.com/watch?v=n8zBC2dvERM (de http://mepicaenflandes.wordpress.com/2007/03/22/este-mapa-esta-mal/) el final es épico y aún me extraña que no se haya comentado... Bueno en serio, mientras pintemos tiles renderizadas tendremos que apañarnos con UNA proyección, y en su día se eligió la de Mercator. He visto ya algún experimento de ir cambiando la proyección en función del nivel de zoom y el área visualizada. Esto si lo juntas con pintar en vectorial todos los elementos, pues ya tienes un sistema que podría descartar Mercator y empezar a usar otras proyecciones más bonitas como la dymaxion o la waterman (a mí me gusta la Robinson) y poniendo arriba el rumbo en el que te sientas más realizado. -- Jorge Sanz http://es.osgeo.org ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Mercator-Peters
On Martes, 25 de septiembre de 2012 17:15:31 Gari Araolaza escribió: Pues no os cortéis, por favor. Hombre, si estás interesado yo lo más que te puedo contar es lo que nos contó Raúl Ibáñez (Profesor de la UPV y magnífico divulgador matemático) en su charla: Muerte de un cartógrafo http://divulgamat2.ehu.es/divulgamat15/index.php?option=com_docmantask=doc_downloadgid=491Itemid=75 De hecho ha escrito un libro sobre el tema: http://divulgamat2.ehu.es/divulgamat15/index.php?option=com_contentview=articleid=12021:el-sueno-del-mapa-perfecto-cartografia-y-matematicascatid=53:libros-de-divulgaciatemcadirectory=67 Básicamente lo que explicaba es que el mapa de Peters no es más que una modificación del Mercator para mejorar las áreas y que complica mucho los cálculos sin introducir ninguna mejora real (porque sigue siendo aproximado). De hecho hay alternativas mucho mejores para aproximar las áreas usando modificaciones de Mercator (creo que se llaman equiareales o no se que del seno, no me acuerdo) que desde un punto de vista geométrico son muy superiores, sin embargo no se usan porque Mercator a solas es muy simple y permite navegar por el mapa con facilidad (porque está DISEÑADO para ser así). El caso es que Peters fue un espabilado que le vendió la moto a la ONU y a las ONGs y les coló su mapa que básicamente sirve de cuadro, pero que para la práctica no funciona porque no tiene absolutamente ninguna de las propiedades que debe tener un mapa: ni puedes calcular caminos más cortos (geodésicas), ni puedes trazar rumbos (mercator), ni puedes calcular áreas (el que comentaba antes). Su única ventaja respecto a Mercator es que las áreas de ciertos continentes están mejor aproximadas que las de otros, pero a costa de PERDER la capacidad de trazar rumbos! De hecho, no se usa en ninguna aplicación seria, digo yo que si ni siquiera se usa en entornos en donde los temas políticos no existen (como mapas de la Luna, Marte, etc.) digo yo que será por algo... Espero que el ladrillo (y sobre todo las referencias) os convenzan porque mi experiencia con estos temas es que cada vez que se mencionan son SOLO y EXCLUSIVAMENTE para montar el FLAME. PD: por cierto, hay más información también en Amazing: http://amazings.es/2012/05/07/el-mapa-de-peters/ Yo no soy muy partidario de la proyección Peters que se diga, pero no domino bien el tema como para contestar. Sin embargo, una persona ha preguntado y lo mínimo es que se le conteste con unas mínimas explicaciones, sin necesidad ni de flame-wars, ni silencios incómodos ni sangre de labios mordidos. Es que si no, otro día otra persona no se atreverá a preguntar otra cosa por miedo a esto mismo, y entonces podemos cerrar esta lista de correo. Saludos Gari 2012/9/25 Cruz Enrique Borges cruz.bor...@deusto.es: On Martes, 25 de septiembre de 2012 16:09:42 Pedro-Juan Ferrer Matoses escribió: O_o¡ (¿Existe un emoticono para Me estoy mordiendo la lengua, pero bien mordida, de una de estas me provoco una hemorragia?) Para que conste, que sepas que no eres el único... -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ 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 -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] OSM 3D in osm2world - Graz wird gerendert
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-09-24 22:04, liberalerhuman...@gmx-topmail.de wrote: Ich den Häuserblock Kapuzinerstraße/Steingasse/Waltherstraße/Baumbachstraße mit 3D-Tags versehen, verwendet wurden Tags laut: http://wiki.openstreetmap.org/wiki/Building_attributes . Am besten die Tags vom Simple-3D Tagging verwenden, die wurden unter den 3D-Codern abgestimmt und werden von allen 3 Programmen unterstützt. http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings Ich habe die Gebäudehöhe mit building:levels=* angegeben, da mir keine Gebäudehöhen bekannt sind. Ich habe keine Tags nach dem Muster building:roof:ridge=* und building:roof:orientation=* verwendet, da mir die Verwendungsmöglichkeit nicht ganz klar ist. Ich möchte für die Dachkante nicht unbedingt neue Linien einzeichnen. Die Levels Angabe ist OK, da wird im 3D geschätzt mit 3m je Level. Building:roof:ridge oder orientation sollten nicht genutzt werden, dafür sollte man roof:orientation=along/across setzen. Aber so 100% ist das auch noch nicht. Jedenfalls besser als ein Tag mit 2 mal : im Namen. Leider ist das noch bei building_levels:underground der Fall... Wichtig ist bei Gebäude, die unterschiedliche Höhen haben, jedes Gebäudeteil extra markieren, taggen, über das gesamte Gebäude einen Polygonzug legen und building=yes. Hinzu eine Relation type=building mit allen Bestandteilen (also der Umriss und die einzelnen Teile). MfG, Humanist. Original-Nachricht Datum: Mon, 24 Sep 2012 21:26:33 +0200 Von: liberalerhuman...@gmx-topmail.de An: OpenStreetMap AT talk-at@openstreetmap.org Betreff: Re: [Talk-at] OSM 3D in osm2world - Graz wird gerendert Haben wir von Linz irgendwo die Gebäudehöhen? Dachformen könnte man auch vom Luftbild eintragen, für einige Gebäude bräuchte man eigene 3D-Modelle (Schloss, Lentos, Dom etc.) Ein paar Gebäude haben height eingetragen und im kendzi3d Plugin sieht man die nach oben rausschauen ;-) Generell sieht die Darstellung von Graz gut aus, Ich hielte allerdings wenig davon, Dach- und Hauswandfarben in die Karte einzutragen. Das sind zu flexible Daten, die eher mehr eine Sache für Luftbilder sind. Zumindest die Dachfarben sind eher statisch bis vergammelnd über die Zeit. Ich merke, das eine ähnliche Farbe und Form des Daches den 3D Eindruck stark verbessert und das Gebäude viel besser wiedererkennbar macht. Jedenfalls ist es besser, ein paar Dächer/Häuser nicht rot zu haben... MfG, Humanist MfG, Lars Schimmer - -- - - TU Graz, Institut für ComputerGraphik WissensVisualisierung Tel: +43 316 873-5405 E-Mail: l.schim...@cgv.tugraz.at Fax: +43 316 873-5402 PGP-Key-ID: 0x4A9B1723 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlBhSgkACgkQmWhuE0qbFyP/dACghplQz1r3fjZOZlV3FtMnP7py bjIAoJUeOstYar4A74vcj2FIFy63v8nE =o7QV -END PGP SIGNATURE- ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD Tirol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Wie ist denn in Tirol die Lage inzwischen, was/wieviel wurde schon von den OGD übernommen? Habe durch Zufall (muss mich grade mit OGD Wien beschäftigen) auf die Mountainbike-Routen (http://www.tirol.gv.at/applikationen/e-government/data/datenkatalog/sport-und-freizeit/mountainbike-routen-in-tirol/) gestossen, sind die schon übernommen? Sonst kommt das auf meine Todo. lg, Florian On 18/05/12 16:20, Boris Cornet wrote: Hallo! Nun ist es soweit: Open Government Data (ODG) Tirol kann in OSM genützt werden, die erforderlichen Eintragungen auf der OSM Homepage sind erfolgt. Unter http://www.tirol.gv.at/applikationen/e-government/data/datenkatalog/ sind die derzeit verfügbaren Daten aufgelistet. Es ist noch nicht sehr viel, aber es soll schon in Kürze mehr kommen, Burgen und Schlösser sind schon in Vorbereitung, eventuell bekommen wir sogar die verorteten Adressen (das wäre der Hit). Zur Klarstellung, die derzeitige Vereinbarung betrifft nur die ODG-Daten unter obigen Link. Das Land Tirol bietet auch im Bereich Geoinformation (tiris) freie Daten unter einer ähnlichen Lizenz an, hierzu muss aber noch eine eigene Vereinbarung betreffend der Form der Namensnennung getroffen werden (hierzu hoffentlich schon bald mehr). Auch wenn es nicht ausdrücklich erforderlich ist, sollte bei Dingen, die in OSM auf Basis der ODG Tirol Daten erstellt werden, im Source Tag Land Tirol (data.tirol.gv.at) stehen. Technisches: Die Daten liegen teilweise als GPX, zumeist aber als ESRI shapefiles in Gauß-Krüger M28 Projektion (EPSG:31257) vor. Beim Umprojezieren in WGS84 sind die erforderlichen proj4 Parameter selbst anzugeben, da es sich erwiesen hat, dass die mitgelieferten prj-Dateien nicht genau genug sind. Es besteht da eine Abweichung in einem Parameter an der siebten Nachkommastelle, der einen Versatz um einige 10 Meter bewirkt. Zu den angebotenen Radrouten ist zu sagen, dass diese teilweise schon wieder veraltet sind (Routenumlegungen, neue Radwege). -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iF4EAREIAAYFAlBhuOwACgkQjeo4W6cWeHNpFgD/QeMs171GFKy680wn/qO28Is1 czqpJhDts8cRIdy+GKIA/A9qu2pDF+xg71/h0YZfxqZDzhcn5sJ3ZWZzFUKJpAMb =tLMh -END PGP SIGNATURE- ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk-fr] EPCI non connue de l'INSEE ?!?
Le 25/09/2012 07:47, Francescu GAROBY a écrit : (p.22)... Du coup, quelqu'un sait où je peux trouver le ref:INSEE, si ce n'est sur le site de l'INSEE ? peut-être en leur demandant directement ? http://www.cc-pays-orne-moselle.fr/Contactez-nous.html ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] EPCI non connue de l'INSEE ?!?
Merci pour ta réponse, C'est ce que j'avais fini par faire, mais je me demandais en fait (ma question initiale n'était cependant pas claire) s'il existe une liste exhaustive des ref:INSEE (extraction de la base INSEE, par ex.) ? Francescu Le 25 septembre 2012 08:23, Hélène PETIT h...@free.fr a écrit : Le 25/09/2012 07:47, Francescu GAROBY a écrit : (p.22)... Du coup, quelqu'un sait où je peux trouver le ref:INSEE, si ce n'est sur le site de l'INSEE ? peut-être en leur demandant directement ? http://www.cc-pays-orne-**moselle.fr/Contactez-nous.htmlhttp://www.cc-pays-orne-moselle.fr/Contactez-nous.html __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] EPCI non connue de l'INSEE ?!?
Le 25/09/2012 08:23, Hélène PETIT a écrit : http://www.cc-pays-orne-moselle.fr/Contactez-nous.html Autant pour moi, shame on me, ce n'est pas du tout au même endroit que ce que tu cherches. Quand même; je téléphonerais aux communes concernées, pour voir si cette CC fonctionne effectivement ... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] EPCI non connue de l'INSEE ?!?
En regardant sur la base banatic ? -- View this message in context: http://gis.19327.n5.nabble.com/EPCI-non-connue-de-l-INSEE-tp5727280p5727287.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] EPCI non connue de l'INSEE ?!?
Merci pour l'info : je ne connaissais pas cette base. Francescu 2012/9/25 partir-en-vtt ad...@partir-en-vtt.com En regardant sur la base banatic ? -- View this message in context: http://gis.19327.n5.nabble.com/EPCI-non-connue-de-l-INSEE-tp5727280p5727287.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] EPCI non connue de l'INSEE ?!?
Bonjour, De : Francescu GAROBY Merci pour l'info : je ne connaissais pas cette base. Tu peux sinon regarder sur cette page : http://www.insee.fr/fr/methodes/default.asp?page=zonages/intercommunalite.htm Deux différence avec Banatic : * c'est moins à jour * mais la licence est plus claire sur le droit de piocher de l'info dedans. Petit paradoxe : dans le champ de saisie, si tu cherches ta CC, tu ne la trouves pas, alors que dans l'Excel téléchargeable en bas de page, elle est référencée. vincent Une messagerie gratuite, garantie à vie et des services en plus, ça vous tente ? Je crée ma boîte mail www.laposte.net ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Imports du cadastre et compte dédié
2012/9/24 Vincent Pottier vpott...@gmail.com Le 24/09/2012 18:17, Marc SIBERT a écrit : (et c'est moi qui écrit ça). Il n'y a que les imbéciles qui ne changent pas d'avis Et il faut ajouter : C'est ce que je répète toujours ... A+ -- Marc Sibert m...@sibert.fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] GPS vélo Xplova et OSM ?
Quelqu'un a déjà entendu parlé des GPS de vélo Xplova ? Ils parlent d'OSM sur leur site: http://www.xplova.com/fr/serie-g/xplova-g3/ -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap et iOS 6
Le 24/09/2012 à 20:31:20 +1100 Eric Pommereau eric.pommer...@gmail.com a écrit Objet: [OSM-talk-fr] OpenStreetMap et iOS 6 : Sans savoir cela en détail je pense qu'il n'y a pas de sujet impacts d'OSM sur la nouvelle appli plans d'iOS5. Toute nouvelle source d'info sur le sujet est bonne à prendre, qu'on aime ou pas la firme à la pomme... ;-) http://www.journaldulapin.com/2012/09/23/plans-sous-ios-6-et-le-scuffgate-de-liphone-5/ On 22 sept. 2012, at 00:15, Emilie Laffray emilie.laff...@gmail.com wrote: Et aussi que sur certains produits. Le problème d'ios 6 serait un mélange de données teleatlas retraité par Apple. Il y a un site où l'on peut voir ces fameuses cartes sans acheter un iPhone? -- Cordialement Hendrik Oesterlin - Nouvelle-Calédonie ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OpenStreetMap et iOS 6
Ici, http://theamazingios6maps.tumblr.com/ Attention, ça pique les yeux ! -- Pierre-André Le 25 septembre 2012 10:48, Hendrik Oesterlin hendrikmail2...@yahoo.de a écrit : Le 24/09/2012 à 20:31:20 +1100 Eric Pommereau eric.pommer...@gmail.coma écrit Objet: [OSM-talk-fr] OpenStreetMap et iOS 6 : Sans savoir cela en détail je pense qu'il n'y a pas de sujet impacts d'OSM sur la nouvelle appli plans d'iOS5. Toute nouvelle source d'info sur le sujet est bonne à prendre, qu'on aime ou pas la firme à la pomme... ;-) http://www.journaldulapin.com/2012/09/23/plans-sous-ios-6-et-le-scuffgate-de-liphone-5/ On 22 sept. 2012, at 00:15, Emilie Laffray emilie.laff...@gmail.com wrote: Et aussi que sur certains produits. Le problème d'ios 6 serait un mélange de données teleatlas retraité par Apple. Il y a un site où l'on peut voir ces fameuses cartes sans acheter un iPhone? -- Cordialement Hendrik Oesterlin - Nouvelle-Calédonie ___ 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] Imports du cadastre et compte dédié
Hier soir, en faisant une correction ou deux pour le Remap-O-Tron qui a pour but de re-cartographier les données supprimées sur les USA après le changement de licence, je suis encore tombé sur des zones avec des données importées de la base Tiger complètement farfelues qui n'ont jamais été touchées par un contributeur OSM (comme un très fort pourcentage des données la bas) Je me suis demandé comment on avait pu laisser faire un import aussi brut et de mauvaise qualité directement dans la base (avec un compte séparé, il est vrai ;-) et surtout comment on pouvait autant critiquer l'intégration de notre cadastre qui semble bien mieux maitrisé et d'une qualité qui n'a rien a voir... Mais bon cela ne m'empêche pas d'aller donner un coup de main la bas, ils en ont bien besoin ;-) Vlad. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
