[Talk-ko] Import of marine lights
Hi! We are going to import marine lights into the OSM database. This will touch Chinese, Korean and Malaysian coasts. Please find more information at the following pages: http://wiki.openstreetmap.org/wiki/Openseamap/List_of_Lights_Import Additional information is found there: http://wiki.openstreetmap.org/wiki/OpenSeaMap/Lights_Data_Model http://wiki.openstreetmap.org/wiki/Key:seamark:fixme http://wiki.openstreetmap.org/wiki/Key:seamark:type Best regards, Bernhard signature.asc Description: This is a digitally signed message part. ___ Talk-ko mailing list Talk-ko@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ko
Re: [Talk-hr] Foto geo-tagiranje
Što se tiče fotografiranja može se fotografirati bez problema tu nema nekih posebnih zakonskih odredbi jedino te može netko tužiti ako mu uđeš(fizički) na njegov privatni posjed :) Znači možeš ga sa ceste uslikati i objaviti za stolom kako jede Za OpenStreetView ne znam nisam nikada probao. 2011/5/18 Goran tom4...@yahoo.co.uk Bok, Imate li kakvih savjeta vezanih uz geo-tagiranog fotografiranja POI-a i ostalih OSM-točaka ? Naime, do sada sam koristio samo GPS-logove (trase) ali tražim bolju/bržu/jednostavniju metodu za označavanje POI-a, kućnih brojeva i sličnog. Razmišljam o tome da ponesem svoj foto-aparat i spojim GPS-log s fotkom... geo-tagiram i stavim na OpenStreetView. Ima li tko iskustva s time? ...vidim da su na OpenStreetView servisu neki Zagrebački kvartovi pokriveni takvim slikama. Koji je pravni status takvih fotografija? Da li je legalno snimati kuće, natpise/reklame firmi i slično, pa ih staviti na Internet kao javno dobro ? ... znam, glupo pitanje, ali načuo sam da zakonski gledano u Hrvatskoj ne smijem nikoga snimati bez eksplicitne dozvole te osobe ?!? ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr -- Svega što vrijedi Bog je stvorio malo, kako zlata tako i Hrvata. ___ Talk-hr mailing list Talk-hr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-hr
Re: [talk-ph] Admin Boundary of Davao City and Davao del Norte REMOVED
Is this the changeset? http://www.openstreetmap.org/browse/way/61959357 On Thu, May 19, 2011 at 8:17 PM, Marloue Pidor mur...@mail2engineer.com wrote: I noticed that the boundary I set between Davao City and Island Garden City of Samal was deleted. It was derived from 1:50k topographic map May I ask the group who deleted it? Best Regards, murlwe P.S. Please revert the deletion. ___ Get the Free email that has everyone talking at http://www.mail2world.com Unlimited Email Storage – POP3 – Calendar – SMS – Translator – Much More! ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- 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
[talk-ph] Admin Boundary and Coastline
Is there a need to clamp the admin boundaries to the coastline? span id=m2wTlpfont face=Arial, Helvetica, sans-serif size=2 style=font-size:13.5px___BRGet the Free email that has everyone talking at a href=http://www.mail2world.com target=newhttp://www.mail2world.com/abr font color=#99Unlimited Email Storage #150; POP3 #150; Calendar #150; SMS #150; Translator #150; Much More!/font/font/span___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Admin Boundary of Davao City and Davao del Norte REMOVED
You again! Ian Haylock, I need that Admin boundary. Do you think that was incorrectly placed? Why remove it? it says in your changeset you are fixing errors. murlwe From: maning sambale [emmanuel.samb...@gmail.com] Sent: 5/19/2011 8:23:18 PM To: mur...@mail2engineer.com Cc: Subject: Re: [talk-ph] Admin Boundary of Davao City and Davao del Norte REMOVED Is this the changeset? http://www.openstreetmap.org/browse/way/61959357 On Thu, May 19, 2011 at 8:17 PM, Marloue Pidor wrote: I noticed that the boundary I set between Davao City and Island Garden City of Samal was deleted. It was derived from 1:50k topographic map May I ask the group who deleted it? Best Regards, murlwe P.S. Please revert the deletion. ___ Get the Free email that has everyone talking at http://www.mail2world.com Unlimited Email Storage - POP3 - Calendar - SMS - Translator - Much More! ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- . span id=m2wTlpfont face=Arial, Helvetica, sans-serif size=2 style=font-size:13.5px___BRGet the Free email that has everyone talking at a href=http://www.mail2world.com target=newhttp://www.mail2world.com/abr font color=#99Unlimited Email Storage #150; POP3 #150; Calendar #150; SMS #150; Translator #150; Much More!/font/font/span___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Admin Boundary and Coastline
There's no real need. The idea is that in the future we would be able to map out the exact municipal and provincial waters. But until then, making the admin boundaries just tackle land for the moment is manageable since data is much more readily available. Please reply if you have other suggestions. :) On Thu, May 19, 2011 at 8:23 PM, Marloue Pidor mur...@mail2engineer.com wrote: Is there a need to clamp the admin boundaries to the coastline? ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Admin Boundary and Coastline
Hi Eugene, I find it easier if the Barangay boundaries be extendend to the City/Municipal boundary, City/Municipal boundary be extended to the Provincial boundary, Provincial boundary to the Country boundary. This is just a suggestion for the coastal areas as you said to map out the exact municipal and provincial waters. If you notice here, http://osm.org/go/4sY75GPk-- the admin boundaries are clamped to the shoreline and creating the same to the island when we can include those island to the municipal boundary. I'm suggesting this because on a GIS point of view, it is easier to look for places when it is placed inside boundaries. murlwe -Original Message- From: Eugene Alvin Villar [sea...@gmail.com] Sent: 5/19/2011 10:13:33 PM To: mur...@mail2engineer.com Cc: Subject: Re: [talk-ph] Admin Boundary and Coastline There's no real need. The idea is that in the future we would be able to map out the exact municipal and provincial waters. But until then, making the admin boundaries just tackle land for the moment is manageable since data is much more readily available. Please reply if you have other suggestions. :) On Thu, May 19, 2011 at 8:23 PM, Marloue Pidor mur...@mail2engineer.com wrote: Is there a need to clamp the admin boundaries to the coastline? . span id=m2wTlpfont face=Arial, Helvetica, sans-serif size=2 style=font-size:13.5px___BRGet the Free email that has everyone talking at a href=http://www.mail2world.com target=newhttp://www.mail2world.com/abr font color=#99Unlimited Email Storage #150; POP3 #150; Calendar #150; SMS #150; Translator #150; Much More!/font/font/span___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Admin Boundary and Coastline
On Fri, May 20, 2011 at 11:50 AM, Eugene Alvin Villar sea...@gmail.com wrote: Hi Murlwe, I don't think that municipal/provincial waters should be clamped to the national waters. According to the UNCLOS, national waters are those that are within 12 nautical miles (about 22km) from the coastline. According to the Philippine Fisheries Code of 1998, municipal waters are within 15 kilometers of the coastline. In addition, there is yet no rule on how to deal with overlapping municipal waters. According to the Fisheries Code: Where two (2) municipalities are so situated on opposite shores that there is less than thirty (30) kilometers of marine waters between them, the third line shall be equally distant from the opposite shore of the respective municipalities. This can be easily done with a GIS buffer operation, but I don't find any real need for osm to do that. You can of course download the osm data and create your preferred boundary within a GIS app. I couldn't find a law stating anything about provincial waters, but I assume they encompass their municipalities' waters. Same with barangay waters. So the idea is to mark admin boundaries of barangays, municipalities/cities and provinces as just the land portions for now. This includes islands. This is a touchy issue (politically), so for now, I agree with using coastlines as part of the admin boundary. Plus, it is easier to maintain the data since when we move the the coastline, the admin boundary in relation to the coastline move as well. Although I have different opinion with clamping boundary relations to rivers. If the concern is that you want to signify that places/landmarks of an LGU are within its boundaries in GIS terms, then the GIS app need to support boundaries that are composed of multiple polygons. For example, Caloocan City is composed of 2 disjoint territories http://www.openstreetmap.org/?relation=273242. To say that a street or POI is within Caloocan, the GIS app needs to support multiple polygons. I think postgis can do this. Same thing goes currently with LGUs that have islands. The admin boundaries currently include islands as multipolygons. For example, Romblon, whose boundaries are currently clamped to the coastlines of all of its constituent islands: http://www.openstreetmap.org/?relation=1506343. Eugene On Fri, May 20, 2011 at 10:27 AM, Marloue Pidor mur...@mail2engineer.com wrote: Hi Eugene, I find it easier if the Barangay boundaries be extendend to the City/Municipal boundary, City/Municipal boundary be extended to the Provincial boundary, Provincial boundary to the Country boundary. This is just a suggestion for the coastal areas as you said to map out the exact municipal and provincial waters. If you notice here, http://osm.org/go/4sY75GPk-- the admin boundaries are clamped to the shoreline and creating the same to the island when we can include those island to the municipal boundary. I'm suggesting this because on a GIS point of view, it is easier to look for places when it is placed inside boundaries. murlwe -Original Message- From: Eugene Alvin Villar [sea...@gmail.com] Sent: 5/19/2011 10:13:33 PM To: mur...@mail2engineer.com Cc: Subject: Re: [talk-ph] Admin Boundary and Coastline There's no real need. The idea is that in the future we would be able to map out the exact municipal and provincial waters. But until then, making the admin boundaries just tackle land for the moment is manageable since data is much more readily available. Please reply if you have other suggestions. :) On Thu, May 19, 2011 at 8:23 PM, Marloue Pidor mur...@mail2engineer.com wrote: Is there a need to clamp the admin boundaries to the coastline? . ___ Get the Free email that has everyone talking at http://www.mail2world.com Unlimited Email Storage – POP3 – Calendar – SMS – Translator – Much More! -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- 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: [talk-ph] Admin Boundary and Coastline
On Fri, May 20, 2011 at 12:15 PM, maning sambale emmanuel.samb...@gmail.com wrote: On Fri, May 20, 2011 at 11:50 AM, Eugene Alvin Villar sea...@gmail.com wrote: Hi Murlwe, I don't think that municipal/provincial waters should be clamped to the national waters. According to the UNCLOS, national waters are those that are within 12 nautical miles (about 22km) from the coastline. According to the Philippine Fisheries Code of 1998, municipal waters are within 15 kilometers of the coastline. In addition, there is yet no rule on how to deal with overlapping municipal waters. According to the Fisheries Code: Where two (2) municipalities are so situated on opposite shores that there is less than thirty (30) kilometers of marine waters between them, the third line shall be equally distant from the opposite shore of the respective municipalities. Let me clarify, there's a problem with the Fisheries Code's conflict resolution in that it disadvantages municipalities that have offshore islands. This research paper provides a very nice detailed description of the problem including illustrations and examples:http://www.scribd.com/doc/4938593/Archipelagic-Principle-Towards-Charting-of-the-Municipal-Waters ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Admin Boundary and Coastline
Maning, we have the need to do that at least in Davao because we have this Disaster Preparedness project here and it includes monitoring of passenger sea vessels via GPS/SMS?RF going from Davao to Samal so I need the boundaries. We are using OSM as the base map. That is also the reason why I am adding now the Barangay boundaries to have some idea to where the vessel on the map. Eugene, that information help me a lot so now I would limit the barangay boundary to 22kms or 30kms from the shoreline. Thanks for the info guys. murlwe -Original Message- From: maning sambale [emmanuel.samb...@gmail.com] Sent: 5/20/2011 12:15:48 PM To: Cc: mur...@mail2engineer.com; Subject: Re: [talk-ph] Admin Boundary and Coastline On Fri, May 20, 2011 at 11:50 AM, Eugene Alvin Villar sea...@gmail.com wrote: Hi Murlwe, I don't think that municipal/provincial waters should be clamped to the national waters. According to the UNCLOS, national waters are those that are within 12 nautical miles (about 22km) from the coastline. According to the Philippine Fisheries Code of 1998, municipal waters are within 15 kilometers of the coastline. In addition, there is yet no rule on how to deal with overlapping municipal waters. According to the Fisheries Code: Where two (2) municipalities are so situated on opposite shores that there is less than thirty (30) kilometers of marine waters between them, the third line shall be equally distant from the opposite shore of the respective municipalities. This can be easily done with a GIS buffer operation, but I don't find any real need for osm to do that. You can of course download the osm data and create your preferred boundary within a GIS app. I couldn't find a law stating anything about provincial waters, but I assume they encompass their municipalities' waters. Same with barangay waters. So the idea is to mark admin boundaries of barangays, municipalities/cities and provinces as just the land portions for now. This includes islands. This is a touchy issue (politically), so for now, I agree with using coastlines as part of the admin boundary. Plus, it is easier to maintain the data since when we move the the coastline, the admin boundary in relation to the coastline move as well. Although I have different opinion with clamping boundary relations to rivers. If the concern is that you want to signify that places/landmarks of an LGU are within its boundaries in GIS terms, then the GIS app need to support boundaries that are composed of multiple polygons. For example, Caloocan City is composed of 2 disjoint territories http://www.openstreetmap.org/?relation=273242. To say that a street or POI is within Caloocan, the GIS app needs to support multiple polygons. I think postgis can do this. Same thing goes currently with LGUs that have islands. The admin boundaries currently include islands as multipolygons. For example, Romblon, whose boundaries are currently clamped to the coastlines of all of its constituent islands: http://www.openstreetmap.org/?relation=1506343. Eugene On Fri, May 20, 2011 at 10:27 AM, Marloue Pidor mur...@mail2engineer.com wrote: Hi Eugene, I find it easier if the Barangay boundaries be extendend to the City/Municipal boundary, City/Municipal boundary be extended to the Provincial boundary, Provincial boundary to the Country boundary. This is just a suggestion for the coastal areas as you said to map out the exact municipal and provincial waters. If you notice here, http://osm.org/go/4sY75GPk-- the admin boundaries are clamped to the shoreline and creating the same to the island when we can include those island to the municipal boundary. I'm suggesting this because on a GIS point of view, it is easier to look for places when it is placed inside boundaries. murlwe -Original Message- From: Eugene Alvin Villar [sea...@gmail.com] Sent: 5/19/2011 10:13:33 PM To: mur...@mail2engineer.com Cc: Subject: Re: [talk-ph] Admin Boundary and Coastline There's no real need. The idea is that in the future we would be able to map out the exact municipal and provincial waters. But until then, making the admin boundaries just tackle land for the moment is manageable since data is much more readily available. Please reply if you have other suggestions. :) On Thu, May 19, 2011 at 8:23 PM, Marloue Pidor mur...@mail2engineer.com wrote: Is there a need to clamp the admin boundaries to the coastline? . ___ Get the Free email that has everyone talking at http://www.mail2world.com Unlimited Email Storage - POP3 - Calendar - SMS - Translator - Much More! -- http://vaes9.codedgraphic.com ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- cheers, maning -- Freedom is still the most radical idea of
[talk-ph] re typ of osm
hi, after installing osm map into my garmin unit,im having a hard time viewing the street especially if it is a residential or tertiary road. i tried installing typ file but it wont work osm map. sam___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] Notes on using GADM or PhilGIS boundary data
Hello guys, Some of you may already know that there is a globally available data for administrative boundaries from country level down to the sub-municipality level (depending on country). This is the Global Administrative Areas (GADM) dataset http://gadm.org/. They have data for the Philippines down to the barangay level. If you need a freely available data like that then you can use GADM. The GADM data for the Philippines is in one big chunk. If you need smaller sets (e.g., just for Metro Manila or just for a single province), you can check out PhilGIS http://www.philgis.org/ which has taken the GADM data, added PSGC metadata, and provided downloads on a per-province level. (BTW, PhilGIS contains other freely-available datasets aside from boundaries.) However take note of the restrictions and limitations: 1. License. The GADM data is freely available for academic and other non-commercial use. Redistribution, or commercial use, is not allowed without prior permission. Same with PhilGIS: For academic, non-profit, and non-commercial use only. This means that we *cannot* add GADM data into OSM, which allows redistribution and commercial use even without prior permission. 2. The data has quality issues. 2.1. Inaccurate positioning: Despite saying that the data is in WGS84 datum (which GPS devices use), they don't actually match what's on the ground. For example, here are two comparisons between the GADM data and the data in OSM: a. central Quezon City: http://wiki.openstreetmap.org/wiki/File:GADM_vs_OSM_-_Central_Quezon_City.png b. Northern Caloocan: http://wiki.openstreetmap.org/wiki/File:GADM_vs_OSM_-_Northern_Caloocan.png 2.2. Outdated data: The dataset is missing new barangays, municipalities, and cities. And the embedded data sometimes contain old names. If these restrictions and limitations are not a problem for you, then you should use them in your mapping applications, especially if the current OSM data is incomplete or inadequate for your needs. Eugene ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk-be] Atelier/workshop on OSM, Boussu, 21/05/2011
Je trouve que c'est une très bonne idée. J'ai déjà un programme, samedi après-midi, malheureusemement. Ca m'intéresserait de savoir comment ça a marché par après. Bien du plaisir à vous! Julien Le 16 mai 2011 16:46, Pol d.paol...@gmail.com a écrit : Bonjour, Je vais essayer de venir ! Bonne journée ! -φol d.- 2011/5/16 Linusable linusableli...@yahoo.fr This is an annoucement of a small workshop on OSM near Mons, next saturday ! As it will be in french, i only use this language for the following text : Le prochain atelier mensuel de l'A.S.B.L. LoLiGrUB se déroulera samedi 21 mai à 15h dans les locaux du Caj-Mir à Boussu. Pour plus d'information : http://www.loligrub.be/blog/2011/05/14/prochain-atelier-loligrub-samedi-21-mai-15h/ http://www.loligrub.be/blog/nous-rejoindre/ Un des sujets abordés est OpenStreetMap, un pont plus loin…. (lire : un peu plus loin...) La présentation s'adressera tant aux novices qu'à des utilisateurs de niveaux débutant ou moyen. Après un rapide rappel des bases sur la cartographie numérique avec OpenStreetMap, l'atelier se focalisera sur quelques points : - le fonctionnement de la communauté des contributeurs OSM (Wiki, forum, mailing list, ...) - les nouvelles fonctionnalités du logiciel d'encodage JOSM - la présentation de quelques projets utilisant les données de OpenStreetMap - la couverture de la région de Mons et du Borinage, les perspectives et la contribution de l'association LoLiGrUB La présentation sera suivie d'une discussion. Ambiance conviviale garantie ! L'atelier est ouvert à toute personne intéressée, et en particulier aux contributeurs OSM de la région. Au plaisir de vous y rencontrer ! Linusable PS : à noter que l'animateur de l'atelier (votre serviteur) n'est pas un expert en la matière, mais entend bien amplifier la dynamique OSM sur la région. ___ 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 -- Julien FASTRE http://www.meta-morphoses.be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Informal meeting in Liege - Rencontre informelle à Liège - Informele bijeenkomst in Luik
Thank you Jo for the procedure. I'll try it when I can. Is it somewhere in the osm wiki ? Maybe it deserve a place. Best regards Nicolas 2011/5/18 Jo winfi...@gmail.com: Ivo asked me what the shortcut keys were and which plugins I used for that demonstration. Maybe there are other who also wanted a recap, so here goes: Plugins: AddrInterpolation Terracer BuildingsTools Utilsplugin2 And a few others that I like, but which are not related to drawing buildings: Contourmerge OpeningHoursEditor turnrestrictions Public_Transport So, to draw many connected buildings very quickly, you start with a few addr:housenumber nodes connected by an addr:interpolation vector/way. Select the addr:interpolation vector and all the segments of the street it belongs to. This street/These street segments should have a name. This name will become a name field for the addressInterpolation relation Then you apply Tools/AddrInterpolation or Outils/Interpolation d'addresse and you tick create relation and Convertir un chemin en numéros de maison. This will result in an evenly distributed collection of nodes where the addr:interpolation vector was. They are all added to the newly created relation. Now these can be converted to building outlines, as follows: Create a building around them with 'w'. Select this building, one node on the outline of this building (near to the lowest house number) and use the relation to selected all the house number nodes. Then use Outils/Diviser un bâtiment Tools/Terracer All the created buildings are now selected. So add them to the associatedStreet relation and assign them a 'house' role. (The nodes have disappeared) The building outlines automatically get building=yes and it's possible to automatically assign them source=bing with Modifier/Définir la grandeur des bâtiments (advanced). Now drag the nodes of where the houses actually meet, according to bing. Then add extra nodes as needed by dragging the +'s. Alternatively use x (extrude). It's possible to make buildings orthogonal by using q. Things that I forgot to mention are merging of nodes, joining of (end) nodes to ways, ungluing nodes with g. I hope the whole presentation wasn't too incoherent and that my French was understandable enough. I get more practice in English and Spanish lately. I sure enjoyed talking about the subject. Maybe next time somebody could go into more detail about the creation of maps based on what's in the database. Such that it can become useful for somebody who wants to publish them. Polyglot 2011/5/18 Julien Fastré julienfas...@gmail.com Hi ! We had a nice meeting last Friday. Jo - Polyglot - demonstrate us how to map buildings very fast with JOSM, and use the plugin addrinterpolation. I also enjoyed meeting others contributors from Liege and around... And, it seems to me that, in Liege, a lot of new places appeared on the map... Good news ! In wich city will take place the next meeting ? Julien Julien Fastré a ecrit le 03/04/2011 17:38: TEXTE EN FRANCAIS : Voir plus bas TEXT IN ENGLISH : See Below Beste OpenStreetMapmedewerker, Als een mierenleger, leveren we allen individueel onze bijdrage aan het OSM-kaartproject. Het leek ons belangrijk, en ook wel leuk, om de verschillende vrijwilligers 's samen te brengen. We stellen dus een informele bijeenkomst voor in het begin van de maand mei. Om een datum vast te leggen die voor zoveel mogelijk mensen goed uitkomt, stellen we voor om de peiling in te vullen op het volgende adres: http://nuages.domainepublic.net/3833/ (Merk op dat het beginuur op de voorgestelde zaterdag 13u is). We wensen deze bijeenkomst te houden in Luik, bij de VZW Barricade, rue Pierreuse 19-21 (Dit plaats zal bevestigd worden zo vlug een datum besloten is.). Het dichtsbijzijnde station is dat van Liège-Palais. Dit staat er op het programma: * uitwisselen van tips voor het gebruik van JOSM (snel aanmaken gebouwen en adressen toewijzen, geavanceerd zoeken); * uitwisseling van de verschillende interacties met overheidsinstanties; * en gewoon een gezellige ontmoeting! U krijgt dit bericht omdat u verklaarde heeft een mapper te zijn in Luik en omgeving. Gelieve ons te verontschuldigen als u er geen interesse in hebt. Benoît Coumont, Polyglot et Julien Fastré Cher contributeur à OpenStreetMap, Comme des petites fourmis, il nous arrive de contribuer, individuellement, à la carte libre d'OSM. Il nous apparaissait important, et même amusant, de rencontrer les différents contributeurs au projet. Nous vous proposons donc un moment d'échange informel au début du mois de mai. Pour fixer une date qui conviendrait au plus grand nombre, nous vous proposons de remplir le sondage à l'adresse suivante : http://nuages.domainepublic.net/3833/ (Notez que le samedi, nous proposons un rendez-vous à 13h00). Cette rencontre aurait lieu à Liège, à l'ASBL Barricade, rue Pierreuse 19-21
[OSM-talk-be] Importing csv, good practices and tips : Multipharma Case Study
Hello, 3 weeks after my initial request, I received from the IT Director (E. Joos), a CSV file containing all the informations about each Multipharma in Belgium and the right to publish them on OSM ! Hooray ! The file is raw and needs to be parsed and cleaned. I did that part and the file is now converted into a .osm. To do that, I used LibreOffice to transform some fields, it worked without problems, the CSV handling in LibreOffice is the best I ever seen. To convert the csv file into something usable like a .osm, I used a custom python script I can share. My questions are: 1. How to be sure not to override existing data ? 2. How to maintain such a list ? I mean, if I receive an updated CSV in some month, should I upload the whole set ? What about duplicates then ? 3. After work, the current fields in the CSV are 1. Latitude 2. Longitude 3. Country 4. Name 5. addr:postcode 6. addr:city 7. addr:street 8. addr:housenumber 9. phone 10. fax 11. amenity Should I add more fields ? Source ? addr:full ? something else ? 4. What is the preferred file encoding when submitting ? Iso-8859-1 or UTF8 ? Is suppose this is the later, but I want to be sure. Thanks for the help ! ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Importing csv, good practices and tips : Multipharma Case Study
Just for info, note that there is a CSV import module in Merkaartor. If features are missing, don't hesitate to request them on the merkaartor mailing list, or via ticket on http://merkaartor.be - Chris - On Thu, May 19, 2011 at 11:06, Pol d.paol...@gmail.com wrote: Hello, 3 weeks after my initial request, I received from the IT Director (E. Joos), a CSV file containing all the informations about each Multipharma in Belgium and the right to publish them on OSM ! Hooray ! The file is raw and needs to be parsed and cleaned. I did that part and the file is now converted into a .osm. To do that, I used LibreOffice to transform some fields, it worked without problems, the CSV handling in LibreOffice is the best I ever seen. To convert the csv file into something usable like a .osm, I used a custom python script I can share. My questions are: 1. How to be sure not to override existing data ? 2. How to maintain such a list ? I mean, if I receive an updated CSV in some month, should I upload the whole set ? What about duplicates then ? 3. After work, the current fields in the CSV are 1. Latitude 2. Longitude 3. Country 4. Name 5. addr:postcode 6. addr:city 7. addr:street 8. addr:housenumber 9. phone 10. fax 11. amenity Should I add more fields ? Source ? addr:full ? something else ? 4. What is the preferred file encoding when submitting ? Iso-8859-1 or UTF8 ? Is suppose this is the later, but I want to be sure. Thanks for the help ! ___ 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] Importing csv, good practices and tips : Multipharma Case Study
I think you should check, one by one, the different points... Or maybe could you write a script which download a short area around each point, and check if there isn't any point or area which wear the tag amenity=pharmacy ? Julien 2011/5/19 Chris Browet c...@semperpax.com: Just for info, note that there is a CSV import module in Merkaartor. If features are missing, don't hesitate to request them on the merkaartor mailing list, or via ticket on http://merkaartor.be - Chris - On Thu, May 19, 2011 at 11:06, Pol d.paol...@gmail.com wrote: Hello, 3 weeks after my initial request, I received from the IT Director (E. Joos), a CSV file containing all the informations about each Multipharma in Belgium and the right to publish them on OSM ! Hooray ! The file is raw and needs to be parsed and cleaned. I did that part and the file is now converted into a .osm. To do that, I used LibreOffice to transform some fields, it worked without problems, the CSV handling in LibreOffice is the best I ever seen. To convert the csv file into something usable like a .osm, I used a custom python script I can share. My questions are: How to be sure not to override existing data ? How to maintain such a list ? I mean, if I receive an updated CSV in some month, should I upload the whole set ? What about duplicates then ? After work, the current fields in the CSV are Latitude Longitude Country Name addr:postcode addr:city addr:street addr:housenumber phone fax amenity Should I add more fields ? Source ? addr:full ? something else ? What is the preferred file encoding when submitting ? Iso-8859-1 or UTF8 ? Is suppose this is the later, but I want to be sure. Thanks for the help ! ___ 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 -- Julien FASTRE http://www.meta-morphoses.be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Importing csv, good practices and tips : Multipharma Case Study
@Lennard : i didn't know about this test API. Can we use the test api with JOSM ? @Pol: I think it would be a great idea to share the file on the wiki, or any other website, and make a link from the wiki to this site (if you need a hosting place, i can share some byte of mine) Julien -- Julien FASTRE http://www.meta-morphoses.be 2011/5/19 Lennard l...@xs4all.nl: 1. How to be sure not to override existing data ? Compare with existing pharmacies before importing. For instance, you can download all pharmacies through xapi and open those in an editor, together with your to-be-imported data. Comparing every location will be tedious, especially the first time, but does give very good results. You could also run both the xapi result and your file through a script to compare locations and notify you if there are two pharmacies within a certain distance from each other. This is easier for large datasets, but more prone to errors. 2. How to maintain such a list ? I mean, if I receive an updated CSV in some month, should I upload the whole set ? What about duplicates then ? You definately don't upload the whole set, but only the changes. If you get a new csv, the easiest would be to compare that to the csv that was the source of the last import and note any changes. Then go over those manually or with a script. That's easier than having to recheck every pharmacy in the country. If the original data has a Multipharma reference ID, you could add that as a ref=* key (or a more specific variant). That alone would make updates much easier to perform. But do keep in mind that people could remove or alter the ref, so a basic nearness test with existing data is still a good idea. 3. After work, the current fields in the CSV are 1. Latitude 2. Longitude 3. Country 4. Name 5. addr:postcode 6. addr:city 7. addr:street 8. addr:housenumber 9. phone 10. fax 11. amenity Country is not essential and should probably be dropped. If there are proper boundaries and place=* nodes, addr:city is not strictly necessary either, but it makes sense to add it anyway. Should I add more fields ? Source ? addr:full ? something else ? Source=*, definately. Also make a note of this import on the wiki 'Import Catalogue', with contact details and a note of the license of the original data release to OSM. addr:full is probably not needed, because you already have the more specific addr: keys. 4. What is the preferred file encoding when submitting ? Iso-8859-1 or UTF8 ? Is suppose this is the later, but I want to be sure. All key values are UTF8 encoded. A final note: OSM has a test API. You're well advised to upload your data there first, to test your conversion and upload process and to check the results. It's at http://api06.dev.openstreetmap.org/ -- Lennard ___ 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] Importing csv, good practices and tips : Multipharma Case Study
good news ! I suppose it will be useful to put a reference or a copy of the Multipharma authorization somewhere on the wiki (belgian project ?). What are the usual guidelines ? Linusable Le 19/05/11 11:06, Pol a écrit : Hello, 3 weeks after my initial request, I received from the IT Director (E. Joos), a CSV file containing all the informations about each Multipharma in Belgium and the right to publish them on OSM ! Hooray ! The file is raw and needs to be parsed and cleaned. I did that part and the file is now converted into a .osm. To do that, I used LibreOffice to transform some fields, it worked without problems, the CSV handling in LibreOffice is the best I ever seen. To convert the csv file into something usable like a .osm, I used a custom python script I can share. My questions are: 1. How to be sure not to override existing data ? 2. How to maintain such a list ? I mean, if I receive an updated CSV in some month, should I upload the whole set ? What about duplicates then ? 3. After work, the current fields in the CSV are 1. Latitude 2. Longitude 3. Country 4. Name 5. addr:postcode 6. addr:city 7. addr:street 8. addr:housenumber 9. phone 10. fax 11. amenity Should I add more fields ? Source ? addr:full ? something else ? 4. What is the preferred file encoding when submitting ? Iso-8859-1 or UTF8 ? Is suppose this is the later, but I want to be sure. Thanks for the help ! ___ 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] Importing csv, good practices and tips : Multipharma Case Study
On 19-5-2011 12:01, Julien Fastré wrote: @Lennard : i didn't know about this test API. Can we use the test api with JOSM ? Yes, change the api url in the config. -- Lennard ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] Geofabrik Download Server Update
Hi, On 05/19/2011 06:44 AM, Hermann Peifer wrote: Are the boundary polygons that you use for clipping available somewhere? I do vaguely remember that I have seen them earlier, but I can't find them anymore. No, they aren't publicly available but I send them to people on request. There's really no reason to keep them secret, I just haven't set up a mechanism to automatically put them on the server because I didn't think people were all that interested. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geofabrik Download Server Update
On 19/05/2011 08:10, Frederik Ramm wrote: No, they aren't publicly available but I send them to people on request. There's really no reason to keep them secret, I just haven't set up a mechanism to automatically put them on the server because I didn't think people were all that interested. I am about to make some (rough) overview statistics for European countries, about the length of OSM ways (with tagfilters highway=motorway, railway=rail, etc.). Your country files at http://download.geofabrik.de/osm/europe/ are very convenient in this context. Thanks for this great service! However, I wanted to see how much double-counting there might be, due to the simplified country borders and overlaps between neighbouring countries. I also wanted to know what your difference is between 'british_isles' and 'great_britain', etc. Other users of your files might have a similar interest. Hermann ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geofabrik Download Server Update
Frederik Ramm frede...@remote.org schrieb: Hi, On 05/19/2011 06:44 AM, Hermann Peifer wrote: Are the boundary polygons that you use for clipping available somewhere? I do vaguely remember that I have seen them earlier, but I can't find them anymore. No, they aren't publicly available but I send them to people on request. There's really no reason to keep them secret, I just haven't set up a mechanism to automatically put them on the server because I didn't think people were all that interested. Are they so much in flux that simply putting them on a web server won't do as a mechanism? If you publish them you might get patches to eliminate those occasional spots of no-man's-land you were referring to in an earlier mail. One thing people might be interested in doing is to merge them and use the result for extracting where the geofabrik extracts are not mergeable. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Banner for SOTM-EU on the startpage?
I wonder if it would not be nice to have a banner for SOTM-EU on the start page. As the page is already crowded, this could maybe appear only if the user is logged in (because then the infotext below the logo is not displayed). An example banner can be seen e.g. on http://www.openstreetmap.de/ (in Events). cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geofabrik Download Server Update
2011/5/19 Frederik Ramm frede...@remote.org: On 05/19/2011 06:44 AM, Hermann Peifer wrote: Are the boundary polygons that you use for clipping available somewhere? I do vaguely remember that I have seen them earlier, but I can't find them anymore. No, they aren't publicly available but I send them to people on request. There's really no reason to keep them secret, I just haven't set up a mechanism to automatically put them on the server because I didn't think people were all that interested. It would be interesting for me if I could just review those polygons on a map. Don't know if and/or how this can be done. For instance, I want to use the Austria extract for the coming summer holiday, but we will stay near the border of Italy. So I would like to know how far does it go across borders. And I don't know how to see that from the polygons, if I could download them. Regards, Frank ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Unlicensed use of the logo in iPhone app?
2011/5/19 Russ Nelson nel...@crynwr.com: Thomas Davie writes: On 18 May 2011, at 07:04, Russ Nelson wrote: can Ken assign copyright in the logo to OSMF. He can, but I see no reason why he should (other than if he particularly wants to). The point of the licensing of this project is for people to get credit for what they did, I don't see why Ken should have to say actually, it was the whole of the OSMF. So, no more reason than SteveC should have assigned the trademark, I guess? You really can't compare this. To control the trademark is the power to decide who has the right to call himself Openstreetmap, while beeing the copyright holder of a logo which is licensed cc-by-sa simply gives you the right to be credited when your work is used (because you already gave anyone the right to use your work without any royalties). But I agree to the point that it would be desirable not having to credit Ken every time the logo is used... cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geofabrik Download Server Update
On 19/05/2011 11:09, Frank Fesevur wrote: It would be interesting for me if I could just review those polygons on a map. Indeed. Why not on an Open Street Map? For Denmark, it would expect the bounding polygon it to look like a simplified version of: http://www.openstreetmap.org/browse/relation/50046. Hermann ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Geofabrik Download Server Update
Hi, by popular demand ;) http://download.geofabrik.de/clipbounds/ Please make sure to read the README file there. Regarding boundaries, I prefer geographical over political grouping. The Azores are part of the Europe extract but they are not part of the Portugal extract; likewise, British/French/Dutch overseas territories are not included in the extract of the mother country and usually not even in the Europe extract. There are no hard and fast rules but I figured that if someone took the France extract and computed tiles for everything in that bounding box, they should not have a nasty surprise because I threw in Guadeloupe ;) Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Crowdsource Mapping for Preparedness and Emergency Response
Hi all, Sorry HOT list if this is already on your radar, but I just came across this meeting organized by UN-SPIDER: http://www.un-spider.org/crowdsource-mapping ...'Expert Meeting to be held in Vienna to discuss strategies that will contribute to supporting civil protection and emergency management agencies to make use of products generated by such groups in areas of preparedness and emergency response and provide a better understanding to these groups on the specific needs of the disaster management community.' Anyone invited / going? I'm considering it. -- Martijn van Exel http://about.me/mvexel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Waterkaarten
Op 18-5-2011 14:47, Maarten Deen schreef: Er ook een stukje in het zeehavenkanaal van Delfzijl (naar het westen) waar de kustlijn nog verkeerd ligt. Ik heb naar aanleiding van de 3dShapes import nog wat laatste corrigeerwerk te doen. Onder andere de coastline synchroniseren met de 3dShapes. Dat heb ik in de eemsmonding / Dollard nog niet gedaan, en is alvast door een osm vrijwilliger uitgevoerd en hier aan de buitenkant van de tidalflat area gelegd. Ik ben toch net weer bezig met de coastline en kom hier de komende dagen wel langs, dan zal ik het wel corrigeren. Als iemand anders dat intussen al gedaan heeft is het natuurlijk ook goed. Theun ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Waterkaarten
On Thu, 19 May 2011 08:13:36 +0200, theun wrote: Op 18-5-2011 14:47, Maarten Deen schreef: Er ook een stukje in het zeehavenkanaal van Delfzijl (naar het westen) waar de kustlijn nog verkeerd ligt. Ik heb naar aanleiding van de 3dShapes import nog wat laatste corrigeerwerk te doen. Onder andere de coastline synchroniseren met de 3dShapes. Dat heb ik in de eemsmonding / Dollard nog niet gedaan, en is alvast door een osm vrijwilliger uitgevoerd en hier aan de buitenkant van de tidalflat area gelegd. Ik ben toch net weer bezig met de coastline en kom hier de komende dagen wel langs, dan zal ik het wel corrigeren. Als iemand anders dat intussen al gedaan heeft is het natuurlijk ook goed. Ik zie dat het in het zeehavenkanaal het een beetje tricky is. Daar ligt bijvoorbeeld de strekdam tussen kanaal en Eems (3dshapes man_made=reinforced_slope) daaronder ligt een stukje tidalflat, en dan weer een reinforced_slope. Nu ben ik er al een tijdje niet meer geweest, maar die zuidelijke reinforced_slope is er nooit geweest. Als ik op luchtfoto's kijk dan lijkt die feature een rij basaltblokken om de strekdam en het stukje droogvallend land te beschermen. Mijn mening is dat de reinforced_slope op de plaats van de basaltblokken verwijderd moet worden. In iig ligt dat buiten de kustlijn. Maarten. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] OSM tileserver in RD formaat
Hallo allemaal, Ik heb getracht een eigen server op te zetten om tiles in RD-formaat te genereren. Hiervoor heeft Just van den Broecke een duidelijke handleiding gemaakt. Hierin staat vermeld dat de world bounderies ge-herprojecteerd moeten worden. Dit heb ik ook uitgevoerd echter is bij mij het resultaat van de test afbeelding http://osm.peterse-uithuizen.com/~peter/RD.png Heeft iemand een idee wat hier het probleem van kan zijn en hoe dit opgelost kan worden? Alvast bedankt, Peter ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM tileserver in RD formaat
Opgelost, het bleek dat mijn inc/layers.xml.inc leeg was. Er as een inc/layers.xml.inc_org en de inhoud hiervan in de inc/layers.xml.inc geplakt en daarna ziet het er goed uit. Groeten, Peter Hallo allemaal, Ik heb getracht een eigen server op te zetten om tiles in RD-formaat te genereren. Hiervoor heeft Just van den Broecke een duidelijke handleiding gemaakt. Hierin staat vermeld dat de world bounderies ge-herprojecteerd moeten worden. Dit heb ik ook uitgevoerd echter is bij mij het resultaat van de test afbeelding http://osm.peterse-uithuizen.com/~peter/RD.png Heeft iemand een idee wat hier het probleem van kan zijn en hoe dit opgelost kan worden? Alvast bedankt, Peter ___ 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: [OSM-talk-nl] Uiterlijk van de kaart
Beste Cartinus, Dat OSM gratis is, is wel heel kortzichtig bekeken. De makers van de bepaalde applicaties die data van OSM gebruiken, maken kosten om deze data te ontsluiten en toe te passen. Uiteindelijk berekenen zij die door naar de eindgebruiker. Als de ontwikkelaar op eenvoudige wijze inzicht heeft over de gehele inhoud van OSM door bijvoorbeeld onze wiki door te lezen, en iedere mapper zich keurig heeft gehouden aan gezamenlijk opgestelde regels, dan zullen zijn kosten relatief laag zijn. Maar . als de community blijft bestaan uit bet weterende anarchistisch mappers die allemaal denken dat hun manier van taggen de beste is, en die unaniem weigeren zich aan algemene regels te houden, en ook niet de moeite nemen om hun nieuwe sublieme ideeën om te zetten in een stukje documentatie, en daarbij uitblijven gaan van de stel regel OSM is vrij om te doen en laten wat we willen. De kaartmakers halen uit de brei maar de zaken die ze hebben willen ... dan zal hun kosten relatief hoog blijken te zijn. En zolang er voor OSM geen alternatief is . blijven we in beeld. Wanneer er echter een ordentelijk georganiseerde groep komt die ongeveer het zelfde bied, maar waarvan het halffabricaat of grondstof (zo je wilt) doorzichtiger is en eenvoudiger te hanteren, dan is OSM snel uit beeld en gaat iedereen snel over naar de andere dataleverancier. In die zin scoort OSM slecht, al beweer jij keihard het tegendeel. OSM is duur, deels ondoorzichtig en soms erg onbetrouwbaar. Groet Robert -Oorspronkelijk bericht- From: Cartinus Sent: Tuesday, May 17, 2011 10:24 PM To: talk-nl@openstreetmap.org Subject: Re: [OSM-talk-nl] Uiterlijk van de kaart On Tuesday 17 May 2011 21:14:36 Robert Elsenaar wrote: Cartinus had een goed voorbeeld om mijn bedoeling duidelijk te maken. Het Fordje (ben trouwens zelf groot Ford-fan. ;) ) en de Varta Accu. Natuurlijk klaagt niet de autobezitter bij Varta maar de directeur van Ford. En de directeur van Ford klaagt weer omdat zijn dealer netwerkt klaagt en de dealer netwerk klaagt omdat de autobezitters morren en dreigen andere merken te kopen. Wat Varta niet wil hebben is dat Ford kiest voor andere accu's omdat de klanten anders weglopen. Varta maakt met haar accu's niet de Ford dealer blij, noch zijn dealer netwerk. Nee, Varta kijkt naar de wensen van de autobezitters en overlegt met Ford hoe ze samen een goed product kunnen maken. De automobilist kan wat betreft die accu maar twee dingen schelen: Hoe vaak gaat hij stuk en wat kost het dan. Bovendien zullen zelfs dan de meeste automobilisten niet weten welk merk het is, maar de autofabrikant de schuld geven als het naar hun gevoel te vaak gebeurt of te duur is. Op beide punten scoort OSM uitmuntend. Het is gratis. Je vervangt het wanneer het jezelf uit komt. -- m.v.g., Cartinus ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl --- Tekst ingevoegd door Panda GP 2011: Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende link om de e-mail te herclasseren: http://localhost:6083/Panda?ID=pav_5930SPAM=truepath=C:\Windows\system32\config\systemprofile\AppData\Local\Panda%20Security\Panda%20Global%20Protection%202011\AntiSpam --- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Uiterlijk van de kaart
+1 Mooi verwoord. Op 19 mei 2011 17:54 schreef Robert Elsenaar rob...@elsenaar.info: Beste Cartinus, Dat OSM gratis is, is wel heel kortzichtig bekeken. De makers van de bepaalde applicaties die data van OSM gebruiken, maken kosten om deze data te ontsluiten en toe te passen. Uiteindelijk berekenen zij die door naar de eindgebruiker. Als de ontwikkelaar op eenvoudige wijze inzicht heeft over de gehele inhoud van OSM door bijvoorbeeld onze wiki door te lezen, en iedere mapper zich keurig heeft gehouden aan gezamenlijk opgestelde regels, dan zullen zijn kosten relatief laag zijn. Maar . als de community blijft bestaan uit bet weterende anarchistisch mappers die allemaal denken dat hun manier van taggen de beste is, en die unaniem weigeren zich aan algemene regels te houden, en ook niet de moeite nemen om hun nieuwe sublieme ideeën om te zetten in een stukje documentatie, en daarbij uitblijven gaan van de stel regel OSM is vrij om te doen en laten wat we willen. De kaartmakers halen uit de brei maar de zaken die ze hebben willen ... dan zal hun kosten relatief hoog blijken te zijn. En zolang er voor OSM geen alternatief is . blijven we in beeld. Wanneer er echter een ordentelijk georganiseerde groep komt die ongeveer het zelfde bied, maar waarvan het halffabricaat of grondstof (zo je wilt) doorzichtiger is en eenvoudiger te hanteren, dan is OSM snel uit beeld en gaat iedereen snel over naar de andere dataleverancier. In die zin scoort OSM slecht, al beweer jij keihard het tegendeel. OSM is duur, deels ondoorzichtig en soms erg onbetrouwbaar. Groet Robert -Oorspronkelijk bericht- From: Cartinus Sent: Tuesday, May 17, 2011 10:24 PM To: talk-nl@openstreetmap.org Subject: Re: [OSM-talk-nl] Uiterlijk van de kaart On Tuesday 17 May 2011 21:14:36 Robert Elsenaar wrote: Cartinus had een goed voorbeeld om mijn b... --- ... Als het hier gaat om een ongevraagde e-mail (SPAM), klik dan op de volgende link om de e-mail te herclasseren: http://localhost:6083/Panda?ID=pav_5930SPAM=truepath=C :\Windows\system32\config\systemprofile\AppData\Local\Panda%20Security\Panda%20Global%20Protection%202011\AntiSpam --- ___ Talk-nl mailing list Talk-nl@openstreetmap.org htt... ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Uiterlijk van de kaart
+/- 1 Het is maar net hoe je het bekijkt. Het valt me op - als relatieve nieuwkomer op deze discussion list - dat er sommigen zijn die op nogal overtuigende of offensieve manier argumenten hanteren zeg maar. En dat er blijkbaar heel veel onduidelijkheid bestaat over missie, doel, strategie en roadmap van OSM. Je kunt wel zien dat OSM geen centraal geleid bedrijf is, en dat hoeft ook niet, maar ik mis toch een beetje sturing, een moderator functie. Al moet ik Martijn een compliment geven voor zijn afgewogen en goed geformuleerde inbreng. Maar kan het op andere plekken in de discussie soms niet wat positiever en vriendelijker? OSM is een pracht product, vind ik, en het neemt soms onverwacht positieve vormen aan. Voor de een is het denk ik een halffabricaat, voor de ander, die gewoon op www.openstreetmap.org kijkt of met openlayers een laagje toevoegt aan zijn webapp of webpagina, is het een eindproduct. Maar de kracht, de USP of 'unique selling point' zou toch moeten zijn dat het een actieve, betrokken en creatieve community is die elkaar positief versterkt. Dan gaat het niet alleen om de inhoud van de database, de kaart, maar ook om de ideeen en de vorm waarin ze gebracht worden. Dat geldt volgens mij ook voor de argumenten en discussies die gevoerd worden, en die vindt ik zoals gezegd nogal eens offensief of defensief . Ook als is de inhoud van de argumenten wellicht juist, het is de tone of voice die bepaald of de boodschap overkomt en dus functioneel is. Of zoals de Fransen zeggen: c'est le ton qui fait la musique. Net als met een kaart: de vorm en de inhoud vullen elkaar aan, en 1 + 1 is meer dan 2 Ik denk dat Robert best wel een punt maakt in zijn beweringen, maar ze klinken niet erg uitnodigend, en het gevolg is dat er een standpuntendiscussie oplaait die niet erg constructief is. De kaart kan inderdaad mooier, en er is zeker belangstelling of markt voor. Ik zou dan ook zeggen, kijk eens op openfietskaart, het valt me op dat ene Rubke daar heel veel werk in heeft verricht. Opencyclemap wordt door Andy Allen getrokken, kun je zo opzoeken op internet. Ik zou zeggen, mail elkaar eens, reis eens af naar elkaar, en vraag wat je aandeel kan zijn om te helpen die fietskaart er nóg mooier en professioneler uit te laten zien. Zoals Martijn al zegt: Volgens mij is het niet zo belangrijk dat we al die groepen en individuen onder één noemer brengen, maar wel dat iedereen elkaar kan vinden als het nodig is. Wat me wel opvalt is dat de OSMF , de foundation zich wat weinig laat zien in dit draadje. Ze zouden toch wel duidelijk kunnen formuleren wat het doel is (de missie), de strategie (hoe daar te komen en waarop te sturen) en de roadmap (wat wanneer en hoe gaan we dat doen). Dan zou deze deze discussie niet meer echt nodig zijn. Want kudo's scoren is toch een beetje zonde van de tijd. Ik weet dat er mensen zijn die heel wat hebben bijgedragen aan OSM, maar die om die reden nooit meer zijn terug te vinden, en hun eigen gang gaan, cq bedrijfje opzetten. Zonde. Want OSM is een prachtig fabrikaat, al is het nog niet perfect en kan het altijd beter. Dat zal allemaal vast ook wel gebeuren, want OSM wordt steeds meer volwassen. Wat alle auto-navigatieleveranciers links laten liggen en wat OSM heel goed doet is het detail van de kaart, voet- en fietspaden, de orientatie op de omgevingsdetails, zoals groen en bebouwing, bomen en POIs. Met name op het gebied van lopen, wandelen en fietsen. Alle grote GEO leveranciers (teleatlas, google, navteq) rijden met auto's en campers rond, volgehangen met video's en laserstralen, maar de fiets en voetpaden waar de OSeMmer zich begeeft op zijn fietsje met GPS: daar komen ze bijna nooit. Daarom zijn de openfietskaart en openbusmap en dergelijke zulke mooie aanvullende half- of van mijn part driekwart-fabrikaten ;-). Waar het volgens om gaat is dat OSMmers elkaar aanvullen, en elkaar uitnodigen en openstaan om elkaar aan te vullen, dat is ook terecht de boodschap van Martijn. De een kan heel goed met zn GPS overweg, de ander is goed in editen, weer een ander maakt handige tools en mooie proggies, er zijn mensen die goed structuur aan kunnen brengen in de chaos en normen opstellen, er zijn figuren die goed zijn in usability en functionaliteit en anderen in layout. Weer anderen zorgen voor een mooie zoekfunctie of routing service. En al die kikkers zitten in dezelfde O S eMmer! En samen kunnen ze een prachtig koor vormen, door met elkaar te kwaken en niet elkaars vliegen af te vangen. Ik heb respect voor al diegenen die wel meer dan één steentje hebben bijgedragen, en ook voor diegenen die opeens bijna in hun eentje - op basis daarvan - een prachtig idee verwezenlijken. Kijk bijvoorbeeld eens naar OsmAnd. Gewoon bijna 95% door één Mapthousiastic in elkaar gezet. Wellicht niet perfect, maar nu wordt het zo populair dat het aantal terabytes internet verkeer een probleem is gaan worden! Respect! All deze persoonlijke en gezamelijke initiatieven maken het geheel groter. Dus Robert, ik
[OSM-talk-nl] Fietsinventarisatie Amsterdam
Beste OSMers, zoals bekend hebben wij nog steeds de visie tot een landsdekkende (en misschien grensoverschrijvende) fietsrouteplanner op OSM-basis te komen. Omdat wij zoals eerder scherp vastgesteld een heel boos bedrijf zijn dat alleen maar geld wil verdienen proberen wij hiervoor handig zoveel mogelijk regionale projecten bij elkaar te voegen. Naast de bekende fietsrouteplanner-zuid.nl en fietsrouteplanner.nl (Twente) hebben we inmiddels ook Rotterdam en Utrecht geïnventariseerd. Voor de gemeente Amsterdam mogen wij nu een detailinventarisatie van het fietsnetwerk maken. Zij hebben dit nodig voor analyses en priorisering van onder meer investeringen in fietsinfrastructuur. Deze inventarisatie doen we (met hun toestemming) natuurlijk in OSM om weer een stap verder naar de landelijke dekking te komen. De komende weken fietsen 2-3 veldwerkers van ons meer dan 700 km fietsinfrastructuur af in Amsterdam, en zullen dit in tracks, tags, voice-messages en fotos via osmtracker vastleggen en korte tijd later in JOSM invoeren. De ontstaande data wordt door ons dubbel gelicenseerd en mag door de gemeente Amsterdam zonder beperkingen, en verder door iedereen onder de CC-BY-SA (ja, we moeten nog over naar de nieuwe licentie...) gebruikt worden. Voor wie dit interessant vindt: we hebben de interne handleiding voor het invoeren in JOSM op http://osm.goudmap.info/amsterdam gezet. Graag zou ik een pagina aanmaken op wiki.openstreetmap.org waar ik het volgende beschrijf: - wat is nodig om zinvol routes te kunnen plannen voor de fiets - welke regio's zijn al door ons onder handen genomen (met uitnodiging dat vrijwilligers inschrijven om ontbrekende regio's te doen) - aanbevelingen voor te gebruiken tags - links van draaiende fietsrouteplanners - beschrijving onze api om osm-fietsroutes uit je eigen app (web of mobiel) te laten bepalen Zijn daar regels voor of mag ik zomaar een wiki-pagina aanmaken en verlinken? Groeten Dirk Dirk Bussche Senior Adviseur Geografische Toepassingen T +31 (0)570 666 830 #9642; E dbuss...@goudappel.nl (aanwezig op kantoor: maandag, dinsdag en woensdag) Goudappel Coffeng #9642; Snipperlingsdijk 4 #9642; 7417 BJ Deventer #9642; Postbus 161 #9642; 7400 AD Deventer #9642; The Netherlands #9642; www.goudappel.nl Goudappel Coffeng BV is gevestigd in Deventer, Den Haag, Eindhoven, Leeuwarden en Amsterdam ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Diese Antwort bezieht sich jetzt sowohl auf die Mail von Garry als auch auf die andere Antwort von Martin. Natürlich ist das keine Optimale Lösung, und nein, ich würde dieses Tool nicht einsetzen um die manuelle Unterteilung zu ersetzen. Ich denke aber, dass es sinnvoll sein könnte, die großen landuses erstmal automatisch zu teilen, um dann manuell die Grenzen zu verfeinern. Deine Aussage, Garry, damit gingen Daten verloren, stimmt ja nur, wenn du vorher landuses zusammenfasst, wo die Daten schon genauer sind. Da, wo Wälder über Bundesstraßen etc. liegen, sind die Daten aber noch nicht in der Datenbank. Gruß Peter P.S.: Nein, ich würde das Tool auch nicht als vollautomatisches Update laufen lassen wollen, sondern z.B. als JOSM-Plugin, mit dem ich ein landuse entsprechend splitten und dann nachbearbeiten kann - und dafür stell ich mir das ganz praktisch vor, weil einiges an Arbeit entfällt, die man beim systematischen manuellen Aufteilen hätte: Den alten Grenzverlauf da nachzuziehen, wo das große landuse-Poly zu Ende war, das Erstellen einer Relation, wenn gewünscht, das Setzen der Tags auf der Relation (oder alternativ auf den einzelnen Polygonen) und so weiter. Am 19.05.2011 01:23, schrieb Garry: Am 18.05.2011 14:38, schrieb Peter Wendorff: Am 18.05.2011 13:18, schrieb M∡rtin Koppenhoefer: Am 18. Mai 2011 12:56 schrieb Martin Simongrenzde...@gmail.com: Am 18. Mai 2011 11:59 schrieb M∡rtin Koppenhoeferdieterdre...@gmail.com: Zugegebenermaßen ist das Geschmackssache, aber ich gebe hier zu bedenken, dass man problemlos größere Gebiete von angrenzenden gleichen Nutzungen automatisch zusammenfassen kann. Es ist aber unmöglich, aus großen Gebieten automatisch einzelne kleinere Gebiete zu bilden. Aufgabe an gelangweilte Programmierer (falls es solche gibt): Tool, das genau das Problem löst: Schneide aus einem landuse=*-Polygon highway=*-Linienzüge mit (konfigurierbarem) Puffer oder, noch besser, unter Berücksichtigung von dessen width-Tag aus. ;) Gut dass Du den Smiley nicht vergessen hast. Dass kann man als Notlösung dort machen wo die Daten noch nicht besser sind. Markante Konturen gehen so verloren da sich bestenfalls der minimale, aber nie der reale Abstand zwischen Fahrbahn und Waldgrenze angeben lässt. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Lizenzwechsel-Simulation / Bachelor-Arbeit von Jakob Altenstein
Hallo, im Maerz hat Jakob Altenstein seine Bachelor-Arbeit zum Lizenzwechsel in OSM fertiggestellt. Die Arbeit ist von mir mit betreut worden. Es ging dabei darum, die Folgen des Lizenzwechsels zu visualisieren (was muss geloescht werden, was bleibt, was aendert sich) und auch einen Algorithmus zu bauen, der einen existierenden Datenbestand in einen post-Lizenzwechsel-Datenbestand ueberfuehren kann. Die Arbeit gibt es jetzt als PDF hier: http://checkout.yourweb.de/thesis/Jakob_Altenstein_Thesis.pdf Jakob hat eine Software in Java entwickelt, die als Input einen Ausschnitt aus dem Full-History-File und die aktuelle Liste der ODbL-Zustimmer bekommt, und als Output dann entweder ein modifiziertes OSM-File erzeugen kann, in dem alles so abgeaendert ist, wie es waere, wenn morgen der Lizenzwechsel kaeme, oder alternativ ein OSM-File auf dem neusten Datenstand mit zusaetzlichen Pseudo-Tags, an denen man erkennen kann, ob ein Objekt gefaehrdet ist. Zusaetzlich hat Jakob auch Maperitive-Renderregeln gebaut, anhand derer man eine so erzeugte Datei dann schoen anzeigen kann. Der Code ist in svn.openstreetmap.org/applications/utils/filter/odblsimulator und kann ausprobiert werden. Das benoetigte History-Extrakt muss man sich derzeit allerdings meistens selber herstellen (siehe dazu auch Peter Koerners Posting hier: http://lists.openstreetmap.org/pipermail/dev/2011-May/022624.html). Die Software ist sicher noch nicht perfekt und hat noch ein paar Eigenarten, die fuer die Arbeit egal waren, fuer den praktischen Einsatz aber hinderlich sind, z.B. dass Dateinamen fest im Programm drinstehen statt konfigurierbar zu sein und so weiter - aber vielleicht hat jemand ja Lust, an der Sache weiter zu arbeiten. Das PDF der Bachelor-Arbeit ist eigentlich eine sehr gute Programmdokumentation. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Simulation / Bachelor-Arbeit von Jakob Altenstein
Am 19. Mai 2011 11:54 schrieb Frederik Ramm frede...@remote.org: Hallo, im Maerz hat Jakob Altenstein seine Bachelor-Arbeit zum Lizenzwechsel in OSM fertiggestellt. interessante Arbeit mit (zum damaligen Lizensierungsstand) beeindruckender Visualisierung der Auswirkungen auf die Karlsruher Innenstadt. Ich finde allerdings die Annahme, dass man bei einer Straße alles löschen muss, wenn der Ersteller der Version 1 nicht zugestimmt hat, ein bisschen hart. Gesetzt den Fall, diese Straße besteht in der aktuellen Version nur noch aus Nodes, die von Zustimmern bewegt wurden, wären m.E. nur noch die Tags auf dem Way, die in Versionen von Nichtzustimmern hinzugefügt wurden, zu entfernen. Dann sähe das Bild sicherlich ziemlich anders aus. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Simulation / Bachelor-Arbeit von Jakob Altenstein
Am 19.05.2011 12:10, schrieb M∡rtin Koppenhoefer: interessante Arbeit mit (zum damaligen Lizensierungsstand) beeindruckender Visualisierung der Auswirkungen auf die Karlsruher Innenstadt. In der Tat ... Dann sähe das Bild sicherlich ziemlich anders aus. Ein dickes Problem wurde dezent ausgeklammert: S. 15: Teilen (und m.E. auch Vereinigen) von Wegen. In Bezug auf den Lizenzwechsel ist das problematisch, da bei der Analyse das Urheberrecht an diesen Objekten unterschlagen würde. Das drückt m.E. sehr drastisch, aber auch wahrheitsgemäß aus, dass wir ohne Lösung dieses Problems den Lizenzwechsel auch aus rechtlichen Gründen knicken können, da das Ergebnis dann höchst angreifbar wäre ... Die folgende Frage habe ich schon diverse Male gestellt, aber mir ist keine Antwort erinnerlich ...: Arbeitet jemand schon an diesen Problem, die Versionsgeschichte incl. Teilungen/Vereinigungen komplett zu kriegen? Wäre ja nicht nur für Lizenzfragen interessant, sondern auch ganz trivial, um bei Edits die Entwicklung eines ways besser nachvollziehen zu können, bspw. um rauszufinden, wer x=y drangehängt hat zum fragen warum dies ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnübergang
Am 11.05.2011 18:00, schrieb Wolfgang: ich habe im Wiki nichts über beschrankt/unbeschrankt etc gefunden. Habe ich etwas übersehen? Im Forum gab's relativ kürzlich eine ähnliche Fragestellung: http://forum.openstreetmap.org/viewtopic.php?id=11082 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Simulation / Bachelor-Arbeit von Jakob Altenstein
Hallo, On 05/19/11 12:10, M?rtin Koppenhoefer wrote: interessante Arbeit mit (zum damaligen Lizensierungsstand) beeindruckender Visualisierung der Auswirkungen auf die Karlsruher Innenstadt. Ich finde allerdings die Annahme, dass man bei einer Straße alles löschen muss, wenn der Ersteller der Version 1 nicht zugestimmt hat, ein bisschen hart. Ich sehe da wenig Alternativen. Aber ich habe die Hoffnung, dass einige Mapper, die zu dem Thema eigene Ideen haben, wie Du... Gesetzt den Fall, diese Straße besteht in der aktuellen Version nur noch aus Nodes, die von Zustimmern bewegt wurden, wären m.E. nur noch die Tags auf dem Way, die in Versionen von Nichtzustimmern hinzugefügt wurden, zu entfernen. Dann sähe das Bild sicherlich ziemlich anders aus. ... aufgrund des vorliegenden Programmcodes solche Ideen auch ausprogrammieren koennen und wir dadurch, wenn es dann mal so weit ist, besser ueber alles reden koennen, huebsche Bilder zu jeder denkbaren Vorgehensweise haben und so weiter ;) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Simulation / Bachelor-Arbeit von Jakob Altenstein
Hi, On 05/19/11 12:34, Heiko Jacobs wrote: Die folgende Frage habe ich schon diverse Male gestellt, aber mir ist keine Antwort erinnerlich ...: Arbeitet jemand schon an diesen Problem, die Versionsgeschichte incl. Teilungen/Vereinigungen komplett zu kriegen? Ob jemand schon daran arbeitet, weiss man natuerlich nicht, es gibt ja viele, die im stillen Kaemmerlein was tun. Aber es hat noch niemand *gesagt*, dass er daran arbeitet. Ich halte das fuer ein recht einfaches Problem, und wenn es bis zum Lizenzwechsel niemand anders gemacht hat, werde ich da wohl was basteln muessen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Simulation / Bachelor-Arbeit von Jakob Altenstein
Heiko Jacobs schrieb: Das drückt m.E. sehr drastisch, aber auch wahrheitsgemäß aus, dass wir ohne Lösung dieses Problems den Lizenzwechsel auch aus rechtlichen Gründen knicken können, da das Ergebnis dann höchst angreifbar wäre ... Es ist so weit ich weiß nicht mal klar, ob wir aus rechtlichen Gründen *irgendwas* löschen müssen, um den Lizenzwechsel durchzuführen, es gäbe wahrscheinlich einige rechtliche Lücken, durch die wir schlüpfen könnten und alle Daten in die neue Lizenz befördern könnten - zumindest gibt es dazu einige einschlägige Meinungen. Alles in allem sind wir mit unserer Vorgangsweise schon jetzt ziemlich übervorsichtig und mangels starker Führung in der Community sowieso viel zu zweifelnd und langsam. Robert Kaiser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Große Plots erstellen
HI ! wenn man doch mit mapnik große Plots erstellt werden, dann werden doch (meines Wissens) Kacheln generiert die dann später zu einem Plot zusammengestellt werden. Nun gibt es auch andere Renderer die Kacheln erzeugen - kann mir einer sagen wie man solche Kacheln am einfachsten zusammenbaut aus einem Dateiverzeichnis ?? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Große Plots erstellen
Am 19. Mai 2011 15:00 schrieb Jan Tappenbeck o...@tappenbeck.net: wenn man doch mit mapnik große Plots erstellt werden, dann werden doch (meines Wissens) Kacheln generiert die dann später zu einem Plot zusammengestellt werden. man kann mit Mapnik auch große Bilder rendern, z.B. mit dem script generate_image.py dass bei mapnik dabei ist. Wenn Du die Ausgabe als svg (oder pdf?) machst, hast Du einige Nachteile der auf kleine Auflösungen optimierten bitmaps nicht (wobei die Icons sofern nicht als svg vorliegend trotzdem pixelig werden). Sehr große svgs machen allerdings wohl auch Probleme beim Drucken. Nun gibt es auch andere Renderer die Kacheln erzeugen - kann mir einer sagen wie man solche Kacheln am einfachsten zusammenbaut aus einem Dateiverzeichnis ?? Bestimmt gibt es dafür auch irgendwo ein fertiges Script, spontan fällt mir allerdings nur Openlayers ein. Am einfachsten scheint mir, Du renderst gleich ein großes Bild. Es gibt auch das Script bigmap.cgi mit dem man recht große Bilder aus tiles machen kann. http://wiki.openstreetmap.org/wiki/Bigmap Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 19.05.2011 08:50, schrieb Peter Wendorff: Diese Antwort bezieht sich jetzt sowohl auf die Mail von Garry als auch auf die andere Antwort von Martin. Natürlich ist das keine Optimale Lösung, und nein, ich würde dieses Tool nicht einsetzen um die manuelle Unterteilung zu ersetzen. Ich denke aber, dass es sinnvoll sein könnte, die großen landuses erstmal automatisch zu teilen, um dann manuell die Grenzen zu verfeinern. Deine Aussage, Garry, damit gingen Daten verloren, stimmt ja nur, wenn du vorher landuses zusammenfasst, wo die Daten schon genauer sind. Da, wo Wälder über Bundesstraßen etc. liegen, sind die Daten aber noch nicht in der Datenbank. Gruß Peter P.S.: Nein, ich würde das Tool auch nicht als vollautomatisches Update laufen lassen wollen, sondern z.B. als JOSM-Plugin, mit dem ich ein landuse entsprechend splitten und dann nachbearbeiten kann - und dafür stell ich mir das ganz praktisch vor, weil einiges an Arbeit entfällt, die man beim systematischen manuellen Aufteilen hätte: Den alten Grenzverlauf da nachzuziehen, wo das große landuse-Poly zu Ende war, das Erstellen einer Relation, wenn gewünscht, das Setzen der Tags auf der Relation (oder alternativ auf den einzelnen Polygonen) und so weiter. Achso, Du willst das Tool auf die Daten selbst loslassen, ich hatte es so verstanden dass es nur zum Rendern eingesetzt werden soll. Klingt erstmal nicht schlecht, aber ob dass auch zuverlässig in den komplexen Gebieten funktioniert wo grosszügig mit inner/outer gearbeitet wurde? Als eins der einfacheren Beispiele: Eine Ortschaft an einer Bundesstrasse die ringsum von Wald umgeben ist und deren landuse=residential als inner für das Waldgebiet angelegt wurde... Gruss Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 19. Mai 2011 16:13 schrieb Garry garr...@gmx.de: Am 19.05.2011 08:50, schrieb Peter Wendorff: Als eins der einfacheren Beispiele: Eine Ortschaft an einer Bundesstrasse die ringsum von Wald umgeben ist und deren landuse=residential als inner für das Waldgebiet angelegt wurde... Da kann man als erstes mal den Wald an der Straße in 2 Teile teilen, dann braucht man meistens schon mal kein Multipolygon für die Ortschaft mehr. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Große Plots erstellen
jan99 wrote: Nun gibt es auch andere Renderer die Kacheln erzeugen - kann mir einer sagen wie man solche Kacheln am einfachsten zusammenbaut aus einem Dateiverzeichnis ?? Die billigste Methode, die ich kenne, ist - OpenLayers SlippyMap im Browser einrichten - Karte durch entsprechende Größenangabe im html großziehen, z.B. width=400% - mit einem Firefox-Plugin (dessen Name mir grade entfallen ist) Screenshot davon ziehen Vorteil ist, daß Du ständig siehst was dabei rauskommen wird. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Gro-e-Plots-erstellen-tp6381848p6382462.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] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 19.05.2011 17:05, schrieb M∡rtin Koppenhoefer: Am 19. Mai 2011 16:13 schrieb Garrygarr...@gmx.de: Als eins der einfacheren Beispiele: Eine Ortschaft an einer Bundesstrasse die ringsum von Wald umgeben ist und deren landuse=residential als inner für das Waldgebiet angelegt wurde... Da kann man als erstes mal den Wald an der Straße in 2 Teile teilen, dann braucht man meistens schon mal kein Multipolygon für die Ortschaft mehr. Das schon, aber die Frage ist ob ,man damit auch zuverlässig die bis dahin verwendeten Multipolygon-Tags (inner) löschen kann ohne etwas anderes zu zerschiessen.. Oder was ich auch schon hatte dass bei grossen Waldgebiet die ich zerteilt hatte Grenzlinien zwischen zwei grossen Teilfächen verliefen die keine natürliche Ursache (Strasse,Gewässer,etc) hatte. Da war nicht zu erkennen ob diesel Linie einen anderen Hintergrund hatte als nur die beiden Teilfächen zu teilen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Garry schrieb am 19.05.2011 17:51: Oder was ich auch schon hatte dass bei grossen Waldgebiet die ich zerteilt hatte Grenzlinien zwischen zwei grossen Teilfächen verliefen die keine natürliche Ursache (Strasse,Gewässer,etc) hatte. Da war nicht zu erkennen ob diesel Linie einen anderen Hintergrund hatte als nur die beiden Teilfächen zu teilen. Es hat halt jeder so seine eigene Mapping-Technik, jeder Ansatz hat ja auch seine Vor- und seine Nachteile. Bei den Flussflaechen z.B. gibt es in meiner Region einen Mapper, der an den Trennstellen die beiden Teile immer ein wenig ueberlappen lasst. Das sorgt dann dafuer, dass Renderer an der Schnittstelle keinen sichtbaren Streifen erzeugt, aber ueberlappende Fluss-Abschnitte ist datentechnisch natuerlich totaler Bloedsinn. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Simulation / Bachelor-Arbeit von Jakob Altenstein
Am 19.05.2011 14:39, schrieb Robert Kaiser: Es ist so weit ich weiß nicht mal klar, ob wir aus rechtlichen Gründen *irgendwas* löschen müssen, um den Lizenzwechsel durchzuführen, es gäbe wahrscheinlich einige rechtliche Lücken, durch die wir schlüpfen könnten und alle Daten in die neue Lizenz befördern könnten - zumindest gibt es dazu einige einschlägige Meinungen. Auf welchen von mir wohl verpassten Diskussionen baust Du diese Meinung auf? Und wo kann man nachlesen, dass wir die Zuständigen schon nahezu überzeugt haben? ;-) Deine Botschaft höre ich wohl, allein mir fehlt der Glaube daran ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] See in Wald in (L|N)SG - Sichtbarkeitsproblem
Am 19. Mai 2011 17:51 schrieb Garry garr...@gmx.de: Da kann man als erstes mal den Wald an der Straße in 2 Teile teilen, dann braucht man meistens schon mal kein Multipolygon für die Ortschaft mehr. Das schon, aber die Frage ist ob ,man damit auch zuverlässig die bis dahin verwendeten Multipolygon-Tags (inner) löschen kann ohne etwas anderes zu zerschiessen.. klar, das ist ein Punkt wo man sich das ganze gründlich ansehen muss. Habe neulich auch ein Multipolygon geteilt. Das ist viel Arbeit, man muss die ganzen inners von einem aufs andere schieben und zusehen, dass man nichts übersieht. Aber der Editor ist mittlerweile auch deutlich besser geworden als noch vor Jahren. Man kann die Sachen auswählen, dann aus dem einen ausschließen, und im gleichen Zug dem anderen MP zuschlagen (da sie noch selektiert sind). Über Relation selektieren kann man dann nochmal visuell prüfen, ob alles stimmt. Das macht man ein paarmal, dann sollte es hinhauen. Fehler findet in dem Bereich auch der Validator zuverlässig (inners die ausserhalb der outer liegen). Oder was ich auch schon hatte dass bei grossen Waldgebiet die ich zerteilt hatte Grenzlinien zwischen zwei grossen Teilfächen verliefen die keine natürliche Ursache (Strasse,Gewässer,etc) hatte. Da war nicht zu erkennen ob diesel Linie einen anderen Hintergrund hatte als nur die beiden Teilfächen zu teilen. wenn sie nicht getaggt ist und nicht mind. einer der Wälder einen unterschiedlichen Tag hat, dann ist es zumindest aus Datensicht erstmal egal. Wer da nichtmal einen note an seine Mitmapper hinterlässt, braucht sich hinterher auch nicht zu beschweren. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Simulation / Bachelor-Arbeit von Jakob Altenstein
Heiko Jacobs schrieb: Am 19.05.2011 14:39, schrieb Robert Kaiser: Es ist so weit ich weiß nicht mal klar, ob wir aus rechtlichen Gründen *irgendwas* löschen müssen, um den Lizenzwechsel durchzuführen, es gäbe wahrscheinlich einige rechtliche Lücken, durch die wir schlüpfen könnten und alle Daten in die neue Lizenz befördern könnten - zumindest gibt es dazu einige einschlägige Meinungen. Auf welchen von mir wohl verpassten Diskussionen baust Du diese Meinung auf? 1) Gibt es die teilweise gängige Meinung, dass jemand in den USA derzeit alle unsere Daten unter PD verwenden könnte. Das heißt, es könnte jemand dort theoretisch eine Kopie unserer Datenbank ziehen, unter PD zur Verfügung stellen, und wir könnten sie unter jeglicher Lizenz re-importieren. Theoretisch, natürlich. ;-) 2) Wurde ich denke auf der legal-Liste (keine Zeit, um Details für derartiges theortetischen Geplänkel rauszusuchen, ich hab auch eine echte Arbeit - obwohl die auch im Umfeld offener Daten und Software steht) durchaus glaubwürdig behauptet, dass Gerichte eine Mitarbeit an einem Gemeinschaftsprojekt so deuten, dass jene Organisation, unter deren Schirmherrschaft die Freiwilligen ihre Arbeit verrichten, auch zum Gute des Projekts sein legales Umfeld korrigieren können, ohne jeden Beitragenden zu fragen, ob sein Beitrag damit vereinbar ist. Dieser Monstersatz heißt im Klartext: Sollte unser Fall vor Gericht kommen, wird der OSMF höchstwahrscheinlich Recht gegeben, sogar wenn sie einfach ohne zu fragen die ganze Datenbank einfach auf ODbL umstellen und nichts löschen würde. Und wo kann man nachlesen, dass wir die Zuständigen schon nahezu überzeugt haben? ;-) Gar nirgends, weil das alles pure Theorie ist, und niemand Zuständiger von irgendwem in dieser Richtung überzeugt wurde. Mal abgesehen davon, dass ich bei osm den Eindruck habe, dass keine Verantwortung tragen und klare Entscheidungen treffen will, also kann ich zuständig wohl nur unter Anführungszeichen setzen. Deine Botschaft höre ich wohl, allein mir fehlt der Glaube daran ... Mir fehlt zwar nicht der Glaube, dass die Theorien haltbar wären, aber mehr sind sie halt nicht - und Entscheidungsschwäche ist wohl der zweite Vorname unserer Community. Robert Kaiser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM | Kartenmaterial | Anwendungsmöglichkeit |GARMIN.img
Hinweis: Da diese Mail wegen eines technischen Fehlers an der falschen Stelle landete, sende ich sie nochmal, um einen neuen Thread zu erzeugen. = Hallo Zusammen! Vielleicht hat ein GARMIN + Windows + Mapsource-Nutzer eine Antwort auf meine Frage. Ausgangslage: - GARMIN Vista eTrex Hcx - GARMIN TOPO DE (2007) - GARMIN City Navigator NT - Win7 (32) PC - Suche für das Routing am PC über Mapsource +Startpunkt = Adresse oder Wegpunkt +Endpunkt = Adresse Funktioniert für die Planung am PC und unterwegs einwandfrei Ziel: Mit gleicher Hard- und Software die GARMIN-Karten ersetzen (weil alt) und statt dessen OSM-Kartenmaterial von http://www.raumbezug.eu/ag/internet/osmGarmin.htm aus der Quelle http://download.geofabrik.de/osm/europe/germany/ verarbeitet u.a. mit Mkgmap zu verwenden. Problem: - Kartenmaterial nach Anleitung (http://www.raumbezug.eu/downloads/dl/dl.php?id=31 )in Mapsource geleitet, aber eine Adresssuche ist dort nicht möglich. - Kartenmaterial über Mapsource nach Speicherkarte GARMIN geleitet (nicht immer die ganze Karte, sondern ausgewählte Tiles und auch Stücke anderen Materials, wie z.B. der TOPO, daher durch Mapsource): auch keine Adresssuche - Routing nur von und zu bekannten POI oder Koordinaten Die vorverarbeitende Anwendung http://wiki.openstreetmap.org/index.php/Mkgmap beschreibt ja noch ein paar offene Baustellen. Frage: Sehe ich es richtig, dass ich das, was ich bisher mit dem GARMIN-Kartenmaterial gemacht habe, so mit aus dem unter Ziel genannten Quellen erhältlichen Material nicht genauso tun kann? Gruß Thomas P.S. Da diese Mail wegen eines technischen Fehlers an der falschen Stelle landete, sende ich sie nochmal, um einen neuen Thread zu erzeugen. == Bisherige Antwort auf meine Frage: fla...@googlemail.com Wed, 18 May 2011 11:06:46 -0700 instaliere mal eine Karte von hier (http://dev.openstreetmap.de/aio/germany-daily/nsis/) das sollte die Suche teilweise funktionieren, auch wenn man die Daten überträgt. Was teilweise nun bedeutet .. muss jeder selber für seine Bedürfnisse klären. Dirk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kein Micromapping mit landuse (war: See in Wald in (L|N)SG)
Am 18.05.2011 11:59, schrieb M∡rtin Koppenhoefer: Am 18. Mai 2011 11:30 schrieb Garrygarr...@gmx.de: Gerade landuse=rail (ebenso highway, insbesondere motorway/trunk) sollte kein inner einer Waldfläche sein sondern eine Trennfläche zwischen zwei einzelnen in sich geschlossenene Waldpolygonen ohne gemeinsamen nodes. Für landuse=rail und highway=motorway/trunk stimme ich voll zu. Generell betrachte ich Wege, die ein Gebiet erschließen (Feldwege, Waldwege, Straßen in Wohn- und Gewerbegebieten) als Teil der landuse-Fläche. Hat ein Weg keine lokale Erschließungsfunktion (Autobahn, Kraftfahrstraße, Bahnstrecke außer Industriegleis) dann lasse ich die landuse-Fläche neben dem Weg enden. Ein highway=primary mit dichter Randbebauung kann in landuse=residential liegen, ein Radweg zwischen Kleingarten und Friedhof mit keinem davon verbunden sein. Das entspricht etwa dem üblichen Sprachgebrauch (Weg führt durch den Wald - Autobahn teilt den Wald). Die meisten Mapper verwenden offenbar eine ähnliche Definition und schließen Wege und kleine Straßen in landuse-Flächen ein. Die ATKIS-Daten der Landesvermessungsämter (siehe z.B. [1]) nehmen selbst größere Straßen in Wohngebiete, Wälder und Wiesen auf. Einzelne identifizierbare Flächen würde ich als solche mappen, und nicht zusammenfassen. Aber bitte nicht als landuse. landuse ist im Wiki mehrfach als größeres Gebiet mit einer hauptsächlichen Nutzung definiert. Für viele Darstellungen ist solch eine Generalisierung wertvoll. Micromapping hat für andere Anwendungen Vorzüge. Wer Gebiete in Einzelgrundstücke zerlegen will und diese wiederum in Acker, Hecke, Wohngebäude, Rasen, Gemüsebeet etc. teilen will, mag sich austoben, aber er sollte andere Tags nutzen. Wie ich es machen würde: http://www.openstreetmap.org/browse/way/106441866 -1. Dort sind sogar Hecken, die sicherlich Teil der Flurstücke sind, aus der landuse-Fläche ausgeschnitten. Viele Grüße, Stephan [1] http://onmaps.de/st/deutschland.php ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Firenze, 26 maggio: meeting ad Architettura
Giovedi 26 Maggio, alle 17:00 presso la Facoltà di Architettura di Firenze, Sede di Santa Verdiana, Aula 1 (Piazza Ghiberti, 27 [1]) si terrà un incontro sui temi: Cartografia resistente: derive sul territorio http://cartografiaresistente.org/ OpenStreetMap: svolgimento libero. (dovrei parlare io, vedremo di cosa, dipende dai presenti :-) Purtroppo l'evento è stato annunciato solo su Facebook, in modo non pubblico. Chi avesse l'account lo può cercare. Un invito ai mappatori fiorentini (che ci sono, ma non socializzano mai) a farsi vedere! Saluti. [1] http://www.openstreetmap.org/?mlat=43.770671mlon=11.266467zoom=18layers=M -- Niccolo Rigacci Firenze - Italy Tel. ufficio: 055-0118525 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Firenze, 26 maggio: meeting ad Architettura
On Thu, May 19, 2011 at 09:33:45AM +0200, Niccolo Rigacci wrote: Giovedi 26 Maggio, alle 17:00 presso la Facoltà di Architettura di Firenze, Sede di Santa Verdiana, Aula 1 (Piazza Ghiberti, 27 [1]) Correggo di qualche metro le coordinate del luogo: http://www.openstreetmap.org/?mlat=43.77023mlon=11.267416zoom=18layers=M -- Niccolo Rigacci Firenze - Italy Tel. ufficio: 055-0118525 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Firenze, 26 maggio: meeting ad Architettura
Il 19 maggio 2011 09:43, Niccolo Rigacci o...@rigacci.org ha scritto: On Thu, May 19, 2011 at 09:33:45AM +0200, Niccolo Rigacci wrote: Giovedi 26 Maggio, alle 17:00 presso la Facoltà di Architettura di Firenze, Sede di Santa Verdiana, Aula 1 (Piazza Ghiberti, 27 [1]) Correggo di qualche metro le coordinate del luogo: http://www.openstreetmap.org/?mlat=43.77023mlon=11.267416zoom=18layers=M Ho visto che avevi aggiunto l'evento in homepage ma non nel portale italiano, fatto! PS non è quasi l'ora di creare la pagina su firenze?? -- Niccolo Rigacci Firenze - Italy Tel. ufficio: 055-0118525 -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Pensiline / tettoie distributori benzina
Qualcuno mi sa dire come si indicano le pensiline o tettoie dei distributori di benzina, quelle con sotto le pompe tanto per intenderci. Grazie morsi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Pensiline / tettoie distributori benzina
2011/5/19 MorSi mo...@inwind.it: Qualcuno mi sa dire come si indicano le pensiline o tettoie dei distributori di benzina, quelle con sotto le pompe tanto per intenderci. io le mappo con building=roof e se passa un percorso sotto anche con layer=1 (nel caso dei distributori c'è sempre un percorso sotto). Non ti aspettare granchè dal ufficiale rendering attuale, viene renderizzato come un edificio, ma col tempo, se inseriamo abbastanza di queste, chi lo sa. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Trasformare Marcatori in Punti da mappare??
Ciao, da un file .kml ho ricavato un percorso e anche molti punti d'interesse come ad esempio rifugi fontane parcheggi etc.. solo che tutti questi punti su josm mi vengono visualizzati come dei marcatori che non riesco a trasformare in punti da aggiungere al livello per poter caricarli.. come devo fare? - http://www.openstreetmap.org/user/Orlandi_IT_EmiliaRomagna -- View this message in context: http://gis.638310.n2.nabble.com/Trasformare-Marcatori-in-Punti-da-mappare-tp6383667p6383667.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Mappare i porti
Salve a tutti. Sulla scia dell'inserimento dei nuovi confini istat ho proceduto a migliorare anche la linea di costa e mi sono imbattuto nel problema dei porti, come mapparli? Ho trovato l'apposita pagina sul wiki (http://wiki.openstreetmap.org/wiki/IT:Harbour) che spiega come fare ma mi sono rimasti alcuni dubbi. In quella pagina si spiega che tutte le strutture del porto a contatto con l'acqua devono essere mappate come natural=coastline, in pratica la linea di costa entra nel porto, ne segue tutto il profilo fino a uscirne dall'altro lato. Tuttavia molti porti sono costruiti alla foce di fiumi, come si fa a sapere dove finisce la costa e inizia il fiume? Come taggare le darsene, ovvero quelle parti del porto dove si parcheggiano le barche? Finora ho usato waterway=dock, anche perché josm usa quel tag selezionando la voce darsena dalle preimpostazioni, ma sul wiki specifica che va usato per specchi d'acqua chiudibili utilizzati per le riparazioni. -- Samuele Battarra batta...@email.it signature.asc Description: This is a digitally signed message part. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Tag per negozi di bici (service:bicycle) approvati!
Ciao, la votazione per il nuovo namespace service:bicycle si è conclusa e il tag è stato approvato (20 voti: 17 a favore e 3 contrari). Non ho ancora sistemato per bene la pagina (si trova qui: http://wiki.openstreetmap.org/wiki/Proposed_features/service:bicycle) ma direi che il namespace si può già usare. Breve riassunto: si tratta di un set di 7 chiavi (per ora) che accettano valori yes/no e permettono di descrivere meglio i servizi offerti dai negozi di biciclette (amenity=shop) ma non solo. Ad esempio si possono indicare le strutture ricettive che noleggiano biciclette, oppure i posti dove è disponibile gratuitamente una pompa da bici, ecc. Mi piacerebbe che qualcuno esperto di JOSM / Potlatch 2 mi aiutasse ad aggiungerlo ai preset. Cioè bisognerebbe editare i preset per shop=bicycle in modo da gestire queste specificazioni aggiuntive. Chi mi dà una mano? Grazie, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mappare i porti
2011/5/19 Samuele Battarra batta...@email.it: In quella pagina si spiega che tutte le strutture del porto a contatto con l'acqua devono essere mappate come natural=coastline +1 , in pratica la linea di costa entra nel porto, ne segue tutto il profilo fino a uscirne dall'altro lato. si, faccio anchio così. Se le mole sono galleggianti la linea di costa passa sotto. Tuttavia molti porti sono costruiti alla foce di fiumi, come si fa a sapere dove finisce la costa e inizia il fiume? devi misurare la quantità del sale nell'acqua. In teoria ;-). In pratica farei come sembra giusto (forse fai entrare la linea di costa per qualche metro, ma non importa molto secondome). Cosa a me interessa, e non ne sono certo: dove passa il confine del comune, della provincia e della regione? Comprende anche le parti del mare dentro il porto? Suppongo di si. Perchè un confine come l'ho mappato qui mi sembra assurdo: http://www.openstreetmap.org/?lat=42.09798lon=11.78211zoom=15layers=M penso che dovrei fare una cosa del genere: http://www.openstreetmap.org/?lat=42.094167lon=11.78917zoom=18layers=M anche per una parte più grande, vero? ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Tag per negozi di bici (service:bicycle) approvati!
2011/5/19 Federico Cozzi f.co...@gmail.com: ma direi che il namespace si può già usare. certo. si poteva già usare prima ;-) Mi piacerebbe che qualcuno esperto di JOSM / Potlatch 2 mi aiutasse ad aggiungerlo ai preset. Cioè bisognerebbe editare i preset per shop=bicycle in modo da gestire queste specificazioni aggiuntive. Chi mi dà una mano? per JOSM lo faceva in passato sempre Christoph Eckert ( c...@christeck.de ). PL2 non lo so. In realtà non è difficile, se ti prendi il file dei preset attuali lo capisci quasi subitò come funziona. penso (non sono sicuro) che il file da modificare è quello: http://josm.openstreetmap.de/svn/trunk/data/defaultpresets.xml (se te lo mettono dentro e non dicono che devi fare un optional preset). Al inizio del file è anche spiegato come funziona e una riferenza a questa pagina: http://josm.openstreetmap.de/wiki/TaggingPresets. ciao Martin qui le spiegazioni: !-- item: name: the text to display icon: the icon to display - relative to the icon path - URL's are also supported to allow remote icons (are cached locally) type: the data types - way,node,relation,closedway (separated by comma) link: link to the relating map features website label: simple static text label text: the text to display key: fixed key/value pair to be set key: key to set value: value to set text: text box key: key to set text: fixed label to display default: default string to display delete_if_empty: true/false use_last_as_default: true/false combo: combo box, with multiple choices and possible to enter free form text key: key to set text: fixed label to display values: comma separated list of values display_values: comma separated list of values to be displayed instead of the database values, order and number must be equal to values short_description: comma separated list of texts to be displayed below each display_value. (Only if it is not possible to describe the entry in 2-3 words.) Instead of comma separeted list, you can also write it in the following form: short_descriptionfirst description/short_description ... short_descriptionlast description/short_description default: default string to display delete_if_empty: true/false use_last_as_default: true/false multiselect: list of values from which zero or more can be selected key: key to set text: fixed label to display delimiter: character that separates values (default: semicolon) - this will also be used to separate selected values in the tag. values: delimiter-separated list of values (delimiter can be escaped with backslash) display_values: delimiter-separated list of values to be displayed instead of the database values, order and number must be equal to values short_description: delimiter-separated list of texts to be displayed below each display_value. (Only if it is not possible to describe the entry in 2-3 words.) Instead of a separated list, you can also write it in the following form: short_descriptionfirst description/short_description ... short_descriptionlast description/short_description default: default string to display delete_if_empty: true/false use_last_as_default: true/false check: checkbox key: key to set text: fixed label to display default: ticked on/off delete_if_empty: true/false value_on: the value to set when checked (default is yes) value_off: the value to set when unchecked (default is 'no') role: type to specify possible roles in relations key: the role name used in relation text: fixed label to display requisite: optional or required (default is optional) count: how often can the role occur (if not given unlimited number is assumed) type: the data types - way,node,relation,closedway (separated by comma) For external files the presets should have following elements: - author the author of the preset - version a version number of some sort (e.g. creation date) - description what is your preset meant to be - shortdescription very short description - link a link to a helpful website (optional) - The fields description, shortdescription and link may also be localized (e.g. de.link) See also http://josm.openstreetmap.de/wiki/TaggingPresets. The fields name, text, display_values may also be localized (e.g. de.name). When translations of equal words but different meanings may conflict, a translation context should be specified. Use name_context, text_context or values_context for this. The context should be a meaningful short description to help translators. In JOSM internally all name, text and display_values are translated when no specific translation has
[Talk-it] Routing errato e dubbi sul tag Stop
Sto diventando matto a cercare di capire il perché... Il Garmin 245W sbaglia il routing di un percorso piuttosto semplice, proponendomi un percorso alternativo non solo più lungo ma anche su strade meno veloci di quelle del vero tragitto. La cosa strana è che se testo il routing su http://www.openrouteservice.org/# viene calcolato in modo perfetto, quindi mi viene da pensare ad un errata interpretazione dei dati da parte del Garmin. Oltretutto il navigatore si fa beffe di alcune impostazioni, tipo evita inversioni ad U, e cerca sempre di riportarmi sul tragitto che lui individua... La località di partenza è San Claudio, Via Filippo II, quella di arrivo Macerata, Via Ariani. Il tracciato corretto è Via Filippo II, SP485 (Strada Cluentina), SP63 (Via Bramante), Via Pancalducci, Corso Cairoli, Via Carducci, Via Cucchiari, Via De Amicis, Via Merelli, Via Ariani. Il tragitto proposto invece opta per allungare sulla SP485 e deviare per strade di campagna, fino a raggiungere la destinazione. Altro dubbio: il tag riguardante il segnale STOP: la documentazione italiana è alquanto scarna di informazioni (quella inglese contiene qualcosa in più) e non molto chiara. Esempio, classico incrocio con 4 strade provenienti dai 4 punti cardinali: la strada Nord-Sud ha diritto di precendenza su quella Est-Ovest, per cui il l'ultimo nodo della strada Est (prima di immettersi nell'incrocio) ha il segnale di stop. Ma un veicolo proveniente dalle altre direzioni, che giri sulla strada Est, si trova questo segnale di Stop subito, cosa piuttosto illogica. La strada Est (come le altre 4) è una normale strada urbana, a doppio senso di marcia, senza separazioni fisiche tra le due corsie. Come si tagga questo tipo di situazione piuttosto frequente? -- View this message in context: http://gis.638310.n2.nabble.com/Routing-errato-e-dubbi-sul-tag-Stop-tp6384323p6384323.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] Como usar la api de openstreetmap en un sitio web
Muchas gracias por la info a todos, lo de +PostGIS MapServer PHPMapScript+ se me hace muy complicado, ademas lo que quiero hacer deforma muy simple es colocar un mapa y GEO con mi celular, mapstraction es una buena opción pero no se conque licencia esta ? por el momento me inclino por OpenLayers. Aunque uno dice algo y resulta haciendo otra, me encanta este tema y voy con toda a estudiar la mejor opción, viendo el tema del servidor y probando diferentes velocidades en los navegadores, muchas gracias. On Miércoles 18 Mayo 2011 23:35:23 usted escribió: Hola, Una alternativa a más alto nivel es usar Mapstraction, que permite usar cualquier tipo de mapa de la misma manera (OSM-OpenLayers, Google, Yahoo, Bing) sin estar atado a una implementación de un API. http://www.mapstraction.com/ Esa es la teoría, pero no soy desarrollador GIS para explicar los detalles de como hacer el cambio de un sistema a otro. Andrés Gómez Casanova AngocA 2011 IBM Certified Advanced Database Administrator - DB2 9 DBA for Linux, UNIX and Windows IBM Certified Database Administrator - DB2 9 DBA for Linux, UNIX and Windows IBM Certified Database Administrator - DB2 UDB V8.1 for Linux, UNIX and Windows ITIL V3 Foundation Certificate in IT Service Management IBM Certified Associate Developer - WebSphere Studio V5.0 ang...@yahoo.com WebRep Overall rating ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ If you reply to this email, your message will be added to the discussion below: http://gis.638310.n2.nabble.com/Como-usar-la-api-de-openstreetmap-en-un-si tio-web-tp6379261p6380617.html To start a new topic under Colombia, email ml-node+5860023-1191161677-331...@n2.nabble.com To unsubscribe from Colombia, visit http://gis.638310.n2.nabble.com/template/NamlServlet.jtp?macro=unsubscribe _by_codenode=5860023code=ZGllZ28udXJpYmUuZ2FtZXpAZ21haWwuY29tfDU4NjAwMjN8 LTk3NTgyMjUyMA== -- Diego Alonso Uribe Gamez Twitter: @DiegoUG Facebook: diego.uiribe.gamez Esta comunicación es confidencial, destinado únicamente para el llamado destinatario (s) anterior y puede contener secretos comerciales u otra información que está exenta de divulgación según la legislación aplicable. Cualquier uso, difusión, distribución o copia de esta comunicación por cualquier persona que no sea el destinatario con nombre (s) está estrictamente prohibido. -- View this message in context: http://gis.638310.n2.nabble.com/Como-usar-la-api-de-openstreetmap-en-un-sitio-web-tp6379261p6382106.html Sent from the Colombia mailing list archive at Nabble.com.___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-es] personalizar mapas en Wiking
El día 18 de mayo de 2011 00:31, bicifamiliar i...@bicifamiliar.org escribió: Hola, estoy empezando con Wiking. En la capa de mapas estoy trabajando con OpenStreetMap (Mapnik), y en Maps Directory: /home/paco/.viking-maps/ Quisiera saber si se puede personalizar el directorio de mapas, en concreto me interesa: http://oobrien.com/oom/global.php Por dos cosas, porque me oculta el texto descriptivo, como por el juego de colores de los mapas de orientación. Igual no se puede usar esta cartografía pero sí conseguir mi objetivo. Creo que lo que intentas hacer es usar Viking con ese rendering que indicas con tu enlace ¿Correcto? El rendering que muestras parece haberse hecho de manera estándar, por lo que debería porder configurarse (lo siento, no tengo el programa delante, no te puedo dar los pasos). En cualquier caso, siempre tienes Cloudmade [1], donde la personalización del rendering es uno de sus fuertes. http://maps.cloudmade.com/?lat=40.162083lng=-3.361816zoom=7styleId=3007opened_tab=0 -- Jaime ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] Charla en Zaragoza
Hola, me han enmarronado para dar una charla sobre OSM el próximo viernes 27 en Zaragoza, dentro de unas jornadas de software libre de la Universidad: http://pulsar.unizar.es/2011/05/19/jornadas-de-primavera-2011/ Por supuesto, si hay algún OSMero más que esté interesado, se puede hacer algo aparte de la charla, de manera paralela (ej.: taller/mapping party/beers). Saludos, -- Jaime ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] Tunel y funcioamiento
Hola todos : Ayer Brieron un tunel en mi ciudad Con el cual La misma categoria que tenia por arriba lo pasa para el tunel . aqui no veo ploblea el problema me surge cuando el trazado que figura por arriba es igual en algunos puntos . La colocacion actual el tunes es un carril de abos entidos ( pero en realidad son dos carriles a cada sentido ,) Para poner el trazado en el medio del de arriba. se que nos es correcto pero no tendria mucho sentido poner dos carriles que luego los Gps no funcionarian . -- *** ~ Un saludo cordial de Manuel ~ *** Mi sitio si te interesa mas información visita El blog relacionado con linux # http://www.picholeiro.info . Mi servidor # http://servidor.picholeiro.info . :-) attachment: face-smile.png___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Tunel y funcioamiento
No me entero muy bien a que te refieres. Si añades un enlace a la zona para ver lo que has hecho a lo mejor se entiende mejor. El 19 de mayo de 2011 22:43, Manuel manuelmi...@gmail.com escribió: Hola todos : Ayer Brieron un tunel en mi ciudad Con el cual La misma categoria que tenia por arriba lo pasa para el tunel . aqui no veo ploblea el problema me surge cuando el trazado que figura por arriba es igual en algunos puntos . La colocacion actual el tunes es un carril de abos entidos ( pero en realidad son dos carriles a cada sentido ,) Para poner el trazado en el medio del de arriba. se que nos es correcto pero no tendria mucho sentido poner dos carriles que luego los Gps no funcionarian . -- * ***~ Un saludo cordial de Manuel ~* * *Mi sitio si te interesa mas información visita* El blog relacionado con linux # http://www.picholeiro.info . Mi servidor # http://servidor.picholeiro.info . [image: :-)] ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ face-smile.png___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Tunel y funcioamiento
Aun no esta renderizada pero aqui va http://www.openstreetmap.org/?lat=42.870837lon=-8.546114zoom=18layers=M El vie, 20-05-2011 a las 01:43 +0200, Jorge Sanz Sanfructuoso escribió: No me entero muy bien a que te refieres. Si añades un enlace a la zona para ver lo que has hecho a lo mejor se entiende mejor. El 19 de mayo de 2011 22:43, Manuel manuelmi...@gmail.com escribió: Hola todos : Ayer Brieron un tunel en mi ciudad Con el cual La misma categoria que tenia por arriba lo pasa para el tunel . aqui no veo ploblea el problema me surge cuando el trazado que figura por arriba es igual en algunos puntos . La colocacion actual el tunes es un carril de abos entidos ( pero en realidad son dos carriles a cada sentido ,) Para poner el trazado en el medio del de arriba. se que nos es correcto pero no tendria mucho sentido poner dos carriles que luego los Gps no funcionarian . -- *** ~ Un saludo cordial de Manuel ~ *** Mi sitio si te interesa mas información visita El blog relacionado con linux # http://www.picholeiro.info . Mi servidor # http://servidor.picholeiro.info . :-) ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- *** ~ Un saludo cordial de Manuel ~ *** Mi sitio si te interesa mas información visita El blog relacionado con linux # http://www.picholeiro.info . Mi servidor # http://servidor.picholeiro.info . :-) attachment: face-smile.pngface-smile.png___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-ar] video sobre el uso del validador de josm
On Mié 18 May 2011 12:57:11 Fabian Alejandro escribió: Hoy descubrí que hay una aplicación libre recordmydesktop en ubuntu que graba el escritorio, como otros soft comerciales en windows, anda muy bien e hice una prueba de grabar en ejemplo del uso del validador en josm. se ve que cargo las imagenes bind en un layer, oscuersco un poco el layer para poder ver los nodos, tambien aclaro los tracks gps para que no molesten. Uso los shortcuts del teclados para selecionar/crear/unir nodos (esc, s,n,m). http://www.youtube.com/watch?v=_IY6yae9gU8 Espero que les sirva. saludos. tambien tenes xvidcap saludos! -- Dock Sud BBS http://bbs.docksud.com.ar telnet://bbs.docksud.com.ar signature.asc Description: This is a digitally signed message part. ___ Talk-ar mailing list Talk-ar@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ar
Re: [Talk-ee] Aadressite validaator
You will have to write parser unit for your source. Like for Latvia I made one which read format like area-area-.area-Street-building Sotmthing like this: ?xml version=1.0 encoding=UTF-8? adress area type=Country name=Latvija area type=City name=Rīga street name=Nīcgales iela a p=1 / ... /street street name=Daugavgrīvas iela a p=31 / /street /area /area . area type=Region name=Kocēnu nov. area type=Town name=Zilupe /area area type=Sub region name=Kocēnu pag. street name=Dārza iela a p=1 / /street /area area type=Sub region name=Vaidavas pag. ... /area /area /adress But still main point of discusion is, what will be plugins object model to store all received address data. Here I put discusion about this we did with Radomir. https://sourceforge.net/p/addressmanager/wiki/Home/ Anyway project is mainly in discusion phase now, so any input on design is welcomed. 2011. gada 19. maijs 09:53 Jaak Laineste j...@openstreetmap.ee rakstīja: Thank you Gints! JOSM plugin would be much better than separate scripts. Can you explain a bit how does it work and how can it be extended? For Estonia we have two original official data sources : - X-tee (Estonian official central API for state registers) XML requests via pretty heavy infrastructure. We don't use this, but this is the ultimate official info - monthly updated ADS (address registry) database extracts as bunch of .csv files in FTP site of Maaamet. We use this. I have two-step processing of the DB extracts: 1) Importing them to Postgres database (no transoformation, so it is easy to update). 2) PHP script to request data from postgres and output .OSM as point nodes: Both my scripts are in: https://code.google.com/p/maakaart-ee/source/browse/#svn%2Ftrunk%2Fserver%2Fadb%2Fads2osmhttps://code.google.com/p/maakaart-ee/source/browse/#svn/trunk/server/adb/ads2osm%253Fstate%253Dclosed So there are several options from to get data for the plugin: 1) maaamet .csv files . Original ones, but these are in password-protected FTP site, and are pretty big (some 700 MB uncompressed) and we use only some specific fields from it. 2) give direct SQL access to the postgres database API. 3) use generated .OSM files with nodes 4) create some new better light API between postgres and plugin (some pbf-based) How to you feed data for LT and CZ? Jaak On 19.05.2011, at 9:28, Gints Polis wrote: May be this is useful. We with czech address plugin developers started new project for JOSM address plugin. http://sourceforge.net/projects/addressmanager/ Idea is: * Plugin will be able to get address information from different sources depending on country settings. * It will use downladed information to check/correct/enter address tags for downloaded region * Each country can make they own implementations on numbering system and house nummber assignement using plugin code as core As I understund you think about somthing like this. If it is, I purpose work on this problem together. Gints 2011/5/18 Joosep-Georg Järvemaa joosep-georg.jarve...@eesti.ee Failis dva_37_651_6694.osm.gz on mingi andmeviga, proovisin mitu korda erinevate programmidega alla laadida. -- Joosep-Georg ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee -- Ginc ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee -- Ginc ___ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
Re: [Talk-at] Hilfe wegen OSM
Hallo, ohne mit dem Thema Erfahrung zu haben (das hat aber wohl schon jemand gelöst, google bietet sich an), einfach ein paar Ideen. Frage ist natürlich, wie groß die zu untersuchende Fläche ist, wieviele highways da sind, wie genau es sein soll, und wieviel Entwicklungszeit resp. Rechenkapazität/zeit zur Verfügung stehen. Von den Punktmengen (ev. auch nur Mittelpunkt, ev. gewichtet mit Straßenlänge) der (residential) highways ausgehen und per Cluster-Algorithmus (DBSCAN o.ä.) Gebiete höherer Dichte identifizieren, dann ev. Straßenlänge/Fläche der Hülle. Ausgehend von einem residential highway alle anderen erreichbaren residentials innerhalb einer gewissen (Straßen)Distanz rekursiv suchen (wäre natürlich einfacher, wenn ein Graph schon zur Verfügung stünde), dann Straßenlänge/Fläche der Hülle. Straßenlänge pro Fläche zu berechnen würde z.B. bedeuten, Straßenlänge pro Gridquadrat zu berechnen, und die vollsten Quadrate zu suchen (dabei könnte man aber Orte verlieren, die in mehrere Quadrate fallen). Das verursacht jedenfalls eine Menge Schnittoperationen (auch wenn die Schnittmenge leer ist). Zur Berechnung wäre eine Kopie der DB fein (hoffentlich nicht wirklich der ganzen Welt ;-), PostGIS hat eine Menge praktische Funktionen (konvexe Hülle, Schwerpunkt, Fläche, Längenberechnung, bounding box/index-unterstützte Geometrieoperatoren), darüber hinaus könnte man die Verarbeitung abschnittsweise auch außerhalb der Datenbank durchführen. Just my 2 cents… Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hilfe wegen OSM
On 18.05.11 16:50, Soldier Boy wrote: Es geht darum wie man aus OSM Daten eine Siedlung/Ort erkennen kann. Hier geht es um weltweite Daten. Also nicht schon die fertig eingetragenen Orte in Österreich etc. Siehe auch Pascals Gedanken zu seinen Unmapped Places in OSM EU http://neis-one.org/2011/03/unmapped-places-1103/ Servus, Andreas -- SotM-EU 15.-17. Juli 2011 in Wien: https://sotm-eu.org ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hilfe wegen OSM
Wie kann das eig funktionieren? Lg Von: wolfbert [geowol...@googlemail.com] Gesendet: Donnerstag, 19. Mai 2011 12:13 Bis: 'OpenStreetMap AT' Betreff: Re: [Talk-at] Hilfe wegen OSM Hallo, ohne mit dem Thema Erfahrung zu haben (das hat aber wohl schon jemand gelöst, google bietet sich an), einfach ein paar Ideen. Frage ist natürlich, wie groß die zu untersuchende Fläche ist, wieviele highways da sind, wie genau es sein soll, und wieviel Entwicklungszeit resp. Rechenkapazität/zeit zur Verfügung stehen. Von den Punktmengen (ev. auch nur Mittelpunkt, ev. gewichtet mit Straßenlänge) der (residential) highways ausgehen und per Cluster-Algorithmus (DBSCAN o.ä.) Gebiete höherer Dichte identifizieren, dann ev. Straßenlänge/Fläche der Hülle. Ausgehend von einem residential highway alle anderen erreichbaren residentials innerhalb einer gewissen (Straßen)Distanz rekursiv suchen (wäre natürlich einfacher, wenn ein Graph schon zur Verfügung stünde), dann Straßenlänge/Fläche der Hülle. Straßenlänge pro Fläche zu berechnen würde z.B. bedeuten, Straßenlänge pro Gridquadrat zu berechnen, und die vollsten Quadrate zu suchen (dabei könnte man aber Orte verlieren, die in mehrere Quadrate fallen). Das verursacht jedenfalls eine Menge Schnittoperationen (auch wenn die Schnittmenge leer ist). Zur Berechnung wäre eine Kopie der DB fein (hoffentlich nicht wirklich der ganzen Welt ;-), PostGIS hat eine Menge praktische Funktionen (konvexe Hülle, Schwerpunkt, Fläche, Längenberechnung, bounding box/index-unterstützte Geometrieoperatoren), darüber hinaus könnte man die Verarbeitung abschnittsweise auch außerhalb der Datenbank durchführen. Just my 2 cents… Wolfgang Fachhochschule Wiener Neustadt für Wirtschaft und Technik Ges.m.b.H. University of Applied Sciences Wiener Neustadt for Business and Engineering Ltd., Austria Johannes Gutenberg-Straße 3 2700 Wiener Neustadt Austria, Europe ATU: 37772406 Firmenbuchnummer: 77005v Firmenbuchgericht: Landesgericht Wiener Neustadt DVR: 0798771 Der Inhalt dieses E-Mails ist ausschliesslich fuer den bezeichneten Adressaten bestimmt. Jede Form der Kenntnisnahme, Veroeffentlichung, Vervielfaeltigung oder Weitergabe des Inhalts dieses E-Mails durch unberechtigte Dritte ist unzulaessig. Wir bitten Sie, sich mit dem Absender des E-Mails in Verbindung zu setzen, falls Sie nicht der Adressat dieses E-Mails sind und das Material von Ihrem Computer zu loeschen. This e-mail and any attachments are confidential and intended solely for the addressee. The perusal, publication, copying or dissemination of the contents of this e-mail by unauthorised third parties is prohibited. If you are not the intended recipient of this e-mail, please delete it and immediately notify the sender. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hilfe wegen OSM
Hallo Janine, was hast Du denn für Vorkenntnisse, wieviel von osm willst Du untersuchen, und was passiert mit dem Ergebnis? Wie kann das eig funktionieren? Kenntnisse in Programmentwurf und Programmierung (inkl. relationale Datenbank/GIS-Erweiterungen) solltest Du schon haben oder Dir erarbeiten. Was den Algorithmus angeht, ich schätze das ist die Aufgabe ;-) LG Wolfgang ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hilfe wegen OSM
Am 18. Mai 2011 16:50 schrieb Soldier Boy soldierboy2...@gmail.com: Hier mal eine genauere Beschreibung des Problems (Bin mit der Problemstellung schon vertraut ;) Es geht darum wie man aus OSM Daten eine Siedlung/Ort erkennen kann. Hier geht es um weltweite Daten. Also nicht schon die fertig eingetragenen Orte in Österreich etc. Ich würde die Problemstellung eventuell umgekehrt angehen. Über die European Environment Agency kann man mittlerweile die Corine Land Cover 2006 [0] Daten kostenlos los beziehen [1] und das selbe gilt für die Globcover Daten der ESA [2]. Daher würde ich zuerst einmal schauen, welche OSM Tags in einem Gebiet mit den schon vorhandenen Landklassifizierungen korrelieren und anhand dieser Korrelationen von den OSM Daten auf die Nutzungsart rückschließen. cu andreas [0] http://sia.eionet.europa.eu/CLC2006/ [1] http://discomap.eea.europa.eu/ArcGIS/rest/services/Land [2] http://ionia1.esrin.esa.int/ ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-ca] Off-topic: general Canvec issues
Bonjour Brent, I'm forwarding your email to the manager in charge of the Canvec product. There are many project teams working on rethinking Canadian mapping nowadays. May it is just the good timing to have your requests consider! Regards, Daniel From: Brent Fraser [mailto:bfra...@geoanalytic.com] Sent: May 18, 2011 11:27 To: Bégin, Daniel Cc: talk-ca@openstreetmap.org Subject: Off-topic: general Canvec issues Daniel, While this is not directly related to OpenStreetMap, I'm posting this here since the OSM community seems to be the most active set of public users of Canvec data. The goal of this post is to improve Canvec (and therefore hopefully improve OSM). As a method of testing the latest release of Mapserver (http://mapserver.org/), I attempted to use Canvec v7 to render a CanTopo http://geogratis.cgdi.gc.ca/geogratis/en/product/search.do?id=A6291EF5-F3FC-A29F-3162-DE4DB194FD38 style map. See my mapserver post http://lists.osgeo.org/pipermail/mapserver-users/2011-May/068731.html for more details on my efforts. While the issues I covered on the Mapserver email list are specific to Mapserver rendering shortcomings, there were a few other issues related to the Canvec data. One of the main issues I ran into was the Toponymy (TO) layer http://wiki.openstreetmap.org/wiki/CanVec:_Toponymy_%28TO%29 is represented by point geometry preventing me from rendering the mountain range text (for example) in a curved manner as done in CanTopo. Is there any possibility of having NRCan change the geometry to LINESTRING? Or perhaps having a _TO_1580009_1 (linestring) shapefile for those names representing linear features in addition to the existing _TO_1580009_0 (point) shapefile? Some of the other less serious issues (these can be handled by pre-processing the Canvec data): Contour layer (FO_1030009_1): no attribute for major/minor contours preventing bolding of major contours Stream Layer (HD_1470009_1): major streams broken at tributary intersections preventing single label for streams Thanks! -- Best Regards, Brent Fraser ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec natural=land tags and untagged ways
Bonjour Samuel, Adam, and all. The purpose of the island conversion from area into point was to maintain toponyms without having the problem caused by natural=island tag for areas Your question just make me realised I should have simply removed island areas when there were no toponyms attached to it! I should be able to correct it for the next release. Best regards, Daniel From: Samuel Longiaru [mailto:longi...@shaw.ca] Sent: May 18, 2011 11:53 To: Adam Dunn Cc: talk-ca Subject: Re: [Talk-ca] CanVec natural=land tags and untagged ways Adam is correct here in that the natural=land tags I was talking about are on single nodes on islands in lakes. All have had a way surrounding them tagged as inner. None of the nodes that I have come across and deleted have had a name tag attached and so didn't seem to be serving any purpose. The name thing is good to know though and so I will be sure to check to see if any other tag is attached to them before deleting. Sam Original Message- From: Adam Dunn dunna...@gmail.com mailto:adam%20dunn%20%3cdunna...@gmail.com%3e To: Bégin, Daniel daniel.be...@rncan-nrcan.gc.ca mailto:%3d%3fiso-8859-1%3fq%3fb%3de9gin%3d2c%3f%3d%20daniel%20%3cdaniel.be...@rncan-nrcan.gc.ca%3e Cc: Samuel Longiaru longi...@shaw.ca mailto:samuel%20longiaru%20%3clongi...@shaw.ca%3e , talk-ca talk-ca@openstreetmap.org mailto:talk-ca%20%3ctalk...@openstreetmap.org%3e Subject: Re: [Talk-ca] CanVec natural=land tags and untagged ways Date: Wed, 18 May 2011 08:38:48 -0700 The natural=island tag that Daniel is referring to used to be applied to the way of the island. This is the old way of doing things (pre-Canvec 7). I think the natural=land tag that Samuel is referring to is a single node at the centre of the island (Canvec 7). The natural=land node is there for the purpose of retaining toponymy (naming). Many islands don't have names and you can just delete the node, but some of these nodes will have the name of the island, so you should either keep the node or transfer the name of the island over to the island's outer way. For water body relations (not coastal), it is sufficient to have just a closed inner way polygon; you don't need a natural=land tag (or any other tags). I'm not that experienced with coastal tagging, but I think having a way going the correct direction around the island and tagged as natural=coastline is how to tag an island in the ocean/sea. One shouldn't need a natural=land in that case either (in fact, according to the wiki, having natural=land as the sole tag on a costal island is not the correct way of doing things [1]). The two cases where natural=land is required is when the island is only a node (too small to be a way polygon), or when you aren't using relations and need to have an island way polygon (but this is obsoleted by using relations). I thought the tagless ghost ways were a byproduct of how JOSM deletes relations, I didn't know it was part of the Canvec export's construction. They can be tossed. Adam ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-cz] Oznamka - OSRM
2011/5/18 jzvc j...@tpfree.net: Dne 17.5.2011 20:24, Petr Dlouhý napsal(a): Ahoj, objevila se nová služba - OSRM. Jde o novou routovací službu, která ale zatím bohužel umí jen navigaci pro auta. Pozoruhodné na této službě je ohromující rychlost, se kterou trasu najde - je možné tažením špendlíku po mapě měnit start/cíl a v reálném čase se mění trasa. To umožňuje lépe než předtím najít nesrovnalosti v OSM datech, které brání správnému routování. Funguje to sice pekne, ale naviguje to spatne ... :/ Napr me to vede misto po dvouproudy silnici cca km po soubezny dvojce (na dalsi najezd nez by byl optimalni). ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz Me to nefunguje vubec, testuju to na sve oblibene trase litovel-pariz:) Ovsem nenajde to ani brno-praha. Patrne je to zpusobeno neexistenci dat vychodne od Pardubic:). Ale je to opravdu pekelne rychle. -- Michal Grézl http://openstreetmap.cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Pro zaj?mavost: Mapa k Bedn?
On Tue, 17 May 2011 18:35:41 +, Pavel Machek wrote: Ahoj! Možná by někoho mohlo zaujmout, že na tradiční pražské šifrovací hře Bedna [1] byla letos účastníkům distribuována specializovaná mapa vytvořená na základě OpenStreetMap v měřítku 1 : 12 000 (vytištěná na formát cca 100×70 cm) s IMHO pěkným stylem (patrně Mapnik, ale Bednu jsem (do)sel (ho-wa-da) (:-), a jo, tohle me hodne potesilo. Protoze ta mapa je papirova, pouzitelna, a profesionalne udelana. Diky CC-BY-SA mam pravo ji nafotit a hodit na web, k cemuz se doufam co nejdriv dostanu. To sice jo, ale pokud je zdrojem pro nafocení mapa co prošla šifrovačkou (obzvláště když na ní skoro celou noc pršelo), tedy poněkud rozmoklá, zmuchlaná a potrhaná, tak to nebude kvalitou nic moc. Spíš by to chtělo přemluvit orgy aby tu mapu dali na web jako třeba PDF (nebo prostě v tom formátu ve kterém to posílali na tisk), případně prozradli co za software na to použili (takže by si pak lidi mohli to samé vygenerovat s novějšími daty, případně pro jinou oblast) Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Linky MHD
Sítě MHD jsou většinou dost stálé, probíhají většinou drobné úpravy jednou za rok - už jenom kvůli lidem, kteří jsou na to zvyklí. Tak rozsáhlé změny, jaké popisuje Honza jsou docela neobvyklé. V Praze se moc MHD nemění, když nepočítám teda dočasné překopávky sítě kvůli výstavbě tunelu Blanka (což celkem zamávalo s hodně linkama v okolí, ale pak se zase vrátily zpět), DPP vydá čas od času nějaký seznam s kterými linkami kam hýblo a obvykle tam jsou jen drobné změny pár autobusdových linek, tramvaje dost zřídka (obvykle jen když se zprovozní někde nový kus tratě) Takže může být užitečné to zmapovat, udržovat to pak aktuální není moc práce. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] silnice - bod rozdělení na 2 ways není křižovatka - jak značit?
Ahoj. Před nedávnem jsem zde diskutoval rozdělení silnice, která má uprostřed fyzickou bariéru, na 2 ways. http://www.openstreetmap.org/?lat=50.075389lon=14.416271zoom=18layers=M Tím ale vznikl v navigaci nový problém, kterého jsem si nevšiml: Navigace bere bod rozdělení jako standardní křižovatku, a klidně pošle auto po jednom pruhu tam, a po druhém zpátky. Konkrétně třeba OSRM mně klidně prožene otočkou přes tento bod: http://www.openstreetmap.org/browse/node/1251239850 Z toho vyplývají dvě otázky: - Existuje jednoduchý způsob, jak v datech naznačit že nejde o křižovatku, nebo je jedinou metodou dvojitý přikázaný směr jízdy rovně? - Existuje nějaký tag, případně nějaké značení, které zakáže otáčení v celém úseku, kde je jen jedna way? no_u_turn povoluje jen zákaz otáčení přes bod a přes úsečku (a ani ten většina navigací neumí). Zákaz otáčení v celém úseku silnice tam nevidím. Ale možná nějak implicitně plyne z nějakého značení. -- Stanislav Brabec http://www.penguin.cz/~utx ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] silnice - bod rozdělení na 2 ways není křižovatka - jak značit?
Před nedávnem jsem zde diskutoval rozdělení silnice, která má uprostřed fyzickou bariéru, na 2 ways. http://www.openstreetmap.org/?lat=50.075389lon=14.416271zoom=18layers=M *** ten graficky dojem z toho ulicniho grafu je pro mne velmi matouci. Na wiki jsme kdysi napsali, ze dvojite way se kresli tehdy, pokud jde o silnici se strednim delicim pasem. Resslova by mela IMHO byt jedna way v cele delce, protoze ulice je v cele delce priblizne stejne sirky a neni delena strednim delicim pasem. Routovaci problemy bych resil routovacimi pravidly, ne topologii grafu. PS: zadnou pozitivni odpoved na routovaci otazky nemam hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Linky MHD
Ahoj! Tak to pozor, jedinou pesi navigaci rozhodne nemas, navit naviguje pesi i kone ;-). A dokonce jsem se do ni pokusil dodelat i tu MHD, a kdyz to oddebuguju, treba to bude i fungovat :-). Je to commitnuty na branchi. (na timetab.sf.net je jakasi vyhledavacka v jizdnich radech). Tak to rád slyším, v době kdy jsem to zkoušel, to ještě ani pořádně neroutovalo po silnici. Asi bych ho měl zase zkusit :) Jak jsi dělal to MHD? Zadáváš tam linky a řády nebo prostě routuješ mezi zastávkami? Ne, stahuju kompletni jizdni rady, a pouzivam je. Casy odjezdu, vsechno. Bohuzel tim graf pro routovani docela hodne nakyne... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] silnice - bod rozdělení na 2 ways není křižovatka - jak značit?
hanoj píše v Čt 19. 05. 2011 v 13:55 +0200: Před nedávnem jsem zde diskutoval rozdělení silnice, která má uprostřed fyzickou bariéru, na 2 ways. http://www.openstreetmap.org/?lat=50.075389lon=14.416271zoom=18layers=M *** ten graficky dojem z toho ulicniho grafu je pro mne velmi matouci. Na wiki jsme kdysi napsali, ze dvojite way se kresli tehdy, pokud jde o silnici se strednim delicim pasem. Resslova by mela IMHO byt jedna way v cele delce, protoze ulice je v cele delce priblizne stejne sirky a neni delena strednim delicim pasem. Část Resslovy ulice je rozdělena souvislým betonovým dělícím pásem, asi půl metru vysokým. Část pouze vodorovnou dopravní značkou Šikmé rovnoběžné čáry (V13a). Část s betonovými zábranami jsem nakreslil jako dvě ways, část oddělenou značkou V13a jako jednu. -- Stanislav Brabec http://www.penguin.cz/~utx ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] silnice - bod rozdělení na 2 ways není křižovatka - jak značit?
Na wiki jsme kdysi napsali, ze dvojite way se kresli tehdy, pokud jde o silnici se strednim delicim pasem. Resslova by mela IMHO byt jedna way v cele delce, protoze ulice je v cele delce priblizne stejne sirky a neni delena strednim delicim pasem. Část Resslovy ulice je rozdělena souvislým betonovým dělícím pásem, asi půl metru vysokým. Část pouze vodorovnou dopravní značkou Šikmé rovnoběžné čáry (V13a). Část s betonovými zábranami jsem nakreslil jako dvě ways, část oddělenou značkou V13a jako jednu. *** Way se kresli v ose komunikace/ulicniho profilu tj.: a) -- b) = To cos nakreslil =---= neni osa komunikace, ale spise routovaci graf. Radeji tedy a) nebo b). PS: Strednim delici pas je napr na dalnici. Betonova svodidla nebo stredni delici ostruvek na Resslove neni stredni delici pas. ha hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[OSM-talk-fr] [HS][Humour] L'europe vu de la France
Bonjour, On est pas encore vendredi, je prends de l'avance :p Voici l'Europe vu de la France :) http://farm3.static.flickr.com/2196/2458274279_180ab2a1f5.jpg A ne pas prendre au premier degré... Bonne journée. Julien ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [HS][Humour] L'europe vu de la France
Le jeudi 19 mai 2011 à 09:31 +0200, Julien Noblet a écrit : Bonjour, On est pas encore vendredi, je prends de l'avance :p Voici l'Europe vu de la France :) http://farm3.static.flickr.com/2196/2458274279_180ab2a1f5.jpg A ne pas prendre au premier degré... Pour ce genre d'humour, tu peux aller sur 4chan.org/b/ ; ils font des threads comme ça de temps à autres (entre deux images de lolcat et de phallus coupé en deux) En plus le fond de carte n'est pas même OSM et nous ne sommes pas même vendredi ! Ne le prends pas mal, mon but n'est pas de t'accabler, mais je trouve ce mail trop déplacé par rapport au sujet de la liste et aux us auxquels je suis habitué. Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [HS][Humour] L'europe vu de la France
Le jeudi 19 mai 2011 09:31:22 Julien Noblet, vous avez écrit : Bonjour, On est pas encore vendredi, je prends de l'avance :p Voici l'Europe vu de la France :) […] A ne pas prendre au premier degré... Même au 42ème degré, je trouve ça vulgaire, inintéressant, aggressif, … stupide Bonne journée aux autres -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Besoins pour entreprises et collectivités
Salut, Le mardi 17 mai 2011 à 22:15 +0200, Sébastien Aubry a écrit : 1) Impression d'une carte en grand format (ex : 1 m x 1 m) d'une entreprise (ou d'une commune) et des lignes de transports en commun autour d'elle. On n'en serait pas loin avec des sites comme Openbusmap ou OsmTransport mais ils ne sont pas mis à jour fréquemment [Edit : Openbusmap vient d'être mis à jour !], pas assez fonctionnels ni lisibles et l'export vers une image n'est pas immédiat. Donc plus généralement : existe-t-il un moyen, online ou offline, de visualiser les réseaux de transports en commun renseignés dans OSM ? Ce serait plus motivant pour les mappeurs d'avoir une couche par défaut avec ces réseaux. Est-ce envisageable sur le site officiel openstreetmap.org ? Il me semble qu'une telle fonctionnalité serait aussi appréciée par les agences de transport qui doivent éditer un plan de telle ou telle ligne ou un plan global et par les collectivités locales (communes, départements, régions) qui souhaitent produire des cartes de leur réseau. Pour SIG la Lettre je viens de produire une carte papier A0 des équipements vélo de Lille centre avec l'aide d'ingénieurs SIG. Je l'ai laissée à Nicolas Moyroud, sauf si Gaël-Ratzilla l'a interceptée : vous aurez l'occasion de la voir sur des salons. Il est apparu qu'un rendu automatique est insuffisant car il aura des imperfections acceptables pour un écran (on peut zoomer/dézoomer, changer de rendu, afficher/cacher dynamiquement …) mais très gênantes au format papier. De plus, des couleurs pertinentes sur un écran ne sont pas nécessairement justes en papier. etc. etc. etc. Pour réaliser un plan papier, il y a une phase de travail manuel : déplacer les symboles superposés, vérifier la lisibilité des noms, l'ordre des perceptions sur la carte (une carte vélo où on aperçoit en premier les voies rapides, c'est *très* con) etc. C'est beaucoup de bon sens et d'expérience professionnelle (pour avoir les bons réflexes). Sans l'aide des ingés SIG, je n'y serais pas parvenu. Faire des cartes papiers est un vrai métier d'expert, mais ça peut s'apprendre tout seul (un peu comme tous les métiers dans le fond ;-)) Philippe ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Besoins pour entreprises et collectivités
Le 19/05/2011 09:57, Philippe Pary a écrit : Pour SIG la Lettre je viens de produire une carte papier A0 des équipements vélo de Lille centre avec l'aide d'ingénieurs SIG. Je l'ai laissée à Nicolas Moyroud, sauf si Gaël-Ratzilla l'a interceptée : vous aurez l'occasion de la voir sur des salons. Vous êtes parti de quoi ? un export osm de josm + osmarender pour l'avoir en svg ? -- Thomas Clavier http://www.tcweb.org Jabber/XMPP/MSN/Gtalk :t...@jabber.tcweb.org +33 (0)6 20 81 81 30 +33 (0)950 783 783 signature.asc Description: OpenPGP digital signature ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Mapnik - Problème de rendu sur les relations multypolygones ?
Le 18 mai 2011 09:32, Erik Amzallag amzallag.e...@gmail.com a écrit : Tu peux donner un lien vers la zone ? et/ou un lien vers la relation ou le way qui présente toujours le problème ? Alors une relation qui ne contenait pas le tag created_by et correctement rendue : http://www.openstreetmap.org/browse/relation/27265 Une relation corrigée (tag created_by supprimé) correctement rendue : http://www.openstreetmap.org/browse/relation/13556 Une relation contenant toujours le tag created_by, non rendue : http://www.openstreetmap.org/browse/relation/13613 Toujours sur la liste dev, voici peut-être un début d'explication: http://lists.openstreetmap.org/pipermail/dev/2011-May/022636.html Matthias ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [HS][Humour] L'europe vu de la France
Le 19/05/2011 09:49, Nicolas Dumoulin a écrit : Le jeudi 19 mai 2011 09:31:22 Julien Noblet, vous avez écrit : Bonjour, On est pas encore vendredi, je prends de l'avance :p Voici l'Europe vu de la France :) […] A ne pas prendre au premier degré... Même au 42ème degré, je trouve ça vulgaire, inintéressant, aggressif, … stupide Bonne journée aux autres Je viens un peu prendre la défense, je trouve ça pas mal mais c'est moins bien que l'équivalent national. La France vue par les Français. Que vous pouvez trouvé sur youtube http://www.youtube.com/watch?v=7h39a15WlYo. Mais il est vrai que c'est trop hors sujet. Nuts ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] comment éviter les participations malveillantes
Bonjour, En dehors des dessins d'enfants et des renommages farfelus de noms de rues, l'un des dangers qui pourraient guetter le projet OpenStreetMap est en rapport avec la concurrence. Rien n'empêche un utilisateur anonyme (en fait, sous couvert d'anonymat) d'ajouter *volontairement* des informations de type œuf de Pâques afin qu'a posteriori, l'éditeur de cartes qui avait caché cet œuf de Pâques se retourne contre OSM et l'attaque. En effet, j'imagine que la disposition d'information cartographique libre ne doit pas plaire à tout le monde... est-ce que je me trompe ? Quelle serait notre défense ? Teuxe - Mail Original - De: Vincent Pottier vpott...@gmail.com À: talk-fr@openstreetmap.org Envoyé: Mercredi 18 Mai 2011 15h29:52 GMT +01:00 Amsterdam / Berlin / Berne / Rome / Stockholm / Vienne Objet: Re: [OSM-talk-fr] comment éviter les participations malveillantes Le 18/05/2011 12:34, Gilles Bassière a écrit : Il y a quelque chose d'intéressant dans ces questions. Les collectivités s'attendent à être la cible de représailles (parfois bêtes et méchantes) de leur part de leur administrés. Cette crainte ne me semble pas injustifiée puisque les actions des collectivités font rarement l'unanimité mais s'imposent tout de même à tous les administrés. Il me semble naturel que cela génère des sentiments tel que la frustration ou la rancœur qui peuvent aboutir à diverses manifestations d'hostilité. OpenStreetMap (ou Wikipédia puisque l'exemple a été cité) ne connaît pas ce genre de réactions hostiles car les choix faits par le projet ne s'imposent qu'à ceux qui veulent bien y participer. Les conflits existent, naturellement, mais ils restent rares. Remarque qui donne à penser... comme disait un de mes profs... OSM, comme Wikipédia n'est pas à l'abri de malversations, ce qu'il faut, c'est mesurer le risque, c'est à dire le produit de la probabilité par le dommage causé. Je ne suis plus très au fait de ce qui se passe sur Wikipédia, mais les cas où la page d'une commune devient une tribune pour exprimer, de quelque façon que ce soit, la rancœur d'administrés doivent être rares, sinon nuls. Il en est de même pour OSM. Qu'il y ait des divergences d'opinion dans les articles on le sait, et cela vaut probablement dans les articles sur des grosses communes. La neutralité de point de vue s'impose alors comme règle, et peut-être comme plus petit commun dénominateur. Pour OSM, la règle équivalente serait le On The Ground. Ce que les communes ont en général à gagner, dans OSM comme dans Wikipédia, c'est que les informations les concernant soient nombreuses et à jour. La qualité et quantité de ces informations étant en général proportionnels à la population. Le souci est qu'en devenant partenaire d'une collectivité, OpenStreetMap pourrait devenir la cible indirecte des attaques destinées à la collectivité. Notre rapport au vandalisme change donc un peu car il est susceptible de provenir de gens plus motivés, voire organisés en groupe. Je ne suis pas sur que partenaire soit le mot exact, au sens ou OSM ne signe pas d'accord de partenariat particulier avec telle ou telle commune. Mais je n'en trouve pas de plus juste... OSM propose aux communes, de façon générale et peut-être de façon plus expresse à telle ou telle, d'être une ressource : du fond de slippy map au fond de base de donnée... Comme il est dit par ailleurs, je doute que les communes un peu importante utilisent OSM comme externalisation de leur SIG... Peut-être quelques cantons ou comcoms ruraux, un jour... Ensuite, c'est à la commune de mesurer son implication en retour. * fourniture de donnés (one shot) * contrôle qualité initial * contrôle qualité continu * synchronisation de données Certes, plus l'implication est grande, plus OSM s'y retrouve. Dans ce fil de discussion, il a déjà été conseillé de faire un rendu propre à la collectivité s'appuyant sur des données validées. Ça permet d'une part d'éviter que la collectivité ne deviennent la risée du Web en publiant elle-même les données vandalisées. D'autre part, cela rend moins efficace l'idée d'attaquer OSM pour toucher la collectivité. Mais ça n'est pas suffisant car les données doivent être régulièrement mises à jour et la validation de celles-ci doit donc être permanente. Ce processus de validation peut (et devrait) être pris en charge par la collectivité. Il me semble que tous les outils nécessaires sont disponibles : - OWL permet d'être notifié des modifications sur le territoire concerné - OSM History Viewer permet de voir le détail de chaque changeset En terme de ressources, cette vérification ne prend pas énormément de temps, je le fais de manière à peu près exhaustive et à peu près hebdomadaire pour les arrondissements du centre de Marseille et je n'y passe généralement pas plus d'une demi-heure. En revanche, cela suppose une montée en compétence autour d'OSM pour au moins un des agents de la collectivité. Mettre en place un
Re: [OSM-talk-fr] comment éviter les participations malveillantes
Rien n'empêche un utilisateur anonyme (en fait, sous couvert d'anonymat) d'ajouter *volontairement* des informations de type œuf de Pâques afin qu'a posteriori, l'éditeur de cartes qui avait caché cet œuf de Pâques se retourne contre OSM et l'attaque. En effet, j'imagine que la disposition d'information cartographique libre ne doit pas plaire à tout le monde... est-ce que je me trompe ? Quelle serait notre défense ? Supprimer tous les changements du contributeur en question. Si la même personne recommence avec d'autres comptes, on pourrait imaginer des outils de détection sur l'IP avec refus d'inscription de ceux qui passent par des proxy anonymiseurs. De mon point de vue, une concurrence déloyale pourrait plutôt introduire des infos dégradant l'exploitation des données. Par exemple, une société vendant du routage pourrait inverser quelques sens interdits. Mais un contributeur va bien finir par s'en apercevoir, voir qu'il y a un gars qui n'a fait que des modifs de sens interdit, connexions de rues. Et si ça se reproduit, mise en place d'outils de détection des inverseurs de sens interdit. Eric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
