Re: [Talk-hr] Talk-hr Digest, Broj 63, Izdanje 5
oko Sinja ima 4 značajna krajobraza Sutina, Grab, Ruda, Rumin. Napraviću to Joža Dana 19. 11. 2014. 13:00 osoba talk-hr-requ...@openstreetmap.org napisala je: Talk-hr posaljite mailing list poruke na talk-hr@openstreetmap.org Da biste se pretplatili ili odjavili preko Weba, posjetite https://lists.openstreetmap.org/listinfo/talk-hr ili, koristeci mail, posaljite poruku sa naslovom ili sadrzajem 'help' na talk-hr-requ...@openstreetmap.org Osobi koja odrzava listu mozete se obratiti na talk-hr-ow...@openstreetmap.org Kada odgovarate, uredite Vasu Subject: liniju tako da je malo detaljnja od Re: Sadrzaj Talk-hr digesta... Današnje Teme: 1. Zaštićena područja u Hrvatskoj (Janko Mihelić) -- Message: 1 Date: Tue, 18 Nov 2014 23:57:40 +0100 From: Janko Mihelić jan...@gmail.com To: talk-hr@openstreetmap.org Subject: [Talk-hr] Zaštićena područja u Hrvatskoj Message-ID: CAA= vps8x807x_hycnf9cr6mp6e3vo2yayzt3w2-gm8ejfdi...@mail.gmail.com Content-Type: text/plain; charset=UTF-8 Pozdrav, palo mi je na pamet da bi trebali odrediti tagove za pojedine vrste zaštićenih područja u Hrvatskoj. Našao sam stranicu na wikiju gdje su korisnici po državama odredili što je koji tag, i bazira se na tagu boundary=protected_area: http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area#Nature-protected-areas U našim zakonima sam našao slijedeća područja: strogi rezervat, nacionalni park, posebni rezervat, park prirode, regionalni park, spomenik prirode, značajni krajobraz, park-šuma, spomenik parkovne arhitekture http://narodne-novine.nn.hr/clanci/sluzbeni/288893.html Predlažem da im po tom rasporedu dajemo brojeve, strogi rezervat bi dobio protect_class=1, a spomenik parkovne arhitekture bi dobio protect_class=9. Ako se većina slaže, to ću upisati u tablicu za Hrvatsku. Ako se kasnije pokaže da bi taj raspored trebao biti drugačiji, nije problem promjeniti. Ti tagovi se ne renderiraju na glavnom OSM layeru. Gledao sam kako to rade oko nas, i Talijani dodaju tag leisure=nature_reserve kako bi se to renderiralo. Tag mi baš nema nekog smisla, ali ako je nekom važno da se renderira na glavnom layeru, ovo je vjerojatno najmanje loše rješenje. Janko Mihelić -- Subject: Podnožje Digesta ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr -- Kraj Talk-hr Digest, Broj 63, Izdanje 5 *** ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
Re: [Talk-hr] Zaštićena područja u Hrvatskoj
On Tue, Nov 18, 2014 at 11:57:40PM +0100, Janko Mihelić wrote: U našim zakonima sam našao slijedeća područja: strogi rezervat, nacionalni park, posebni rezervat, park prirode, regionalni park, spomenik prirode, značajni krajobraz, park-šuma, spomenik parkovne arhitekture http://narodne-novine.nn.hr/clanci/sluzbeni/288893.html Predlažem da im po tom rasporedu dajemo brojeve, strogi rezervat bi dobio protect_class=1, a spomenik parkovne arhitekture bi dobio protect_class=9. Ako se većina slaže, to ću upisati u tablicu za Hrvatsku. Ako se kasnije pokaže da bi taj raspored trebao biti drugačiji, nije problem promjeniti. da, zvuci skroz ok. Ti tagovi se ne renderiraju na glavnom OSM layeru. Gledao sam kako to rade oko nas, i Talijani dodaju tag leisure=nature_reserve kako bi se to renderiralo. Tag mi baš nema nekog smisla, ali ako je nekom važno da se renderira na glavnom layeru, ovo je vjerojatno najmanje loše rješenje. Mozda bolje bi zvucalo da je pod key:landuse umjesto key:leisure, ali tag je takav kakav je, nije niti los [1] (kao recimo shop=hairdresser, k'o da tamo kupujem frizerke :) tako da sam ja za staviti ga svakako. [1] http://wiki.openstreetmap.org/wiki/Key:leisure kaze The leisure tag is for places people go in their spare time i onda ima skroz smisla. -- Opinions above are GNU-copylefted. ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
[talk-ph] New “what’s that?” feature on http://OpenStreetMap.org
Just in case you missed the little ? mark icon in the main OSM website. https://twitter.com/richardf/status/530687174463979520 -- 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 https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] New “what’s that?” feature on http://OpenStreetMap.org
Great addition! I often have to go through loading the area data even if I'm only interested in just one feature. *Erwin Olario* - - - - - - - - - - - - - - - - - - - » email: erwin@ er...@ngnuity.net*n**gnu**IT**y**.**net* http://ngnuity.net/ | gov...@gmail.com » mobile: (PHL): +63 908 817 2013 » OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93 D56B On Wed, Nov 19, 2014 at 6:50 PM, maning sambale emmanuel.samb...@gmail.com wrote: Just in case you missed the little ? mark icon in the main OSM website. https://twitter.com/richardf/status/530687174463979520 -- 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 https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Mappers doing adding attribute
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 For single use buildings like that it is no problem to make them a polygon, it is better in fact because there is then more information in the database, like the size of the object, etc. I would say continue on as you were. - -AndrewBuck On 11/18/2014 08:05 PM, Feye Andal wrote: As for the buildings with many possible features, we did not polygonize them. We only polygonize (as of now) banks, markets (esp. supermarkets, groceries, and public market), schools, fuel and religious institutions/place of worship. We will wait for your replies before we proceed to editing again to avoid confusion. Thanks! Feye On Wed, Nov 19, 2014 at 9:42 AM, Pierre Béland pierz...@yahoo.fr wrote: Hi Eugene, I looked at the first contributor in the list. It seems that this contributor decided to change POI from node to polygon. For every changeset, I see one node erased. You would have to look more in detail. I dont know the context.. But for buildings with many possible features, it is better to show each of these as a node. Pierre -- *De :* Eugene Alvin Villar sea...@gmail.com *À :* OpenStreetMap Philippines talk-ph@openstreetmap.org *Envoyé le :* Mardi 18 novembre 2014 17h49 *Objet :* [talk-ph] Mappers doing adding attribute Hi, Does anybody have any idea what these mappers are doing doing changesets that only say adding attribute? http://www.openstreetmap.org/user/aileen_aviera/history http://www.openstreetmap.org/user/Khym/history http://www.openstreetmap.org/user/ivet/history Most of these changesets seem to be polygonizing point POIs. ~Eugene ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJUbJl4AAoJEK7RwIfxHSXby3sP/3h00TtptxQ8/0lNcd9F81uM 3dkG0foVZQDuxLwtuv3MxOeiT5HvBGARnc8wvxVIaAezZQtV1FBOlykNl0tf/EpK x4o0PP8AZjr8bL74uajg/Pv1t09mQx6FYy4gfba0bKI02VI+2g+bg+65u2QIt2Rd APDltX1H7PDmZdmATxLbKHXV/JCTs145tK7k5Y6DqUNxnA7rsFFYTK/l4dZSh+dB S/S05g9/2xEWPL7rWUT6S9pGatb9/mYzHhYim54Q8sW81xhYwn/SetI77V5Y7O1l +8gmSERC1FJFpvhbaAyftF10LnVSWS2hXB7HZ9W1fqiwYIL+jfLbfUHTpXezel5T xWu4GWW7gWVTPFfDZdbZg8ojHTHTmNFOaV2nwRxhMLQTeeLcDvxVnxWVi5N59sGB 0i0SVQ383ynId+GpytoxadFN+0SOnAplO9j1Rj9pfQD8FzAJr0SEt76AWeQ485q2 QWU/eW2vGOYoifiRg8YsxO4lvLwqn5wtwbkY4XfOAmIqtfS/+qekC4bFSHIiWuZ0 qRwiW+Z6yFLt6/Ds/dlAHtYnVz+1mT901kTLadRAkcm7T3YBcIkoZKxKqAH+zeHG iTWmVuuLp290gifiyYRg/jPwLFcH0SL7fZs5KJMhlgb0E5B45KNp4HhP1jo8ckIJ tZl3Mjn+nyz3/Yyz1NeB =bzYq -END PGP SIGNATURE- ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] Project NOAH v2 Beta
Project NOAH has recently made their v2 to public preview adding a couple of important functionalities to the site and improving its GUI. Aside from the OSM maps layer as selectable basemaps (transport, cyclemap, mapnik), WEBSAFE which is a reconfigured INASAFE for it to be available as a web app and compatible to Philippine scenarios, is a natural hazard impact scenario virtualization app. This application harnesses OSM data which allows it to calculate relief goods distribution in times of emergencies. For more info, you can check out the program at http://beta.noah.dost.gov.ph/p/about OSM-PH has been properly mentioned as its contributor to the project. Ervin M. *Schadow1 Expeditions* - A Filipino must not be a stranger to his own motherland. http://www.s1expeditions.com ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Mappers doing adding attribute
As far as the Garmin GPS map based on OSM to which I compile, either a polygon or a node would do as long as the original tags of the node are re-tagged on the new polygon. I've brought this issue up to Ivet and eventually to Feye a couple of weeks ago. I have noticed that the new nodes they create on top of the existing node is still there on most of what I checked from some of the areas I monitor. But I am aware they will fix this as soon as they are done. Ervin M. *Schadow1 Expeditions* - A Filipino must not be a stranger to his own motherland. http://www.s1expeditions.com On Wed, Nov 19, 2014 at 10:05 AM, Feye Andal andalf...@gmail.com wrote: As for the buildings with many possible features, we did not polygonize them. We only polygonize (as of now) banks, markets (esp. supermarkets, groceries, and public market), schools, fuel and religious institutions/place of worship. We will wait for your replies before we proceed to editing again to avoid confusion. Thanks! Feye On Wed, Nov 19, 2014 at 9:42 AM, Pierre Béland pierz...@yahoo.fr wrote: Hi Eugene, I looked at the first contributor in the list. It seems that this contributor decided to change POI from node to polygon. For every changeset, I see one node erased. You would have to look more in detail. I dont know the context.. But for buildings with many possible features, it is better to show each of these as a node. Pierre -- *De :* Eugene Alvin Villar sea...@gmail.com *À :* OpenStreetMap Philippines talk-ph@openstreetmap.org *Envoyé le :* Mardi 18 novembre 2014 17h49 *Objet :* [talk-ph] Mappers doing adding attribute Hi, Does anybody have any idea what these mappers are doing doing changesets that only say adding attribute? http://www.openstreetmap.org/user/aileen_aviera/history http://www.openstreetmap.org/user/Khym/history http://www.openstreetmap.org/user/ivet/history Most of these changesets seem to be polygonizing point POIs. ~Eugene ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] New “what’s that?” feature on http://OpenStreetMap.org
Im getting this error whenever I use the feature *Error contacting http://overpass-api.de/api/interpreter http://overpass-api.de/api/interpreter* Ervin M. *Schadow1 Expeditions* - A Filipino must not be a stranger to his own motherland. http://www.s1expeditions.com On Wed, Nov 19, 2014 at 7:09 PM, Erwin Olario gov...@gmail.com wrote: Great addition! I often have to go through loading the area data even if I'm only interested in just one feature. *Erwin Olario* - - - - - - - - - - - - - - - - - - - » email: erwin@ er...@ngnuity.net*n**gnu**IT**y**.**net* http://ngnuity.net/ | gov...@gmail.com » mobile: (PHL): +63 908 817 2013 » OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93 D56B On Wed, Nov 19, 2014 at 6:50 PM, maning sambale emmanuel.samb...@gmail.com wrote: Just in case you missed the little ? mark icon in the main OSM website. https://twitter.com/richardf/status/530687174463979520 -- 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 https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Mappers doing adding attribute
Hi Feye, This is OK. Was just curious about the similar activity and wanted to know what was happening. :-) Anyway, I do have a suggestion. Instead of deleting the original POI node, please suggest that they use the original node as one of the nodes of the new polygon. This is so that the original person that added the POI node is still credited somehow in the existing objects in the database. I have left that suggestion on a few of their changesets, but it seems they have not read it. :( http://www.openstreetmap.org/changeset/26859930 http://www.openstreetmap.org/changeset/26859253 http://www.openstreetmap.org/changeset/26858714 ~Eugene On Wed, Nov 19, 2014 at 8:55 AM, Feye Andal andalf...@gmail.com wrote: Hello Sir, We from Project NOAH are polygonizing point POIs so that we can use it for the WebSAFE feature of Project NOAH. WebSAFE (web version of InaSAFE) only uses polygons as its exposure data to be able to function correctly. Sir Maning instructed me to delete the points after we polygonize them. We apologize for not informing you right away. Thanks, Feye On Wed, Nov 19, 2014 at 6:49 AM, Eugene Alvin Villar sea...@gmail.com wrote: Hi, Does anybody have any idea what these mappers are doing doing changesets that only say adding attribute? http://www.openstreetmap.org/user/aileen_aviera/history http://www.openstreetmap.org/user/Khym/history http://www.openstreetmap.org/user/ivet/history Most of these changesets seem to be polygonizing point POIs. ~Eugene ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [talk-ph] Mappers doing adding attribute
Great suggestion from Eugene to merge nodes into polygons. FWIW, in the JOSM editor, the shortcut key to merge nodes is M. *Erwin Olario* - - - - - - - - - - - - - - - - - - - » email: erwin@ er...@ngnuity.net*n**gnu**IT**y**.**net* http://ngnuity.net/ | gov...@gmail.com » mobile: (PHL): +63 908 817 2013 » OpenPGP key: 3A93D56B | 5D42 7CCB 8827 9046 1ACB 0B94 63A4 81CE 3A93 D56B On Thu, Nov 20, 2014 at 3:36 AM, Eugene Alvin Villar sea...@gmail.com wrote: Hi Feye, This is OK. Was just curious about the similar activity and wanted to know what was happening. :-) Anyway, I do have a suggestion. Instead of deleting the original POI node, please suggest that they use the original node as one of the nodes of the new polygon. This is so that the original person that added the POI node is still credited somehow in the existing objects in the database. I have left that suggestion on a few of their changesets, but it seems they have not read it. :( http://www.openstreetmap.org/changeset/26859930 http://www.openstreetmap.org/changeset/26859253 http://www.openstreetmap.org/changeset/26858714 ~Eugene On Wed, Nov 19, 2014 at 8:55 AM, Feye Andal andalf...@gmail.com wrote: Hello Sir, We from Project NOAH are polygonizing point POIs so that we can use it for the WebSAFE feature of Project NOAH. WebSAFE (web version of InaSAFE) only uses polygons as its exposure data to be able to function correctly. Sir Maning instructed me to delete the points after we polygonize them. We apologize for not informing you right away. Thanks, Feye On Wed, Nov 19, 2014 at 6:49 AM, Eugene Alvin Villar sea...@gmail.com wrote: Hi, Does anybody have any idea what these mappers are doing doing changesets that only say adding attribute? http://www.openstreetmap.org/user/aileen_aviera/history http://www.openstreetmap.org/user/Khym/history http://www.openstreetmap.org/user/ivet/history Most of these changesets seem to be polygonizing point POIs. ~Eugene ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph ___ talk-ph mailing list talk-ph@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-legal-talk] License Working Group news
Hi thanks to all for responding and in particular to the offers of help from Luis, Thomas and Diane. I use Luis' email below to give more detail about our activities. See in-line. It is also now my strong personal opinion that we should now engage a paid part-time General Counsel but that needs discussion and OSMF consensus. We are currently completely volunteer, so it is a big step On 19/11/2014 00:57, Luis Villa wrote: On Tue, Nov 18, 2014 at 1:46 PM, Paul Norman penor...@mac.com mailto:penor...@mac.com wrote: On 11/18/2014 10:11 AM, Luis Villa wrote: On Mon, Nov 17, 2014 at 11:18 AM, Michael Collinson m...@ayeltd.biz mailto:m...@ayeltd.biz wrote: I would also like to highlight that we also now welcome associate members who can help us occassionally or want to work on a specific topic that fires you up. This involves no specific formalities nor duties. Hi, Mike, others- Is there a formal description somewhere of the roles/responsibilities of the WG? That would help me evaluate to what extent (if at all) I can participate in WG activities. The scope of the LWG is listed at http://wiki.osmfoundation.org/wiki/Licensing_Working_Group Also, here is our 2013+ Action Plan which was formally submitted to the board and so represents our formal scope document: https://docs.google.com/document/d/1D3KwSM_BO7KkcbVADQVVn7eFwkD-RNauMwidhhlVPsI/pub and for, completeness, draft 2014 Action Plan: https://docs.google.com/document/d/1qRH5-LtzXiLhFFoo4iDu8mKfIUv1dhLYTwRZxBgNhJ8/pub Thanks, Paul. I hope you and the rest of the group don't mind me asking some more questions. https://docs.google.com/document/d/1BWn372ow_1tnTdQja76mthS8V-ZQ5PCL_RWLR1CBzkw/pub has some of the work we'd like to take on in the near future. Interesting. How often does the group meet, in practice? Is there also a fair bit of email between meetings, or...? We've progressively wound down from 2 meetings a week(!) to one per month, which is about right. The current gap in frequency is, I hope, transient. We have a low volume of emails in between on strategic discussion and have also been experimenting with circular resolutions. We are also getting an increasing amounts of license enqurires along the lines of I intend to XYZ, is it OK to use your data. It mentions referrals to outside counsel - is that still WSGR or is it someone else? Yes, WSGR. We occassionally ask for, and get pro bono advice, on specific issues. I note quite a few non-licensing topics—DMCA, Facebook, etc. Are those common or is this unusually timed? Not very common. I wanted to keep our name as License Working Group to emphasize our strategic direction and nature. Our primary task is the promotion of open geospatial data through practical, coherent and clear licensing. But we are a catch-all for anything considered legal. I am also keen on the area of risk mitigation, so conducting a DMCA review in conjunction with our Data Working Group was an important but finite activity. One other thing we've been involved in is policy documents, for example outlining our general position to diplomats on issues such as geographic name clashes and disputed borders ... we create a final draft that goes to the board for endorsement. We haven't worked out a precise framework for the scope of individual associate members - it's not expected that all associate members would participate in all parts of the LWG's work. If associate members not having a vote would allow people to help who would otherwise be in a conflict of interest, that could be done too. How often are votes actually held? Or is it mostly consensus-based anyway? Except for our circular resolutions experiments where it is practical, I believe we have never actually had or needed a vote! My general policy has been that we are deliberately a group of people with disparate personal views, on for example what type of license we should have, and that if we do not have unamimous agreement, or at least assent, then we have not reached the right solution. Does the WG have formal legal obligations as a committee of the board (or otherwise) or is it informal/advisory? (To explain that another way: in some organizations, groups like the LWG are board committees, and so certain formal requirements apply to their members — duties of good faith, attendance, voting rules, etc. In some orgs, they are essentially purely advisory so have no formal legal obligations.) Informal/advisory. It would be good to go beyond our scope document above to formally define that ... something we could use help on! Thanks- Luis -- Luis Villa Deputy General Counsel Wikimedia Foundation 415.839.6885 ext. 6810 /This message may be confidential or legally privileged. If you have received it by accident, please delete it and let us know about the mistake. As an attorney for the Wikimedia
[OSM-talk] The JOSM plug-in you might not know you love yet - GeoChat
I am always late to the party, but I just discovered the GeoChat plugin. It's brilliant. If you use JOSM, you want the GeoChat plug in. Then you want to ask in the irc channel or on the Mumble server for someone to come and look at something you are mapping. Then just watch as people show up* to your spot to look. Move around and follow each other to other parts of the map if you wondered about something near by. Explore and adventure where you are mapping with friends or just other mappers. Want to show a friend or colleague around where you are mapping and what your mapping looks like or evaluate the imagery with someone? GeoChat is a perfect way to do that. Why not get an expert tour or advice with experienced mappers who know the area and land and can take you on a GeoChat tour of an area explaining the mapping in the area. This could also be done via presentations where a live GeoChat evaluation/training goes on. I look forward to seeing more of you on the ground with GeoChat. Cheers, Blake *IRC response times can be slow sometimes so hang out as long as you can, hopefully it happens pretty fast. You can ask if here is anyone around in irc that could take a look so you know someone is coming. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Monitoring route relations
Hi, Peter Barth schrieb: OSMarelmon might be the tool you're looking for. the server seems to be up again. You might want to give it a try if that fits your needs: http://osmarelmon.won2.de/ Peda ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Monitoring route relations
the server seems to be up again. You might want to give it a try if that fits your needs: http://osmarelmon.won2.de/ Looks good but very strange that it won't accept numbers for the name. ie 'NCN Route 4' was rejected! Dave F. Mapper, not committee member --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Maproulette challenge: missing ways for Luxembourg
Good evening, I’m delighted to announce a new Maproulette task that focuses on ways that are missing in Luxembourg: http://maproulette.org/#t=luxembourg_missing_ways http://maproulette.org/#t=luxembourg_missing_ways If you haven’t used Maproulette before: you will get a point where I think we’re missing a highway. Once you’re done drawing the way, you’ll get another one to draw. Behind the scenes, this is done by comparing the Inspire open data road vectors with OSM. I’m very grateful to the Inspire team at the Luxembourg Cadastre, and to OSM users SK53, mvexel and emacsen for their help. Happy mapping, Guillaume___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] OSM voor adressen in Thunderbird
Hoi allemaal, Voor de mensen die Thunderbird gebruiken, stem a.u.b. op https://bugzilla.mozilla.org/show_bug.cgi?id=531285 door in te loggen, op vote te klikken en een stem uit te brengen. Verder is zinvol commentaar welkom (gaarne geen teksten als +1) en deel deze bug met andere OSM-enthousiastelingen die ook Thunderbird gebruiken. Groeten, Pander -- Stichting OpenTaal http://opentaal.org http://twitter.com/opentaal ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-ie] (no subject)
Hi Can I request sheets 26/25 NW and SW? Thanks Brian ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [Talk-it] Mobile Apps
+1 -- View this message in context: http://gis.19327.n5.nabble.com/Mobile-Apps-tp5824537p5824799.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mobile Apps
Io sono utente Android. Solitamente uso OsmAnd per tracciare i percorsi ed OsmPad per rilevare i civici. Ciao, Max -- View this message in context: http://gis.19327.n5.nabble.com/Mobile-Apps-tp5824537p5824800.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mobile Apps
su iOS posso raccomandare Go Map!! Ha autocompletion e si riesce abbastanza bene ad editare nodi e ways ed anche i tags dei multipoligoni... ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mobile Apps
Il 16/11/2014 22:42, Germano Massullo ha scritto: A mio avviso, per Android: OsmTracker e OsmAnd +1 OsmTracker per il tracking. +1 OsmAnd per la navigazione Aggiungerei anche Keypad Mapper per i civici. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mobile Apps
Per iOS c'è anche Galileo ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mobile Apps
On 16/11/2014 22:02, Pratosmart wrote: Ciao a tutti allo stato attuale quali sono le migliori app mobile (android e iOS) per fare GPS tracking su OSM? Grazie! Sarò leggermente OT ma colgo l'occasione per dire che per Firefox OS non c'è ancora nulla. Peccato: se qualcuno ha conoscenze di Javascript, HTML5, cazzimazzi potrebbe creare un'app per il mitico FxOS :) Fino a poco tempo fa davano via gratuitamente gli smartphone per creare app. Peccato abbiano smesso :/ - MM -- Michael Moroni +393313151159 http://diasp.eu/u/airon90 Non stampare questa email se non necessario! Pensa all'ambiente! Ne presu ĉi tiun retpoŝton se nenecese! Pripensu al medio! ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] ZTL e zona pedonale
Ti ringrazio... -- View this message in context: http://gis.19327.n5.nabble.com/ZTL-e-zona-pedonale-tp5823655p5824848.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Diminuzione Tag totali wikipedia
2014-11-18 22:58 GMT+01:00 Simone F. grop...@gmail.com: Faccio delle ipotesi: potrebbero essere stati rimossi per errore o per delle correzioni (es. tag errati o articoli non più esistenti) oppure hanno rimosso da un oggetto i tag riferiti ad altre lingue, visto che ne basta una sola (non sto dicendo che sia una cosa da fare). potrebbe anche essere che i link non erano giusti (link generici, dove l'articolo si riferisce ad una cosa generica e non all'oggetto specifico), per esempio un link all'articolo di WP Strada per una qualsiasi strada in osm. Oppure che i link sono stato reclassificati perché descrivevano delle proprietà e non l'oggetto in se, per esempio il link era wikipedia=architetto dell'edificio ed è stato riclassificato in architect:wikipedia=... Comunque, 36 non sono pochi. Non sarebbe male sapere dove è successo. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Diminuzione Tag totali wikipedia
dieterdreist wrote Comunque, 36 non sono pochi. Non sarebbe male sapere dove è successo. Grazie ad entrambi per le spiegazioni. Anche secondo me e' strano, ma non so come verificare. Terro' comunque monitorata la tabella se si dovesse ripetere. Saluti. -- Marco_T -- View this message in context: http://gis.19327.n5.nabble.com/Diminuzione-Tag-totali-wikipedia-tp5824663p5824883.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Diminuzione Tag totali wikipedia
2014-11-19 18:31 GMT+01:00 Marco_T toto...@libero.it: Grazie ad entrambi per le spiegazioni. Anche secondo me e' strano, ma non so come verificare. Terro' comunque monitorata la tabella se si dovesse ripetere. pensavo ci potrebbe essere ancora una copia del file di ieri, scusate la mia ignoranza, non so bene chi fa questa analisi e se c'è un archivio. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Mobile Apps
On 19/11/2014 12:38, Elena ``of Valhalla'' wrote: On 2014-11-19 at 11:48:35 +0100, Michael Moroni wrote: Sarò leggermente OT ma colgo l'occasione per dire che per Firefox OS non c'è ancora nulla. Peccato: se qualcuno ha conoscenze di Javascript, HTML5, cazzimazzi potrebbe creare un'app per il mitico FxOS :) Fino a poco tempo fa davano via gratuitamente gli smartphone per creare app. Peccato abbiano smesso :/ e non è neanche necessario avere uno smartphone per iniziare: le app per FFOS girano anche su Firefox su PC e a quanto ne so su Firefox per Android. Non tutte le app: dipende da come il creatore la imposta nel Marketplace. Però c'è la possibilità di creare una webapp per Firefox OS che sia compatibile per Firefox desktop, Firefox per Android e Firefox per tablet. Attendo fiducioso che qualcuno metta mano a questo prodotto made in Mozilla :) - MM -- Michael Moroni +393313151159 http://diasp.eu/u/airon90 Non stampare questa email se non necessario! Pensa all'ambiente! Ne presu ĉi tiun retpoŝton se nenecese! Pripensu al medio! ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Diminuzione Tag totali wikipedia
Il giorno 19 novembre 2014 18:54, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: 2014-11-19 18:31 GMT+01:00 Marco_T toto...@libero.it: Grazie ad entrambi per le spiegazioni. Anche secondo me e' strano, ma non so come verificare. Terro' comunque monitorata la tabella se si dovesse ripetere. pensavo ci potrebbe essere ancora una copia del file di ieri Ho controllato il codice. Vengono salvate le liste di tag Wikipedia del giorno corrente e di quello precedente (a futura memoria: nel file /data/OSM/tags.csv). Quindi, Marco_T, se noti ancora il problema si può cercare di capirne il motivo. non so bene chi fa questa analisi e se c'è un archivio. Il server è gestito da Luca Delucchi. Per questioni riguardanti il programma potete chiedere a me o Cristian Consonni. Ciao, Simone F. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Richiesta di aiuto per una relazione
Ciao, in questo punto c'è un multipoligono con cui voglio mappare la foresta. http://www.openstreetmap.org/#map=17/45.64481/11.34744layers=C Tutto bene eccetto la parte di foresta che viene disegnata fra questi due nodi (è uno piccolo spicchio ma c'è): node 452166379 node 452166463 Qualcuno ha idea di quale sia il motivo di questo comportamento? Grazie mille. Ciao, Mirco -- View this message in context: http://gis.19327.n5.nabble.com/Richiesta-di-aiuto-per-una-relazione-tp5824899.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Richiesta di aiuto per una relazione
Il giorno mer, 19/11/2014 alle 13.24 -0700, mircozorzo ha scritto: Ciao, in questo punto c'è un multipoligono con cui voglio mappare la foresta. http://www.openstreetmap.org/#map=17/45.64481/11.34744layers=C Tutto bene eccetto la parte di foresta che viene disegnata fra questi due nodi (è uno piccolo spicchio ma c'è): node 452166379 node 452166463 Qualcuno ha idea di quale sia il motivo di questo comportamento? Grazie mille. Ciao, Mirco Queste way tagliano la parte inner a metà. Vanno tolte dalla relazione per chiudere l'area. 3830923 313601819 Secondo me qui dovresti tracciare alcuni confini della forest a parte invece di usare le tracce highway Ciao Lorenzo ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. En import vil selvfølgelig ikke overskrive bygninger som OSM frivillige i forvejen har indtegnet eller slette dette arbejde. Denne mail er kun sendt for at veje stemningen i OSM Danmark for om vi skal bruge tid på 3,8 millioner bygningsimport? Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Vedr. disse her imports så skal der være en vis enighed og flertal i et lands OSM community før tingene sættes gang Så giv lige tilkende din mening (Jeg siger selv Ja til bygningsimport) Med venlig hilsen Søren Johannessen NB - Såfremt vi gør dette så vil Danmark være land nummer 3 der har en ca. 100% dækningsgrad af bygningspolygoner - Frankrig og Holland har i et par år haft noget nær 100 % dækningsgrad og lavet af åbne geodata. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Det lyder som en god idé - hvilke indvendinger kan der være? Venlig hilsen Kristian Krægpøth Den 19. nov. 2014 kl. 17.30 skrev Soren Johannessen soren.johannes...@gmail.com: Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. En import vil selvfølgelig ikke overskrive bygninger som OSM frivillige i forvejen har indtegnet eller slette dette arbejde. Denne mail er kun sendt for at veje stemningen i OSM Danmark for om vi skal bruge tid på 3,8 millioner bygningsimport? Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Vedr. disse her imports så skal der være en vis enighed og flertal i et lands OSM community før tingene sættes gang Så giv lige tilkende din mening (Jeg siger selv Ja til bygningsimport) Med venlig hilsen Søren Johannessen NB - Såfremt vi gør dette så vil Danmark være land nummer 3 der har en ca. 100% dækningsgrad af bygningspolygoner - Frankrig og Holland har i et par år haft noget nær 100 % dækningsgrad og lavet af åbne geodata. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Klart en god ide, der skal bare gøres. @flemming - så er det vel temmeligt begrænset, hvor der er importeret bygning. Fx Kolding kommune. (Andre steder kender jeg ikke til) Ang. Kolding så er de nye data lidt bedre og der er del opdatering med tilbygninger og nedrivniger på eksisterende bygninger. Tænker at det skulle være en smal sag for nogler vores data folk at lurer. Fx. Skal tags på eksisterende bygninger flyttes over i de ny importerede. Jens ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Soren Johannessen skrev: Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Ja. Kristian Krægpøth skrev: Det lyder som en god idé - hvilke indvendinger kan der være? Mulige indvendinger: 1) Hvis datakvaliteten ikke er i orden, vil vi få mærkelige eller ikke-eksisterende bygninger med i kortet. Vi bør lave et par stikprøver af data før importen iværksættes, og måske endda lave noget kvalitetssikring bagefter. 2) Det er ikke sikkert, at de importerede data følger OSMs retningslinier eller vores normale måde at gøre ting på. Bliver en karré f.x. tegnet som enkelthuse eller som ét hus? Hvordan med multipolygoner? Min holdning er her, at det er bedre med et forkert hus end et manglende hus. Så må vi forbedre senere hen. Desuden er det vel begrænset, hvor forkert det kan være... 3) Hvordan med eksisterende bygninger og veje (highway=*)? Hvis der er overlap mellem eksisterende bygninger/veje og de nye bygninger, kan der være flere årsager: - Fejl i data - bygningen findes ikke eller er placeret forkert - Fejl i OSM. - Fejl begge steder. - Mindre afvigelser. Det er sandsynligt, at det importerede vil have bedre præcision end eksisterende OSM-data i mange tilfælde. Jeg mener, det vil være en fejl bare at ignorere overlap. Vi bør klassificere dem og behandle i hvert fald nogle af dem manuelt. Især bygning/highway-kollisionerne bør undersøges. 4) For stor opgave: En ordentlig kvalitetssikring som beskrevet ovenfor vil kræve en del arbejde. Det er ikke sikkert, at vi umidelbart kan bære hele opgaven. Her mener jeg, at vi sagtens kan lave den simple import (dvs. uden kollisioner) først, så længe vi gemmer oplysninger om, hvad der er gjort, så det er muligt/nemt senere hen at lave kvalitetskontrol. - Jørgen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Til orientering - Følgende kommuner er færdige og har fuld dækningsgrad pt. Kolding, Jammersbugt, Frederikssund, Faxe, Stevns, Dragør, Fanø, Morsø og Læsø Vedr teknisk setup og spørgsmål - Jeg vil godt vente med dette indtil vi har fundet ud af om vi skal gøre det eller ej - Hvis ja nedsættes et arbejdsudvalg og der bliver tid til afklaring og mere tekniske spørgsmål her osv. vh Søren Johannessen 2014-11-19 18:23 GMT+01:00 Jens Winbladh j...@somewhere.dk: Klart en god ide, der skal bare gøres. @flemming - så er det vel temmeligt begrænset, hvor der er importeret bygning. Fx Kolding kommune. (Andre steder kender jeg ikke til) Ang. Kolding så er de nye data lidt bedre og der er del opdatering med tilbygninger og nedrivniger på eksisterende bygninger. Tænker at det skulle være en smal sag for nogler vores data folk at lurer. Fx. Skal tags på eksisterende bygninger flyttes over i de ny importerede. Jens ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Ja Op 19-nov.-2014 18:38 schreef Soren Johannessen soren.johannes...@gmail.com: Til orientering - Følgende kommuner er færdige og har fuld dækningsgrad pt. Kolding, Jammersbugt, Frederikssund, Faxe, Stevns, Dragør, Fanø, Morsø og Læsø Vedr teknisk setup og spørgsmål - Jeg vil godt vente med dette indtil vi har fundet ud af om vi skal gøre det eller ej - Hvis ja nedsættes et arbejdsudvalg og der bliver tid til afklaring og mere tekniske spørgsmål her osv. vh Søren Johannessen 2014-11-19 18:23 GMT+01:00 Jens Winbladh j...@somewhere.dk: Klart en god ide, der skal bare gøres. @flemming - så er det vel temmeligt begrænset, hvor der er importeret bygning. Fx Kolding kommune. (Andre steder kender jeg ikke til) Ang. Kolding så er de nye data lidt bedre og der er del opdatering med tilbygninger og nedrivniger på eksisterende bygninger. Tænker at det skulle være en smal sag for nogler vores data folk at lurer. Fx. Skal tags på eksisterende bygninger flyttes over i de ny importerede. Jens ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
God ide Nogle byggerne skal nok forenkles bagefter, så fx 5 punkter med 0 grader imellem dem bliver til 2 punkter Vi skal ikke fylde OSM databasen med ligegyldige punkter. Mvh Bilbo Denmark Den 19/11/2014 18.36 skrev Jørgen Elgaard Larsen j...@elgaard.net: Soren Johannessen skrev: Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Ja. Kristian Krægpøth skrev: Det lyder som en god idé - hvilke indvendinger kan der være? Mulige indvendinger: 1) Hvis datakvaliteten ikke er i orden, vil vi få mærkelige eller ikke-eksisterende bygninger med i kortet. Vi bør lave et par stikprøver af data før importen iværksættes, og måske endda lave noget kvalitetssikring bagefter. 2) Det er ikke sikkert, at de importerede data følger OSMs retningslinier eller vores normale måde at gøre ting på. Bliver en karré f.x. tegnet som enkelthuse eller som ét hus? Hvordan med multipolygoner? Min holdning er her, at det er bedre med et forkert hus end et manglende hus. Så må vi forbedre senere hen. Desuden er det vel begrænset, hvor forkert det kan være... 3) Hvordan med eksisterende bygninger og veje (highway=*)? Hvis der er overlap mellem eksisterende bygninger/veje og de nye bygninger, kan der være flere årsager: - Fejl i data - bygningen findes ikke eller er placeret forkert - Fejl i OSM. - Fejl begge steder. - Mindre afvigelser. Det er sandsynligt, at det importerede vil have bedre præcision end eksisterende OSM-data i mange tilfælde. Jeg mener, det vil være en fejl bare at ignorere overlap. Vi bør klassificere dem og behandle i hvert fald nogle af dem manuelt. Især bygning/highway-kollisionerne bør undersøges. 4) For stor opgave: En ordentlig kvalitetssikring som beskrevet ovenfor vil kræve en del arbejde. Det er ikke sikkert, at vi umidelbart kan bære hele opgaven. Her mener jeg, at vi sagtens kan lave den simple import (dvs. uden kollisioner) først, så længe vi gemmer oplysninger om, hvad der er gjort, så det er muligt/nemt senere hen at lave kvalitetskontrol. - Jørgen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Ja 2014-11-19 17:30 GMT+01:00 Soren Johannessen soren.johannes...@gmail.com: Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. En import vil selvfølgelig ikke overskrive bygninger som OSM frivillige i forvejen har indtegnet eller slette dette arbejde. Denne mail er kun sendt for at veje stemningen i OSM Danmark for om vi skal bruge tid på 3,8 millioner bygningsimport? Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Vedr. disse her imports så skal der være en vis enighed og flertal i et lands OSM community før tingene sættes gang Så giv lige tilkende din mening (Jeg siger selv Ja til bygningsimport) Med venlig hilsen Søren Johannessen NB - Såfremt vi gør dette så vil Danmark være land nummer 3 der har en ca. 100% dækningsgrad af bygningspolygoner - Frankrig og Holland har i et par år haft noget nær 100 % dækningsgrad og lavet af åbne geodata. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Jeg siger også ja. Vh. Erik Klausen Den 19-11-2014 17:30, Soren Johannessen skrev: Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. En import vil selvfølgelig ikke overskrive bygninger som OSM frivillige i forvejen har indtegnet eller slette dette arbejde. Denne mail er kun sendt for at veje stemningen i OSM Danmark for om vi skal bruge tid på 3,8 millioner bygningsimport? Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Vedr. disse her imports så skal der være en vis enighed og flertal i et lands OSM community før tingene sættes gang Så giv lige tilkende din mening (Jeg siger selv Ja til bygningsimport) Med venlig hilsen Søren Johannessen NB - Såfremt vi gør dette så vil Danmark være land nummer 3 der har en ca. 100% dækningsgrad af bygningspolygoner - Frankrig og Holland har i et par år haft noget nær 100 % dækningsgrad og lavet af åbne geodata. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Grønt lys herfra. /Lars 2014-11-19 17:30 GMT+01:00 Soren Johannessen soren.johannes...@gmail.com: Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. En import vil selvfølgelig ikke overskrive bygninger som OSM frivillige i forvejen har indtegnet eller slette dette arbejde. Denne mail er kun sendt for at veje stemningen i OSM Danmark for om vi skal bruge tid på 3,8 millioner bygningsimport? Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Vedr. disse her imports så skal der være en vis enighed og flertal i et lands OSM community før tingene sættes gang Så giv lige tilkende din mening (Jeg siger selv Ja til bygningsimport) Med venlig hilsen Søren Johannessen NB - Såfremt vi gør dette så vil Danmark være land nummer 3 der har en ca. 100% dækningsgrad af bygningspolygoner - Frankrig og Holland har i et par år haft noget nær 100 % dækningsgrad og lavet af åbne geodata. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Ja herfra. Vh Jakob Riis Josephsen Den 19/11/2014 17.30 skrev Soren Johannessen soren.johannes...@gmail.com : Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. En import vil selvfølgelig ikke overskrive bygninger som OSM frivillige i forvejen har indtegnet eller slette dette arbejde. Denne mail er kun sendt for at veje stemningen i OSM Danmark for om vi skal bruge tid på 3,8 millioner bygningsimport? Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Vedr. disse her imports så skal der være en vis enighed og flertal i et lands OSM community før tingene sættes gang Så giv lige tilkende din mening (Jeg siger selv Ja til bygningsimport) Med venlig hilsen Søren Johannessen NB - Såfremt vi gør dette så vil Danmark være land nummer 3 der har en ca. 100% dækningsgrad af bygningspolygoner - Frankrig og Holland har i et par år haft noget nær 100 % dækningsgrad og lavet af åbne geodata. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark ?
Ja til bygningsimport Venlig hilsen Henrik Puukka-Sørensen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
On 19-11-2014 17:30, Soren Johannessen wrote: Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. Så giv lige tilkende din mening Nej. Ikke før der er orden i licensforholdene. Konkret: Overholder den kildeangivelse som OSM kan love (reference til OpenStreetMap på selve kortet, samt en mention på osm.org/copyright) følgende klausul i licensbetingelserne: Når data anvendes skal brugeren: på et rimeligt sted egnet til distributionsmediet indsætte følgende: * ”Indeholder data fra Geodatastyrelsen” * Navnet på datasættet(ene) * Tidspunkt, hvor datasættet(ene) er hentet hos myndigheden, eller om der er tale om en datatjeneste. Er den mere eller mindre hemmelige side http://osm.org/copyright nok til at opfylde det krav? Der er fx ikke noget krav om at brugere af OSM data skal linke til den. Jeg ved det ikke og har ikke set nogle overbevisende argumenter for at det er, så derfor må det blive et nej herfra. -- Jonas Häggqvist rasher(at)rasher(dot)dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Det lyder som en god ide. Et par spørgsmål: Hvilken database er der tale om? Hvorledes forestiller du dig, at importen skal foregå. Bliver det en automatisk import, hvor oprydningen så skal foregå senere? Eller kunne det blive en eller anden form for kooperativ import, hvor frivillige brugere tager ansvar for importen i deres interesseområder? Jeg var selv involveret i adresse og bygningsimporten i Holland, der var baseret på det officielle hollandske adresse og bygningsregister (BAG). Den blev udført af en 30-40 frivillige, der hver især stod for importen i deres interesseområder. Importen var temmelig arbejdsintensiv, da eksisterende bygningsdata skulle erstattes eller flyttes over på de nye polygoner og BAG data var heller ikke perfekte trods deres officielle status (overlappende polygoner etc). De fleste af os brugte vel 2-3 måneder på at udføre vores del af importen. Vi havde udviklet en speciel JOSM plugin til formålet, som hjalp med at erstatte eksisterende data med de nye. Ole On 19/11/2014 17:30, Soren Johannessen wrote: Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. En import vil selvfølgelig ikke overskrive bygninger som OSM frivillige i forvejen har indtegnet eller slette dette arbejde. Denne mail er kun sendt for at veje stemningen i OSM Danmark for om vi skal bruge tid på 3,8 millioner bygningsimport? Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Vedr. disse her imports så skal der være en vis enighed og flertal i et lands OSM community før tingene sættes gang Så giv lige tilkende din mening (Jeg siger selv Ja til bygningsimport) Med venlig hilsen Søren Johannessen NB - Såfremt vi gør dette så vil Danmark være land nummer 3 der har en ca. 100% dækningsgrad af bygningspolygoner - Frankrig og Holland har i et par år haft noget nær 100 % dækningsgrad og lavet af åbne geodata. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Hej Ole Det er det geodatasæt der hedder FOT fra Geodatastyrelsen og de danske kommuner der indeholder disse bygningspolygoner. Nej intet junk-dumpes og så rydder vi op bagefter koncept her - Men lad os vente til alle disse mange relvante spørgsmål bliver besvaret i form af en arbejdsgruppe der sættes ned såfremt vi går videre i processen. vh Søren Johannessen 2014-11-19 21:15 GMT+01:00 Ole Nielsen on-...@xs4all.nl: Det lyder som en god ide. Et par spørgsmål: Hvilken database er der tale om? Hvorledes forestiller du dig, at importen skal foregå. Bliver det en automatisk import, hvor oprydningen så skal foregå senere? Eller kunne det blive en eller anden form for kooperativ import, hvor frivillige brugere tager ansvar for importen i deres interesseområder? Jeg var selv involveret i adresse og bygningsimporten i Holland, der var baseret på det officielle hollandske adresse og bygningsregister (BAG). Den blev udført af en 30-40 frivillige, der hver især stod for importen i deres interesseområder. Importen var temmelig arbejdsintensiv, da eksisterende bygningsdata skulle erstattes eller flyttes over på de nye polygoner og BAG data var heller ikke perfekte trods deres officielle status (overlappende polygoner etc). De fleste af os brugte vel 2-3 måneder på at udføre vores del af importen. Vi havde udviklet en speciel JOSM plugin til formålet, som hjalp med at erstatte eksisterende data med de nye. Ole On 19/11/2014 17:30, Soren Johannessen wrote: Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. En import vil selvfølgelig ikke overskrive bygninger som OSM frivillige i forvejen har indtegnet eller slette dette arbejde. Denne mail er kun sendt for at veje stemningen i OSM Danmark for om vi skal bruge tid på 3,8 millioner bygningsimport? Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Vedr. disse her imports så skal der være en vis enighed og flertal i et lands OSM community før tingene sættes gang Så giv lige tilkende din mening (Jeg siger selv Ja til bygningsimport) Med venlig hilsen Søren Johannessen NB - Såfremt vi gør dette så vil Danmark være land nummer 3 der har en ca. 100% dækningsgrad af bygningspolygoner - Frankrig og Holland har i et par år haft noget nær 100 % dækningsgrad og lavet af åbne geodata. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Jeg stemmer JA! /Leif Lodahl Den 19. nov. 2014 kl. 17.30 skrev Soren Johannessen soren.johannes...@gmail.com: Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. En import vil selvfølgelig ikke overskrive bygninger som OSM frivillige i forvejen har indtegnet eller slette dette arbejde. Denne mail er kun sendt for at veje stemningen i OSM Danmark for om vi skal bruge tid på 3,8 millioner bygningsimport? Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Vedr. disse her imports så skal der være en vis enighed og flertal i et lands OSM community før tingene sættes gang Så giv lige tilkende din mening (Jeg siger selv Ja til bygningsimport) Med venlig hilsen Søren Johannessen NB - Såfremt vi gør dette så vil Danmark være land nummer 3 der har en ca. 100% dækningsgrad af bygningspolygoner - Frankrig og Holland har i et par år haft noget nær 100 % dækningsgrad og lavet af åbne geodata. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Det må blive et JA On Wed, 2014-11-19 at 17:30 +0100, Soren Johannessen wrote: Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. En import vil selvfølgelig ikke overskrive bygninger som OSM frivillige i forvejen har indtegnet eller slette dette arbejde. Denne mail er kun sendt for at veje stemningen i OSM Danmark for om vi skal bruge tid på 3,8 millioner bygningsimport? Så derfor skal I kun svare i denne tråd Ja eller Nej om det er en god ide at gå videre i den process. Vedr. disse her imports så skal der være en vis enighed og flertal i et lands OSM community før tingene sættes gang Så giv lige tilkende din mening (Jeg siger selv Ja til bygningsimport) Med venlig hilsen Søren Johannessen NB - Såfremt vi gør dette så vil Danmark være land nummer 3 der har en ca. 100% dækningsgrad af bygningspolygoner - Frankrig og Holland har i et par år haft noget nær 100 % dækningsgrad og lavet af åbne geodata. ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM
Jeg stemmer klart Ja til at importere de bygninger der ikke konflikter med eksisterende bygninger. Mvh Klaus Hansen Sendt fra Samsung mobil___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Interesse for import af 3, 8 millioner bygninger i OSM Danmark?
Er den ikke afklaret endnu. Jeg ved at der er GST-folk, der abonnere på denne kanal, har I en mening om det Jonas skriver. Jens Den 19. nov. 2014 kl. 21.14 skrev Jonas Häggqvist ras...@rasher.dk: On 19-11-2014 17:30, Soren Johannessen wrote: Hej alle sammen Vi har for tiden ca. 775.000 bygninger i OSM Danmark. Vi har mulighed for at få 3,8 millioner ekstra bygninger i høj kvalitet fra det åbne geodataprogram og dermed værdiberige OSM Danmark endnu mere. Så giv lige tilkende din mening Nej. Ikke før der er orden i licensforholdene. Konkret: Overholder den kildeangivelse som OSM kan love (reference til OpenStreetMap på selve kortet, samt en mention på osm.org/copyright) følgende klausul i licensbetingelserne: Når data anvendes skal brugeren: på et rimeligt sted egnet til distributionsmediet indsætte følgende: * ”Indeholder data fra Geodatastyrelsen” * Navnet på datasættet(ene) * Tidspunkt, hvor datasættet(ene) er hentet hos myndigheden, eller om der er tale om en datatjeneste. Er den mere eller mindre hemmelige side http://osm.org/copyright nok til at opfylde det krav? Der er fx ikke noget krav om at brugere af OSM data skal linke til den. Jeg ved det ikke og har ikke set nogle overbevisende argumenter for at det er, så derfor må det blive et nej herfra. -- Jonas Häggqvist rasher(at)rasher(dot)dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
[Talk-dk] Afstemning og overvældende interessse for Danmark FOT bygningsimport
Hej alle sammen Tak for den overvældende tilkendegivelse i går om at det det vil være en god ide at få importeret ca. 3,8 millioner bygninger. Næste trin er at få nedsat en arbejdsgruppe som får løst og snakket om mange af de spørgsmål nogle af jer allerede i går bragte op i afstemningstråden Så angiv i denne tråd om du har løst til at deltage i sådan en arbejdsgruppe Vi skal blandt andet have lavet en engelsk wiki-side til FOT-Bygnings importsiden, som er vores How to import manual, som også er et krav fra OSM Data Working Group når store importdatasæt vil lægges ind i OSMs database. I kan se et eksempel med Import/Catalogue/NYC Buildings Addresses hvor det er New York bygninger og adresser der bliver beskrevet på wiki-siden http://wiki.openstreetmap.org/wiki/Import/Catalogue/NYC_Buildings_Addresses Venlig hilsen Søren Johannessen ___ Talk-dk mailing list Talk-dk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-dk
[Talk-gb-westmidlands] FW: [Talk-GB] Suburbs in London/Brum - big edits
https://www.openstreetmap.org/changeset/26567938#map=12/52.4747/-1.8777 https://www.openstreetmap.org/changeset/26567938#map=12/52.4747/-1.8777layers=N layers=N We should discuss if any of the place tags in and around Birmingham need updating or not. Cheers Andy From: Andy Robinson [mailto:ajrli...@gmail.com] Sent: 19 November 2014 10:46 To: 'Tom Chance'; 'talk-gb OSM List (E-mail)' Subject: RE: [Talk-GB] Suburbs in London/Brum - big edits Will revert the Birmingham changeset so we can discuss locally Cheers Andy From: Tom Chance [mailto:t...@acrewoods.net] Sent: 19 November 2014 10:07 To: talk-gb OSM List (E-mail) Subject: [Talk-GB] Suburbs in London/Brum - big edits Hello there, As somebody who dislikes change, I was slightly horrified to see these edits: https://www.openstreetmap.org/changeset/26783815 https://www.openstreetmap.org/changeset/26795471 https://www.openstreetmap.org/changeset/26567938 The user has changed a whole lot of places within London and Birmingham that were tagged as town / village / hamlet / etc. to place=suburb. He appears to be following the advice now given on the wiki, that: Areas of a town/city should not be tagged with place=town, place=village or place=hamlet. These should only be used for distinct settlements. http://wiki.openstreetmap.org/wiki/Tag:place%3Dsuburb Apart from the fact that I cannot stand it when the work of self-appointed wiki editors leads to somebody making sweeping edits of others' work, I also really don't like losing the hierarchy of place implicit in Wimbledon being marked as a town, Forest Hill a village, Belleden a hamlet, and so on, and them all just becoming 'suburb'. Apart from the fact that many places in London were historically towns in their own right, they are often also regarded as town centres. But should we swallow this and move to the use of place=suburb/quarter/neighbourhood? If so, I'd like to do this properly, instead of the process that this user has gone through to just make everything 'suburb'. Regards, Tom -- http://tom.acrewoods.net http://twitter.com/tom_chance ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
Re: [Talk-es] Resumen de Talk-es, Vol 94, Envío 6
Sobre el tema de los carriles de aceleración, yo creo que la wiki de OSM en inglés lo especifica claro y con ejemplos muy ilustrativos http://wiki.openstreetmap.org/wiki/Lanes http://wiki.openstreetmap.org/wiki/Key:turn Tal vez lo que se podría hacer es traducir al español estas páginas. A mí personalmente me parece lo correcto que los carriles de aceleración/deceleración formen parte de la vía principal, y que se marquen convenientemente con turn:lanes y destination. Lo malo, es que hay que dividir la vía en muchos trocitos para especificar las propiedades de los carriles en cada tramo, pero creo que es lo más correcto. Ejemplos de mapeos que he realizado de esta manera: http://www.openstreetmap.org/changeset/16443478 http://www.openstreetmap.org/changeset/16432845 En JOSM hay plugins que muestran visualmente la información de carriles, lo que ayuda mucho en la edición de estas propiedades. Espero haber aportado algo de luz a esta discusión :) Saludos, jpereza El 18 de noviembre de 2014, 23:20, Almorca almo...@gmail.com escribió: Sin que sirva de precedente creo que en este caso se debería tener en cuenta como muestran los GPS estos carriles. El 18 de noviembre de 2014, 16:42, Paúl Sanz paulsanzca...@gmail.com escribió: Continúo el debate sobre las carriles de aceleración y deceleración, porque no me convencen demasiado las razones a favor de considerar los carriles de aceleración/deceleración como vías separadas. Creo que hay que distinguir entre las etiquetas de descripción física y las que tienen significados legales. Por ejemplo, maxwidth se refiere a la prohibición legal, (un vehículo que rebase la maxwidth es posible que pueda pasar, pero está incumpliendo la prohibición) mientras que width se refiere a la anchura física. Los carriles, aunque legalmente pudieran no considerarse parte de la calzada (y no tengo claro que sea así), físicamente son un carril, ya desde el mismo nombre. Si el Reglamento de Circulación no los considerara carriles, no los llamaría así. Y separarlos de la highway=motorway es considerarlos una vía separada, no un carril separado. El art. 167 sí indica que las líneas discontinuas pueden indicar la existencia de un carril especial (para determinar la clase de vehículos, de entrada o salida, u otro) ; en este caso la marca es sensiblemente más ancha que en el caso general.. Pero un carril especial sigue siendo un carril, no una vía separada. El art. 77 que cita Robertogeb dice, de hecho: Para abandonar una autopista, autovía o cualquier otra vía, los conductores deberán circular con suficiente antelación por el carril más próximo a la salida y *penetrar lo antes posible en el carril de deceleración*, si existe.. Me parece que la clave es la palabra antelación. Los carriles de decelaración están *antes* de la salida, no después. Si los mapeamos como motorway_link, estarían después, no antes de la salida. Otro argumento es que hay carriles de deceleración muy largos. Alguno he visto que comienza justo en la señal de preseñalización de la salida que marca los 1000 o los 500 m. Esto quiere decir que se considera que la salida está al final del carril de deceleración. Si no fuera así, habría la preseñalización de los 1000 y los 500 m y solo después empezaría el carril. Y esto no es así nunca, que yo haya visto. Los propios carteles dicen que la salida está al final del carril, no al principio. En cuanto a los carriles compartidos, (de aceleración al principio y de deceleración al final), de las 3 opciones que ve Robertogeb yo optaría por la 2. La 1 convierte un carril en un cruce de dos vías añadiendo complejidad, y la 3 me parece arbitraria. La 2, en cambio, sí considera que el carril es un carril. Suena tonto, pero si lo separamos estamos diciendo que un carril no es un carril, sino otra cosa. En consonancia con estos artículos: - El carril de aceleración en OSM debería ser un carril independiente y prolongarse hasta el final, punto en el que se incorpora a la vía principal. - El carril de deceleración en OSM debería ser un carril independiente que se separa de la vía principal en el momento en el que existe el carril . Cuando un carril de aceleración se une a un carril de decelaración surge un problemaa, no sólo de representación en OSM sino de circulación al producirse peligrosas tijeras. Veo varias opciones: 1. Podrían pintarse dos carriles: uno de aceleración y otro de deceleración que se cruzarían en un punto intermedio 2. Podría ampliarse el número de carriles de la vía principal y utilizar turn:lanes, donde el valor del carril derecho sería turn_left en la primer mitad de la vía y turn_right en la segunda 3. Podría crearse un carril de deceleración desde un punto intermedio en la vía principal y un carril de aceleración hasta ese mismo punto Yo opto por la 3. En ocasiones, el carril de aceleración continua (o el de decelaración finaliza) como un
[Talk-at] Wanderwege Zimmermannplatzl
Hallo! Kann das bitte irgendwer Ortskundiger fixen: http://www.openstreetmap.org/way/313375113 A-B-C-B-C kann's irgendwie nicht sein... Mit dem kreuzenden Weg gibt's keinen gemeinsamen Punkt. Außerdem sind die Wanderrouten mit dem Edit von Haimböck kaputtet worden. :( /al ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wanderwege Zimmermannplatzl
On 19.11.2014 11:04, Andreas Labres wrote: Kann das bitte irgendwer Ortskundiger fixen: http://www.openstreetmap.org/way/313375113 A-B-C-B-C kann's irgendwie nicht sein... Mit dem kreuzenden Weg gibt's keinen gemeinsamen Punkt. Außerdem sind die Wanderrouten mit dem Edit von Haimböck kaputtet worden. :( Ich glaube, das gehört nicht in die Mailingliste, aber wenn es schon mal dasteht, werde ich die Sache erklären. Haimböck ist faktisch Markierungswart der Wanderwege im Bereich der Hohen Wand. Nachdem er OSM entdeckt hat, hat er auf http://hiking.waymarkedtrails.org/ einige Fehler erspäht bzw. einiges, was nicht mehr aktuell ist. Das hat er alles er im Webforum der Wanderreitkarte gemeldet. Weil ich auf der Hohen Wand ebenfalls über gute Ortskenntnis verfüge, habe ich mich dieser Angelegenheiten gleich angenommen und einiges in OSM korrigiert, in manchen Dingen war ich aber anderer Meinung. Dazu gehört diese Wegkreuzung. Ich bin der Meinung, dass durch die gatschige Wiese kein Weg erkennbar ist. Er ist der Meinung, dass keiner den Umweg über die Forststraße nimmt. Er weiß, wie die Markierungen gemeint sind (weil er sie selber gemalt hat), ich gehe lieber nach dem, was ich sehe. Darum hab ich die Kreuzung in OSM nicht so abgebildet, wie er wollte. Deshalb hat er - was eh gut ist - seine Anliegen als Map Notes gespeichert. Leider gibt es wenig Mapper, die Map Notes bearbeiten, und noch weniger davon sind bereit, dafür hunderte km mit dem Auto zu fahren. Ich tu aber beides, und somit war's erst wieder eine Sache zwischen ihm und mir... Ich hab mich dann auch nicht mehr so darum gekümmert, weil diese Angelegenheiten vergleichsweise unwichtig sind. Z.B. am Kuhschneeberg waren noch überhaupt keine Wanderwege gemappt, es fehlten sowohl die Ways als auch die Relationen. Und die Wege sind dort derart schlecht markiert, dass vor ein paar Jahren eine Gruppe von Schülern sich verstieg und einer der Schüler in den Tod stürzte. Auf der Hohen Wand wird derweil jeder Weg in allen Farben (rot, gelb, grün, blau) markiert, und jeder Weg ist Teil von zehn Themenwegen. Es stehen schon mehr Themenwegschilder als Bäume. Wovon woanders zu wenig ist, davon ist hier zu viel. Dieses Markierungschaos ergibt ein weißes Rauschen, man kann sich an den Markierungen nicht mehr orientieren. Wenn jeder Weg in allen Farben markiert ist, hat eine Markierung keinen Informationsgehalt mehr. Von daher bin ich froh, dass Haimböck nun selbst zum Editieren anfängt. Jetzt kann er sich seine Routen so herrichten, wie er möchte. Ob sie syntaktisch richtig sind, hat meiner Meinung nach keine Bedeutung, da sie soundso keinen praktischen Wert mehr haben (siehe vorigen Absatz). Wenn du dennoch ein Problem damit hast, solltest du zu ihm Kontakt aufnehmen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wanderwege Zimmermannplatzl
Hallo Friedrich! Danke für die Aufklärung! Ich hab nur ein Problem mit grundsätzlichen Fehlern wie einem Way, der über zwei Nodes zweimal führt, oder Wegekreuzungen ohne gemeinsamem Node oder Wanderrouten, die in Schleifen laufen oder Sprünge machen oder offen sind oder was immer. Mein Anliegen wäre eben, dass jemand diese OSM-technischen Fehler bitte fixt. Danke, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-it-trentino] Talk-it-trentino Digest, Vol 35, Issue 15
. -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org -- Message: 3 Date: Wed, 19 Nov 2014 08:07:50 +0100 From: Matteo Quatrida matteo.quatr...@linuxmail.org To: OpenStreetMap ML-TRENTINO talk-it-trentino@openstreetmap.org Subject: Re: [Talk-it-trentino] appuntamento mensile? Message-ID: trinity-969afa67-d7ab-4cc8-ad60-9b866d58c7c7-1416380870074@3capp-mailcom-lxa09 Content-Type: text/plain; charset=UTF-8 Sent: Tuesday, November 18, 2014 at 11:51 PM From: Luca Delucchi lucadel...@gmail.com Chiaramente, se per svariati motivi, ci fosse solo la tua disponibilità, forse sarebbe meglio tenerlo separato dall'appuntamento mensile (a cui si può partecipare con «più leggerezza»). beh ma io non pensavo ad un evento sostitutivo dell'appuntamento mensile Perfetto! Avevo capito diversamente, cioè che ci fosse la proposta di organizzare questi incontri mensili nelle Valli del Trentino. Già mi vedevo, una volta al mese, raggiungere località sperdute :) per trovarci in quattro gatti... Se invece è un'incontro ulteriore, non c'è problema alcuno. Anzi, possono essere messi a punto proprio durante gli incontri a Trento, migliorandoli di volta, in volta. Buona giornata a tutti. PS. Seconda o terza settimana del mese per me è indifferente. -- Matteo Quatrida GNU/Linux User #498939 OpenStreetMap Contributor since 2009 «Be GREEN and keep it on your SCREEN!» -- Message: 4 Date: Wed, 19 Nov 2014 08:24:29 +0100 From: Dario Zontini dario.zont...@gmail.com To: talk-it-trentino@openstreetmap.org Subject: Re: [Talk-it-trentino] appuntamento mensile? Message-ID: CAOt8SisDvnyLzA7Ybey-TG3=o0tg7fk2btnh2dhhgiqwqfu...@mail.gmail.com Content-Type: text/plain; charset=utf-8 Naturalmente la mia proposta di incontri di Valle non voleva sostituire gli incontri di Trento che sono un bellissima idea. È una possibilità in più per chi abita lontano da Trento. È possibile che non mi siano arrivate tutte le email? Ciao Dario Inviato da Samsung Mobile Il 19/nov/2014 08:08 Matteo Quatrida matteo.quatr...@linuxmail.org ha scritto: Sent: Tuesday, November 18, 2014 at 11:51 PM From: Luca Delucchi lucadel...@gmail.com Chiaramente, se per svariati motivi, ci fosse solo la tua disponibilità, forse sarebbe meglio tenerlo separato dall'appuntamento mensile (a cui si può partecipare con «più leggerezza»). beh ma io non pensavo ad un evento sostitutivo dell'appuntamento mensile Perfetto! Avevo capito diversamente, cioè che ci fosse la proposta di organizzare questi incontri mensili nelle Valli del Trentino. Già mi vedevo, una volta al mese, raggiungere località sperdute :) per trovarci in quattro gatti... Se invece è un'incontro ulteriore, non c'è problema alcuno. Anzi, possono essere messi a punto proprio durante gli incontri a Trento, migliorandoli di volta, in volta. Buona giornata a tutti. PS. Seconda o terza settimana del mese per me è indifferente. -- Matteo Quatrida GNU/Linux User #498939 OpenStreetMap Contributor since 2009 «Be GREEN and keep it on your SCREEN!» ___ Talk-it-trentino mailing list Talk-it-trentino@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it-trentino -- next part -- An HTML attachment was scrubbed... URL: http://lists.openstreetmap.org/pipermail/talk-it-trentino/attachments/20141119/f405ecbd/attachment-0001.html -- Subject: Digest Footer ___ Talk-it-trentino mailing list Talk-it-trentino@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it-trentino -- End of Talk-it-trentino Digest, Vol 35, Issue 15 ___ Talk-it-trentino mailing list Talk-it-trentino@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it-trentino
[Talk-cat] Recordatori: Llistat de coses a fer
Us recordo la pàgina de la wiki on podeu trobar temes pendents a tractar o fer. Si teniu alguna informació o actualització, afegiu-la. https://wiki.openstreetmap.org/wiki/WikiProject_Catalan/Llistat_de_coses_a_fer -- *Carlos Sánchez*About.me http://about.me/carlos.sanchez ___ Talk-cat mailing list Talk-cat@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cat
Re: [Talk-lv] shkjiibs terplaans ?
gan jau kaut kādas siltumnīcas kādreiz bija, vai arī izklātas agroplēves sliktā orto izskatās pēc mājām. mans domāt, ka jānes nost. 2014-11-17 12:08 GMT+02:00 Rich ric...@nakts.net: saliidzinaam shiis 4 eekas ar binga foto : http://www.openstreetmap.org/#map=18/57.09583/24.55755 taadas tur nav, un arii liidziigaa izmeeraa netaalu nekaa nav. tas ir vienkaarshi kljuudains terplaans vai ir kaadi citi mineejumi ? varbuut vienkaarshi jaanes nost ? (bish zemaak arii dazhas diivainas un neatbilst foto) -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] shkjiibs terplaans ?
+1 nesam nost. Varbūt kādreiz bija, bet tagad pēc.pļavas izskatās. Ja ari tur būs apbūve tā noteikti bus savādāka. On Wed, Nov 19, 2014, 22:07 Raitis Upmalis rait...@gmail.com wrote: gan jau kaut kādas siltumnīcas kādreiz bija, vai arī izklātas agroplēves sliktā orto izskatās pēc mājām. mans domāt, ka jānes nost. 2014-11-17 12:08 GMT+02:00 Rich ric...@nakts.net: saliidzinaam shiis 4 eekas ar binga foto : http://www.openstreetmap.org/#map=18/57.09583/24.55755 taadas tur nav, un arii liidziigaa izmeeraa netaalu nekaa nav. tas ir vienkaarshi kljuudains terplaans vai ir kaadi citi mineejumi ? varbuut vienkaarshi jaanes nost ? (bish zemaak arii dazhas diivainas un neatbilst foto) -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-lv
[Talk-ca] (no subject)
Plusieurs (et j'en suis) ont exprimé leur désir d'avoir une meilleure couverture de forêt sur la carte OSM. Ces zones de forêt sont venues avec les importations CanVec mais ne progressent plus depuis un certain temps. Le présent article propose une façon de réaliser la forêt sans utiliser les abus de la méthode CanVec. Voyons un exemple. Dirigez votre éditeur préféré vers -74.375/46.1875 ou visionnez: http://www.openstreetmap.org/#map=16/46.1875/-74.3750 Vous y verrez deux tuiles de forêt. Chacune a été crée avec un rectangle de type natural:wood. Un simple rectangle de 4 points qu'on peut créer facilement. Cette tuile peut être vue simplement avec: http://openstreetmap.org/way/307466266 Voyons un autre exemple un peu plus à l'ouest (-74.500/46.1875). Dans votre éditeur, sélectionner la ligne qui délimite la tuile sud-ouest. On peut constater qu'elle est beaucoup plus complexe. On peut voir l'ensemble de cette ligne avec: http://openstreetmap.org/way/307466267 Elle est composée d'environ 1600 points. Elle est complexe parce qu'elle utilise l'approche everything but the kitchen sink. La tuile définit non seulement la forêt mais aussi les lacs, les rivières et les clairières. Pire encore, ce chemin de 1600 points fait partie d'une relation qui contient plusieurs dizaines de tels chemins. Affichez http://www.openstreetmap.org/relation/2368823 et remarquez le temps de chargement de la page. Revenons au premier exemple: http://www.openstreetmap.org/#map=14/46.1875/-74.3750 La forêt est un simple rectangle mais les lacs, les rivières et les chemins se superposent à la forêt. Il n'est donc pas nécessaire que le contour de forêt suive le contour des lacs et des rivières. Il y a un gain énorme en simplicité. Voyons un autre problème des tuiles CanVec: http://www.openstreetmap.org/#map=17/46.25047/-73.24885 Pour comprendre pourquoi il y a 3 Lac Laporte il faut utiliser l'éditeur: http://www.openstreetmap.org/edit?editor=id#map=17/46.25047/-73.24885 Les tuiles CanVec ont divisé le lac en 3 parties et ont créé 3 entités natual:water, chacune avec le nom Lac Laporte. Pas fort! Sur la même image, remarquez que le chemin Montée Ouest est fait de 2 segments de couleur différente. C'est parce que ce chemin a été défini de 2 façons différentes et, par conséquent, on ne peut pas fusionner les 2 segments ensemble. L'un des segments vient de CanVec6 et l'autre de CanVec7. Belle rigueur! C'est un non-sens qu'une entité soit séparée en plusieurs parties parce qu'elle est à cheval sur une tuile. Le but de mon intervention est d'affirmer qu'il ne faut plus importer de tuile CanVec dans sa forme actuelle. Elles rend la carte lourde et difficile à éditer par des humains. Peut-on remplacer les tuiles de forêt par de simples rectangles? Oui et non. Les tuiles CanVec sont des multi-polygones et celà permet des trous. Ces trous sont utilisés (entre autres) pour représenter des clairières. Donc, au lieu d'un rectangle, on pourrait utiliser un multi-polygone avec des trous. Mais est-ce bien la bonne façon? Un trou (tel qu'uitlisé par CanVec) définit une zone undefined qui apparaît en blanc sur la carte. Ne serait-il pas mieux de créer une entité heath (ou autre) pour représenter cette clairière? Une clairière n'est pas un trou dans une forêt, tout comme une île n'est pas un trou dans un lac. J'aimerais qu'il y ait une discussion sur les points suivants: 1) est-ce que les tuiles CanVec sont la meilleure façon de représenter la forêt? 2) si non, peut-on définir une stratégie pour les remplacer (à long terme) 3) Pour les tuiles forêt, devrait-on utiliser un rectangle avec clairière explicite? 4) Pour les tuiles forêt, devrait-on utiliser un multi-polygone avec trous? J'espère que cette discussion nous fera progresser vers une carte de meilleure qualité et une meilleure performance. dega ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Discussion: zones boisées
Plusieurs (et j'en suis) ont exprimé leur désir d'avoir une meilleure couverture de forêt sur la carte OSM. Ces zones de forêt sont venues avec les importations CanVec mais ne progressent plus depuis un certain temps. Le présent article propose une façon de réaliser la forêt sans utiliser les abus de la méthode CanVec. Voyons un exemple. Dirigez votre éditeur préféré vers -74.375/46.1875 ou visionnez: http://www.openstreetmap.org/#map=16/46.1875/-74.3750 Vous y verrez deux tuiles de forêt. Chacune a été crée avec un rectangle de type natural:wood. Un simple rectangle de 4 points qu'on peut créer facilement. Cette tuile peut être vue simplement avec: http://openstreetmap.org/way/307466266 Voyons un autre exemple un peu plus à l'ouest (-74.500/46.1875). Dans votre éditeur, sélectionner la ligne qui délimite la tuile sud-ouest. On peut constater qu'elle est beaucoup plus complexe. On peut voir l'ensemble de cette ligne avec: http://openstreetmap.org/way/307466267 Elle est composée d'environ 1600 points. Elle est complexe parce qu'elle utilise l'approche everything but the kitchen sink. La tuile définit non seulement la forêt mais aussi les lacs, les rivières et les clairières. Pire encore, ce chemin de 1600 points fait partie d'une relation qui contient plusieurs dizaines de tels chemins. Affichez http://www.openstreetmap.org/relation/2368823 et remarquez le temps de chargement de la page. Revenons au premier exemple: http://www.openstreetmap.org/#map=14/46.1875/-74.3750 La forêt est un simple rectangle mais les lacs, les rivières et les chemins se superposent à la forêt. Il n'est donc pas nécessaire que le contour de forêt suive le contour des lacs et des rivières. Il y a un gain énorme en simplicité. Voyons un autre problème des tuiles CanVec: http://www.openstreetmap.org/#map=17/46.25047/-73.24885 Pour comprendre pourquoi il y a 3 Lac Laporte il faut utiliser l'éditeur: http://www.openstreetmap.org/edit?editor=id#map=17/46.25047/-73.24885 Les tuiles CanVec ont divisé le lac en 3 parties et ont créé 3 entités natual:water, chacune avec le nom Lac Laporte. Pas fort! Sur la même image, remarquez que le chemin Montée Ouest est fait de 2 segments de couleur différente. C'est parce que ce chemin a été défini de 2 façons différentes et, par conséquent, on ne peut pas fusionner les 2 segments ensemble. L'un des segments vient de CanVec6 et l'autre de CanVec7. Belle rigueur! C'est un non-sens qu'une entité soit séparée en plusieurs parties parce qu'elle est à cheval sur une tuile. Le but de mon intervention est d'affirmer qu'il ne faut plus importer de tuile CanVec dans sa forme actuelle. Elles rend la carte lourde et difficile à éditer par des humains. Peut-on remplacer les tuiles de forêt par de simples rectangles? Oui et non. Les tuiles CanVec sont des multi-polygones et celà permet des trous. Ces trous sont utilisés (entre autres) pour représenter des clairières. Donc, au lieu d'un rectangle, on pourrait utiliser un multi-polygone avec des trous. Mais est-ce bien la bonne façon? Un trou (tel qu'uitlisé par CanVec) définit une zone undefined qui apparaît en blanc sur la carte. Ne serait-il pas mieux de créer une entité heath (ou autre) pour représenter cette clairière? Une clairière n'est pas un trou dans une forêt, tout comme une île n'est pas un trou dans un lac. J'aimerais qu'il y ait une discussion sur les points suivants: 1) est-ce que les tuiles CanVec sont la meilleure façon de représenter la forêt? 2) si non, peut-on définir une stratégie pour les remplacer (à long terme) 3) Pour les tuiles forêt, devrait-on utiliser un rectangle avec clairière explicite? 4) Pour les tuiles forêt, devrait-on utiliser un multi-polygone avec trous? J'espère que cette discussion nous fera progresser vers une carte de meilleure qualité et une meilleure performance. dega ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Discussion: zones boisées
Hi Dega, Sorry, you can't just get away with not creating holes for lakes, clearings, etc. What if you get an extract of OSM, and you're only interested in the forests, because you want to calculate the percentage of forest coverage. You don't get information about lakes, heath and other land uses when you don't cut out holes from multipolygons. A better idea might be cutting the forest polygons along the roads. That way they become much more manageable, so forests crossing tile boundaries can be merged as well. For the north this might not work well, because of a lack of roads. Also rivers could be used as forest delimiters, but although there are a lot of rivers, very large chunks of forests will likely remain. However, there remains another problem, which is also shown near Lac Laporte, namely inconsistent landuse along sheet boundaries. That can't be easily fixed, especially not when there is no detailed imagery. The problem of the lakes which are not merged should be fixed. I know, I've imported quite a lot of Canvec data myself, and I haven't always followed the best practices myself, but it's pretty an arduous task. However, it is doable. Recently I've imported a few sheets, and I took attention of merging lakes and avoiding duplicate rings. (As a GIS-professional, I still don't see a problem with the latter, but it's OSM practice to get rid of them.) Regards, Frank On 19-11-2014 17:06, Ga Delap wrote: Plusieurs (et j'en suis) ont exprimé leur désir d'avoir une meilleure couverture de forêt sur la carte OSM. Ces zones de forêt sont venues avec les importations CanVec mais ne progressent plus depuis un certain temps. Le présent article propose une façon de réaliser la forêt sans utiliser les abus de la méthode CanVec. Voyons un exemple. Dirigez votre éditeur préféré vers -74.375/46.1875 ou visionnez: http://www.openstreetmap.org/#map=16/46.1875/-74.3750 Vous y verrez deux tuiles de forêt. Chacune a été crée avec un rectangle de type natural:wood. Un simple rectangle de 4 points qu'on peut créer facilement. Cette tuile peut être vue simplement avec: http://openstreetmap.org/way/307466266 Voyons un autre exemple un peu plus à l'ouest (-74.500/46.1875). Dans votre éditeur, sélectionner la ligne qui délimite la tuile sud-ouest. On peut constater qu'elle est beaucoup plus complexe. On peut voir l'ensemble de cette ligne avec: http://openstreetmap.org/way/307466267 Elle est composée d'environ 1600 points. Elle est complexe parce qu'elle utilise l'approche everything but the kitchen sink. La tuile définit non seulement la forêt mais aussi les lacs, les rivières et les clairières. Pire encore, ce chemin de 1600 points fait partie d'une relation qui contient plusieurs dizaines de tels chemins. Affichez http://www.openstreetmap.org/relation/2368823 et remarquez le temps de chargement de la page. Revenons au premier exemple: http://www.openstreetmap.org/#map=14/46.1875/-74.3750 La forêt est un simple rectangle mais les lacs, les rivières et les chemins se superposent à la forêt. Il n'est donc pas nécessaire que le contour de forêt suive le contour des lacs et des rivières. Il y a un gain énorme en simplicité. Voyons un autre problème des tuiles CanVec: http://www.openstreetmap.org/#map=17/46.25047/-73.24885 Pour comprendre pourquoi il y a 3 Lac Laporte il faut utiliser l'éditeur: http://www.openstreetmap.org/edit?editor=id#map=17/46.25047/-73.24885 Les tuiles CanVec ont divisé le lac en 3 parties et ont créé 3 entités natual:water, chacune avec le nom Lac Laporte. Pas fort! Sur la même image, remarquez que le chemin Montée Ouest est fait de 2 segments de couleur différente. C'est parce que ce chemin a été défini de 2 façons différentes et, par conséquent, on ne peut pas fusionner les 2 segments ensemble. L'un des segments vient de CanVec6 et l'autre de CanVec7. Belle rigueur! C'est un non-sens qu'une entité soit séparée en plusieurs parties parce qu'elle est à cheval sur une tuile. Le but de mon intervention est d'affirmer qu'il ne faut plus importer de tuile CanVec dans sa forme actuelle. Elles rend la carte lourde et difficile à éditer par des humains. Peut-on remplacer les tuiles de forêt par de simples rectangles? Oui et non. Les tuiles CanVec sont des multi-polygones et celà permet des trous. Ces trous sont utilisés (entre autres) pour représenter des clairières. Donc, au lieu d'un rectangle, on pourrait utiliser un multi-polygone avec des trous. Mais est-ce bien la bonne façon? Un trou (tel qu'uitlisé par CanVec) définit une zone undefined qui apparaît en blanc sur la carte. Ne serait-il pas mieux de créer une entité heath (ou autre) pour représenter cette clairière? Une clairière n'est pas un trou dans une forêt, tout comme une île n'est pas un trou dans un lac. J'aimerais qu'il y ait une discussion sur les points suivants: 1) est-ce que les tuiles CanVec sont la meilleure façon de représenter la forêt? 2) si
[Talk-ca] Discussion: zones boisées
Salut Frank, long time no see ... What if you get an extract of OSM, and you're only interested in the forests, because you want to calculate the percentage of forest coverage. You don't get information about lakes, heath and other land uses when you don't cut out holes from multipolygons. You're right but that's a moot point. From my point of view, OSM is not a tool for GIS professionals. It's a community project (activité citoyenne). From a scientific and rigorous perspective, a forest must have a hole for any 2D entity (lake, river, road, street and building). But, if you go that way, editing the map will become so complex (or arduous as you say) that no normal contributor will be interested any more. Look at this monstruous way: http://openstreetmap.org/way/175486790 It's a CanVec import with 1420 nodes, part of relation 2344036. The way was imported after many of the streets have been created. So the forest is on top of streets and roads and there's no hole for them. Do you really think a human being will get satisfaction and pride if he/she have to dig holes around every street? And look at the above example. The golf course is on top of the forest (without a hole) albeit it has a significant area. It the goal is to use the OSM database as a rigorous GIS ressource, then the tools designed for humans (Id, Potlatch, JOSM) will have to be modified to automatically create a hole around any 2D object. If they are not modified, you may say goodbye to normal contributors. You may also broadcast this message to Europe because the first european forest I looked at do not have holes for lake, rivers and roads. http://www.openstreetmap.org/#map=15/52.1965/-3.8386 Regards, dega ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-cz] Podivné relace a překryvy landuse=*
Ahoj, Dne 19.11.2014 8:29, Petr Vejsada napsal(a): Ahoj, dává smysl relace s pouze inner cestami? 24777 je takovou. Tady asi měla být cesta 273460501 (les) jako outer. IMHO jasná chyba. Ta relace býval normální uhul:wms les, ale pak ho někdo rozdělil na víc kusů a neopravil původní relaci. Pak jsou tu překryvy v landuse, které se snažím řešit, některé jsou dost masakrózní, třeba relace 934661 a 25984 - jeden a ten samý les, jen s jinými dírami. Viděl jsem lepší, byla to nějaká zoologická zahrada nebo park. Tam to byly tuším tři relace s několika stejnými outer cestami. Obyčejné překryvy landuse asi půjde vyřešit botem stejně jako velké překryvy budov, ale tohle teda asi ne :( V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou největší problém při identifikaci, o jakou plochu se vůbec jedná. Hlavně u inner cest, kde je v tagování pěkný chaos. Ale už jsem viděl nekonzistentní tagování i u outer cest. V podstatě teď nedovolím říznout do víc než jedné otagované cesty zároveň, protože jinak bych musel výčtem kontrolovat všechny legální, pololegální a nelegální kombinace tagů v zasažených cestách multipolygonu. (A zvykl jsem si v JOSM každý landuse multipolygon okamžitě ručně opravit na new-style tagování, když na něj narazím. :-)) Pokud jde o členství v landuse multipolygon relacích, je běžné že inner cesta v jedné relaci je zároveň outer cesta v druhé relaci. Multipolygon pouze s inner cestami je imho vždy nesmysl. Společná outer cesta ve více multipolygonech může být teoreticky v pořádku, pokud je to hraniční cesta mezi dvěma sousedními plochami. Ale v 95% případů to bude spíš taky chyba. Martin -- Petr p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
On Wed, Nov 19, 2014 at 12:56:47PM +0100, Martin Švec - OSM wrote: V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou Kdyz jsme u toho je nekde na wiki popsan old a new style? Dik -- Tomas Kasparek e-mail: kaspa...@fit.vutbr.cz CVT FIT VUT Brno, L127 jabber: tomas.kaspa...@jabber.cz Bozetechova 1, 612 66web : http://www.fit.vutbr.cz/~kasparek Brno, Czech Republic phone : +420 54114-1220 GPG:2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! pgp6yozTGi2RM.pgp Description: PGP signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
Dne 19.11.2014 15:39, Kasparek Tomas napsal(a): On Wed, Nov 19, 2014 at 12:56:47PM +0100, Martin Švec - OSM wrote: V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou Kdyz jsme u toho je nekde na wiki popsan old a new style? http://wiki.openstreetmap.org/wiki/Relation:multipolygon ... sekce Tagging, popř. Mapping Style, best practice: *apply all tags which describe the area **/to the relation, and not to the ways/*. Stručně řečeno: * new-style = tagy popisující vlastnosti plochy multipolygonu jsou pouze na relaci. * old-style = tagy jsou na outer cestách, popř. na outer i inner cestách (u nás hodně lesů), případně mix všech tří způsobů v důsledku editací. Jak mají renderery ten chaos řešit je nastíněno v sekci Detailed tagging, ale řada kombinací tam chybí nebo nesedí s praxí. Podle těch pravidel by se např. otagované inner cesty uhul:wms lesů neměly renderovat jako díry. Editacemi old-style multipolygonu pak bohužel často padneš do kategorie undefined results, aniž by sis toho vůbec všiml. Martin Dik ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
Ahoj, On Wed, Nov 19, 2014 at 12:56:47PM +0100, Martin Švec - OSM wrote: V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou největší problém při identifikaci, o jakou plochu se vůbec jedná. Hlavně u inner cest, kde je v tagování pěkný chaos. Ale už jsem viděl nekonzistentní tagování i u outer cest. V podstatě teď nedovolím říznout do víc než jedné otagované cesty zároveň, protože jinak bych musel výčtem kontrolovat všechny legální, pololegální a nelegální kombinace tagů v zasažených cestách multipolygonu. (A zvykl jsem si v JOSM každý landuse multipolygon okamžitě ručně opravit na new-style tagování, když na něj narazím. :-)) mám tu ten otestovaný skript na lesy. Nebyl nikdy použit naostro, ale použít se může. Otestovaný znamená, že byla ověřeno u značného množství lesů, že spuštění skriptu neudělá ještě větší binec, ale pomůže spíš pořádku. Zobecnit to na všechny relace s landuse či na všechny relace si netroufám, to by potřebovalo větší průzkum. Není totiž pravda, že všechny tagy z outer cesty by se měly přesunout na relaci. Příklad - oplocený les, obora. landuse=forest má být na relaci, ale barrier=fence má být na outer cestě. Přesun plotu na relaci by bylo chybou (za předpokladu, díry nejsou také oplocené...). No já se spíš orientuju na mazání zjevných duplicit. -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
On Wed, Nov 19, 2014 at 04:20:31PM +0100, Martin Švec - OSM wrote: Dne 19.11.2014 15:39, Kasparek Tomas napsal(a): On Wed, Nov 19, 2014 at 12:56:47PM +0100, Martin Švec - OSM wrote: V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou Kdyz jsme u toho je nekde na wiki popsan old a new style? http://wiki.openstreetmap.org/wiki/Relation:multipolygon ... sekce Tagging, popř. Mapping Style, best practice: *apply all tags which describe the area **/to the relation, and not to the ways/*. Stručně řečeno: * new-style = tagy popisující vlastnosti plochy multipolygonu jsou pouze na relaci. * old-style = tagy jsou na outer cestách, popř. na outer i inner cestách (u nás hodně lesů), případně mix všech tří způsobů v důsledku editací. Jak mají renderery ten chaos řešit je nastíněno v sekci Detailed tagging, ale řada kombinací tam chybí nebo nesedí s praxí. Podle těch pravidel by se např. otagované inner cesty uhul:wms lesů neměly renderovat jako díry. Editacemi old-style multipolygonu pak bohužel často padneš do kategorie undefined results, aniž by sis toho vůbec všiml. Diky, takhle jsem si to predstavoval. -- Tomas Kasparek e-mail: kaspa...@fit.vutbr.cz CVT FIT VUT Brno, L127 jabber: tomas.kaspa...@jabber.cz Bozetechova 1, 612 66web : http://www.fit.vutbr.cz/~kasparek Brno, Czech Republic phone : +420 54114-1220 GPG:2F1E 1AAF FD3B CFA3 1537 63BD DCBE 18FF A035 53BC May the command line live forever! pgpwNHHQarEYN.pgp Description: PGP signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
Dne 19.11.2014 16:29, Petr Vejsada napsal(a): Ahoj, On Wed, Nov 19, 2014 at 12:56:47PM +0100, Martin Švec - OSM wrote: V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou největší problém při identifikaci, o jakou plochu se vůbec jedná. Hlavně u inner cest, kde je v tagování pěkný chaos. Ale už jsem viděl nekonzistentní tagování i u outer cest. V podstatě teď nedovolím říznout do víc než jedné otagované cesty zároveň, protože jinak bych musel výčtem kontrolovat všechny legální, pololegální a nelegální kombinace tagů v zasažených cestách multipolygonu. (A zvykl jsem si v JOSM každý landuse multipolygon okamžitě ručně opravit na new-style tagování, když na něj narazím. :-)) mám tu ten otestovaný skript na lesy. Nebyl nikdy použit naostro, ale použít se může. Otestovaný znamená, že byla ověřeno u značného množství lesů, že spuštění skriptu neudělá ještě větší binec, ale pomůže spíš pořádku. Záleží jak máš chuť a čas :-) Co si matně vzpomínám, zasekli jsme se na odstraňování tagů z inner cest. Můžu s tím zas pomoct, ale od začátku října jsem strávil většinu času předěláváním LPIS traceru, takže jsem to zatím pustil z hlavy. Rozhodně by to pomohlo traceru, multipolygony bez otagovaných cest rozřezává mnohem agresivněji, to je jen čistá geometrie. Přemýšlel jsem i o zaintegrování opravy old-style lesních multipolygonů přímo do LPIS traceru. Stejně se při ořezech do multipolygonů zasahuje, tak by se v rámci ořezu upravily pro přesně definované případy i landuse=forest tagy. Zobecnit to na všechny relace s landuse či na všechny relace si netroufám, to by potřebovalo větší průzkum. Není totiž pravda, že všechny tagy z outer cesty by se měly přesunout na relaci. Příklad - oplocený les, obora. Jo, určitě. To jsme probírali už v září, že přesouvat se může jen landuse=forest tag. Další typy landuse by se musely prozkoumat. landuse=forest má být na relaci, ale barrier=fence má být na outer cestě. Přesun plotu na relaci by bylo chybou (za předpokladu, díry nejsou také oplocené...). No já se spíš orientuju na mazání zjevných duplicit. Martin ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
Dne 19.11.2014 17:18, Martin Švec - OSM napsal(a): Dne 19.11.2014 16:29, Petr Vejsada napsal(a): Zobecnit to na všechny relace s landuse či na všechny relace si netroufám, to by potřebovalo větší průzkum. Není totiž pravda, že všechny tagy z outer cesty by se měly přesunout na relaci. Příklad - oplocený les, obora. Jo, určitě. To jsme probírali už v září, že přesouvat se může jen landuse=forest tag. Další typy landuse by se musely prozkoumat. Ohledně zobecnění na další multipolygony by asi stálo za to se podívat na kód osm2pgsql, který tohle obstarává. Před rokem jsem se trochu šťoural v jednom bugu [1], který s tím souvisí - tenkrát jsem docela načetl kód, co to obstarává. Pokud se něco nezměnilo, tak to není moc ideální, ale funguje to ve většině případů. Myslím, že pokud by se takto přetogovalo vše na new-style, tak jedině dobře. Je možné, že občas bude výsledek ne úplně ideálně správný, ale aspoň bude shodný s tím, jak se to chová teď, protože většina lidí stejně nejprve importuje OSM data přes osm2pgsql do postgisu a pak s nima pracuje dál. S pozdravem, Petr Morávek aka Xificurk [1] https://github.com/openstreetmap/osm2pgsql/issues/80 ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
Dne 19.11.2014 v 12:56 Martin Švec - OSM napsal(a): Ahoj, Dne 19.11.2014 8:29, Petr Vejsada napsal(a): Ahoj, dává smysl relace s pouze inner cestami? 24777 je takovou. Tady asi měla být cesta 273460501 (les) jako outer. IMHO jasná chyba. Ta relace býval normální uhul:wms les, ale pak ho někdo rozdělil na víc kusů a neopravil původní relaci. Pak jsou tu překryvy v landuse, které se snažím řešit, některé jsou dost masakrózní, třeba relace 934661 a 25984 - jeden a ten samý les, jen s jinými dírami. Viděl jsem lepší, byla to nějaká zoologická zahrada nebo park. Tam to byly tuším tři relace s několika stejnými outer cestami. Obyčejné překryvy landuse asi půjde vyřešit botem stejně jako velké překryvy budov, ale tohle teda asi ne :( V první řadě bych asi oprášil myšlenku opravy old-style landuse multipolygonů na new-style multipolygony. Co dělám na ořezu multipolygonů v LPIS traceru, tak old-style multipolygony jsou největší problém při identifikaci, o jakou plochu se vůbec jedná. Hlavně u inner cest, kde je v tagování pěkný chaos. Ale už jsem viděl nekonzistentní tagování i u outer cest. V podstatě teď nedovolím říznout do víc než jedné otagované cesty zároveň, protože jinak bych musel výčtem kontrolovat všechny legální, pololegální a nelegální kombinace tagů v zasažených cestách multipolygonu. (A zvykl jsem si v JOSM každý landuse multipolygon okamžitě ručně opravit na new-style tagování, když na něj narazím. :-)) Pokud jde o členství v landuse multipolygon relacích, je běžné že inner cesta v jedné relaci je zároveň outer cesta v druhé relaci. Multipolygon pouze s inner cestami je imho vždy nesmysl. Společná outer cesta ve více multipolygonech může být teoreticky v pořádku, pokud je to hraniční cesta mezi dvěma sousedními plochami. Ale v 95% případů to bude spíš taky chyba. Cus, ty % chyb bych asi razantne snizil. Podivej se trebas na KU. Hromada cest je clenem 1-N relaci ruznych urovni, trebas v pripade statnich hranic je to zaroven soucast kraje, okresu, obce a konkretniho KU. Vubec bych se nedivil, kdyby to podobne bylo i jinde nez u hranic. Martin -- Petr p ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
Ahoj, Dne St 19. listopadu 2014 17:36:53, Petr Morávek [Xificurk] napsal(a): Ohledně zobecnění na další multipolygony by asi stálo za to se podívat na kód osm2pgsql, který tohle obstarává. Před rokem jsem se trochu šťoural v jednom bugu [1], který s tím souvisí - tenkrát jsem docela načetl kód, co to obstarává. Pokud se něco nezměnilo, tak to není moc ideální, ale funguje to ve většině případů. Myslím, že pokud by se takto přetogovalo vše na new-style, tak jedině dobře. Je možné, že občas bude výsledek ne úplně ideálně správný, ale aspoň bude shodný s tím, jak se no, když to máš nastudované, tak bych docela uvítal tvůj popis než abych to třeba studoval od začátku. to chová teď, protože většina lidí stejně nejprve importuje OSM data přes osm2pgsql do postgisu a pak s nima pracuje dál. to možná ano, ale že by zrovna pomocí osm2pgsql? Na analýzy se hodí víc snapshot schema a to se dělá přes osmosis. Nemám na to kapacitu si teď přibrat studium osm2pgsql, přesto díky za tip. Zpět k tomu stávajícímu skriptu. Pustil jsem si ho teď na pouhých 5 lesů a zjistil jsem, že neodstraňuje tagy landuse=forest na inner cestách. Tak jsem to upravil - jednak jsem přidal na univerzálnosti, že jako parametr je teď k,v , tedy mohu zadat nejen landuse=forest, ale cokoli=cokoli. Nato jsem si uvědomil, že může být i situace: outer landuse=forest, forest_type=typ_a inner landuse=forest, forest_type=typ_b a pak bych na inner cestě odstranil landuse=forest neoprávněně. Hmm, co s tím? -- Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podivné relace a překryvy landuse=*
Dne 19.11.2014 20:19, Petr Vejsada napsal(a): Ahoj, Dne St 19. listopadu 2014 17:36:53, Petr Morávek [Xificurk] napsal(a): Ohledně zobecnění na další multipolygony by asi stálo za to se podívat na kód osm2pgsql, který tohle obstarává. Před rokem jsem se trochu šťoural v jednom bugu [1], který s tím souvisí - tenkrát jsem docela načetl kód, co to obstarává. Pokud se něco nezměnilo, tak to není moc ideální, ale funguje to ve většině případů. Myslím, že pokud by se takto přetogovalo vše na new-style, tak jedině dobře. Je možné, že občas bude výsledek ne úplně ideálně správný, ale aspoň bude shodný s tím, jak se no, když to máš nastudované, tak bych docela uvítal tvůj popis než abych to třeba studoval od začátku. Ono se mi toho za ten rok už dost z hlavy vypařilo :-) Zkusím se na to podívat a sepsat nějak srozumitelně algoritmus, který se používá. Ale neslibuju, kdy se k tomu dostanu... Bohužel jsem teď dost vytížen jinými záležitostmi. S pozdravem, Petr Morávek aka Xificurk ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
[OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Bonjour à tous, A Marseille nous avons de nombreuses Traverses. Or sur la carte de rapprochement des sources, Traverse a l'air d'être transformé automatiquement en Terrasse. Exemple : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/43.31369/5.46615 Et de fait, quand je regarde la page du rapprochement FANTOIR / OSM, je vois l'abréviation TSSE : http://cadastre.openstreetmap.fr/fantoir/#insee=13212 Le terrain et le cadastre, eux, donnent bien des Traverses et non des Terrasses. Comment corriger ça ? C'est un problème du FANTOIR non ? Charles. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Bonjour, Il faut ajouter le code Fantoir sur les voies en question. Par exemple, pour la Traverse de la Malvina, il faut ajouter le tag ref:FR:FANTOIR=132125623A Stéphane Le mercredi 19 novembre 2014 09:47:02, Charles Nepote a écrit : Bonjour à tous, A Marseille nous avons de nombreuses Traverses. Or sur la carte de rapprochement des sources, Traverse a l'air d'être transformé automatiquement en Terrasse. Exemple : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/43.31369/5.46615 Et de fait, quand je regarde la page du rapprochement FANTOIR / OSM, je vois l'abréviation TSSE : http://cadastre.openstreetmap.fr/fantoir/#insee=13212 Le terrain et le cadastre, eux, donnent bien des Traverses et non des Terrasses. Comment corriger ça ? C'est un problème du FANTOIR non ? Charles. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Bonjour, De: Charles Nepote char...@nepote.org A Marseille nous avons de nombreuses Traverses. Or sur la carte de rapprochement des sources, Traverse a l'air d'être transformé automatiquement en Terrasse. Exemple : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/43.31369/5.46615 Et de fait, quand je regarde la page du rapprochement FANTOIR / OSM, je vois l'abréviation TSSE : http://cadastre.openstreetmap.fr/fantoir/#insee=13212 Le terrain et le cadastre, eux, donnent bien des Traverses et non des Terrasses. Comment corriger ça ? C'est un problème du FANTOIR non ? Sur le principe Fantoir connaît bien les deux types, terrasse (TSSE) et traverse (TRA) qui sont répertoriés pour les traitements de rapprochement : https://github.com/osm-fr/bano/blob/9cb5ba5d171c7a0c5ca93f2b6d2af59a8c42f446/dictionnaires/abrev_type_voie.txt#L222 et https://github.com/osm-fr/bano/blob/9cb5ba5d171c7a0c5ca93f2b6d2af59a8c42f446/dictionnaires/abrev_type_voie.txt#L226 Si par corriger tu entends dégommer du rouge sur la carte, la seule possibilité est de renseigner le code Fantoir directement sur les ways avec le tag ref:FR:FANTOIR (ou sur la relation associatedStreet correspondante quand elle existe). Pour le plus long terme, je dois rajouter sur les pages de rapprochement OSM/FANTOIR un moyen de qualifier un code Fantoir en fonction d'une anomalie qui lui est associée (cf https://lists.openstreetmap.org/pipermail/talk-fr/2014-October/072638.html). Ça permettra de garder la mémoire de ces divergences. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base d'adresse : union de raison entre l'IGN et OpenStreetMap
2014-11-18 20:44 GMT+01:00 Pierre Knobel pierr...@gmail.com: Je trouve que c'est une énorme concession qu'on leur fait, de les autoriser à vendre nos contributions à Google (si on choisit de contribuer à la BAN... pour ma part ce n'est pas encore décidé). C'est toute la question de cette histoire de double license. Je ne sais pas dans quelle mesure il sera légalement possible de distribuer le même jeu de données avec des clauses contradictoires comme le partage à l'identique. De fait, la license payante annule les contraintes de la license libre. Ou inversement... Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] création semi automatique d'associed street
Bonjour Je voudrais transformer les addr:* pour les intégrer dans des relations associeted street. J'ai une méthode en tête et je voudrais partager ma méthode pour savoir si je ne fais pas d'impair : Dans JOSM, je charge un zone contenant les éléments de la rue je filtre sur (type=node AND addr:street=foo) OR (type=way AND name = foo) Logiquement je n'obtient que les éléments de la relation. Je les regroupe dans une relation, les noeud (house) et le chemin (street) en ajoutant les éléments fantoir et nom. Au suivant C'est bien ? Cordialement -- David Crochet ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Le 19/11/2014 10:16, Vincent de Château-Thierry a écrit : Bonjour, De: Charles Nepote char...@nepote.org A Marseille nous avons de nombreuses Traverses. Or sur la carte de rapprochement des sources, Traverse a l'air d'être transformé automatiquement en Terrasse. Exemple : http://tile.openstreetmap.fr/~cquest/leaflet/bano.html#17/43.31369/5.46615 Et de fait, quand je regarde la page du rapprochement FANTOIR / OSM, je vois l'abréviation TSSE : http://cadastre.openstreetmap.fr/fantoir/#insee=13212 Le terrain et le cadastre, eux, donnent bien des Traverses et non des Terrasses. Comment corriger ça ? C'est un problème du FANTOIR non ? Sur le principe Fantoir connaît bien les deux types, terrasse (TSSE) et traverse (TRA) qui sont répertoriés pour les traitements de rapprochement : https://github.com/osm-fr/bano/blob/9cb5ba5d171c7a0c5ca93f2b6d2af59a8c42f446/dictionnaires/abrev_type_voie.txt#L222 et https://github.com/osm-fr/bano/blob/9cb5ba5d171c7a0c5ca93f2b6d2af59a8c42f446/dictionnaires/abrev_type_voie.txt#L226 Si par corriger tu entends dégommer du rouge sur la carte, la seule possibilité est de renseigner le code Fantoir directement sur les ways avec le tag ref:FR:FANTOIR (ou sur la relation associatedStreet correspondante quand elle existe). Pour le plus long terme, je dois rajouter sur les pages de rapprochement OSM/FANTOIR un moyen de qualifier un code Fantoir en fonction d'une anomalie qui lui est associée (cf https://lists.openstreetmap.org/pipermail/talk-fr/2014-October/072638.html). Ça permettra de garder la mémoire de ces divergences. Merci Vincent. Oui c'est le long terme qui m'intéresse. Dégommer du rouge n'a pas de sens car c'est reculer pour mieux sauter dans ce cas. Il y a un moment il faudra un feedback aux agents qui complètent le FANTOIR et il nous faut donc garder la mémoire de la divergence. En attendant la mise en oeuvre de ton excellente proposition (que j'avais loupée) je préfère ne rien rapprocher du tout et laisser les avertissements. Vous avez déjà des contacts avec la DGFip pour savoir comment ils bossent sur ces données (comment il les collectent, comment il les corrigent) ? Je peux me renseigner via Etalab mais comme Christian est déjà dans la place je suppose qu'il a toute latitude aussi ;-) Je pense que c'est très important de documenter un peu ce genre de cas : les cas de co-production / co-correction entre acteurs publics et communautés pourraient se multiplier au bénéfice de tous. Il faut des exemples solides pour convaincre plus d'acteurs. Charles. vincent ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] création semi automatique d'associed street
2014-11-19 11:03 GMT+01:00 david.croc...@online.fr: Bonjour Je voudrais transformer les addr:* pour les intégrer dans des relations associeted street. Euh, si les adresses sont déjà dans OSM, il suffit de mettre le code fantoir sur la voie, pas besoin de transformer les addr en relation. Je rappelerais juste ici que d'après les stats mondiales, le modèle associatedStreet reste bien en deça du modèle sans relation et est même en perte de vitesse (3.4M contre 42.7M alors qu'on avait 2.1M contre 23M il y a un an). Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
2014-11-19 11:08 GMT+01:00 Charles Nepote char...@nepote.org: En attendant la mise en oeuvre de ton excellente proposition (que j'avais loupée) je préfère ne rien rapprocher du tout et laisser les avertissements. Je ne pense pas que ce soit une bonne idée. A terme, la base adresse unitifée devra identifier les divergences sur les noms de voies (ou abréviations) entres les divers bases nationales (IGN, la poste, cadastre, etc). Le moyen le plus facile pour comparer ces noms sera d'abord d'utiliser l'identifiant unique qu'est le code fantoir. En l'ajoutant dans OSM, tu valides le fait que le nom dans OSM est le nom correct. Aux autres ensuite de s'adapter. Et en leur fournissant le code fantoir depuis OSM, tu facilites la tâche de rapprochement. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] création semi automatique d'associed street
-Message d'origine- De : Pieren [mailto:pier...@gmail.com] Envoyé : mercredi 19 novembre 2014 11:22 À : Discussions sur OSM en français Objet : Re: [OSM-talk-fr] création semi automatique d'associed street 2014-11-19 11:03 GMT+01:00 david.croc...@online.fr: Bonjour Je voudrais transformer les addr:* pour les intégrer dans des relations associeted street. Euh, si les adresses sont déjà dans OSM, il suffit de mettre le code fantoir sur la voie, pas besoin de transformer les addr en relation. Je rappelerais juste ici que d'après les stats mondiales, le modèle associatedStreet reste bien en deça du modèle sans relation et est même en perte de vitesse (3.4M contre 42.7M alors qu'on avait 2.1M contre 23M il y a un an). -- Je trouve que le modèle AssociatedStreet permet de mieux contrôler la cohérence (n° en double, différence libellé voie/relation). Du moins dans JOSM Denis ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] création semi automatique d'associed street
Le 19/11/2014 11:03, david.croc...@online.fr a écrit : Bonjour Je voudrais transformer les addr:* pour les intégrer dans des relations associeted street. J'ai une méthode en tête et je voudrais partager ma méthode pour savoir si je ne fais pas d'impair : Dans JOSM, je charge un zone contenant les éléments de la rue je filtre sur (type=node AND addr:street=foo) OR (type=way AND name = foo) Logiquement je n'obtient que les éléments de la relation. Je les regroupe dans une relation, les noeud (house) et le chemin (street) en ajoutant les éléments fantoir et nom. Au suivant C'est bien ? Cordialement J'ai fait un script pour ça. Je me demande si ça ne faudrait pas le coup d'en faire un service web sur une commune (id de relation). https://www.mail-archive.com/talk-fr@openstreetmap.org/msg71776.html Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] création semi automatique d'associed street
Le 19/11/2014 11:38, Frédéric Rodrigo a écrit : Je voudrais transformer les addr:* pour les intégrer dans des relations associeted street. J'ai encore du mal à comprendre l'émerveillement devant les relations associated_street. Du point de vue du contributeur, c'est galère à entretenir (ajouter un nœud unique à une rue existante). Du point de vue du consommateur, entre un appel à overpass pour récupérer les addr:street=* ou à l'api pour récupérer une relation, je ne vois pas trop la différence. Et du point de vue de la qualité, repérer les addr:street qui ne correspondent à aucune rue dans le coin ne semble pas bien complexe non plus, ni de vérifier des numéros multiples (ceci dit, ces cas ne semblent pas être vérifiés par le validateur de JOSM. Un ticket à créer ?). J'évite le sujet des rues à cheval sur plusieurs communes. Bon, ceci dit, j'en ai créé un bon nombre quand même, vu que les outils d'intégration les proposent par défaut. JB. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] création semi automatique d'associed street
2014-11-19 11:38 GMT+01:00 Frédéric Rodrigo fred.rodr...@gmail.com: J'ai fait un script pour ça. Je me demande si ça ne faudrait pas le coup d'en faire un service web sur une commune (id de relation). Attention, Je suis contre un tel changement automatisé. Il faudrait qu'il y a un consensus d'abord sur ce sujet. Et je pense qu'il reste trop de problèmes avec la relation associatedStreet qui est aussi critiquée dans d'autres pays. Denis a raison de pointer ses avantages mais il y a aussi des inconvénients majeurs comme la complexité accrue de modifier ces données par des nouveaux arrivants (esayez de déplacer un numéro d'un bâtiment vers un autre ou l'attacher à une autre rue avec iD pour comprendre). L'immense majorité des contributeurs font moins de 10 contributions au total mais ce sont les plus précieux car ils corrigent ce qu'ils reconnaissent comme une erreur (le terrain, toujours le terrain). Alors que la quasi totalité de nos adresses proviennent du cadastre et qu'on y connait un taux d'erreur non négligeable. Faut-il rappeler que l'édition automatique de données OSM doit suivre certaines règles ([1]). Je sais que certains passent déjà outre cette règle et ont déjà massivement modifier les addr en relations (je ne suis pas idiot non plus). Mais j'ai laissé faire tant que c'était des initiatives personnelles. Je pourrais moi aussi faire un script (ou un plugin) qui permettrait ces changements dans le sens inverse (beaucoup plus simple à faire dans ce sens). Ca serait dommage d'en arriver là. Ou même d'en passer par le DWG car j'ai toujours estimé que nous étions assez grands pour nous mettre d'accord tous seuls. Pieren [1] http://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base d'adresse : union de raison entre l'IGN et OpenStreetMap
Le 18 novembre 2014 20:44, Pierre Knobel pierr...@gmail.com a écrit : Je trouve que c'est une énorme concession qu'on leur fait, de les autoriser à vendre nos contributions à Google (si on choisit de contribuer à la BAN... pour ma part ce n'est pas encore décidé). Et l'énorme concession de passer la base adresse actuelle sous une licence libre ? Il ne faut pas l'oublier ! Regardons les données en face: actuellement il y a un pourcentage infime de BANO qui provient réellement de contributions OSM. Sur les 15% des données OSM de BANO, la très grande majorité sont des imports de données opendata (parfois avec une vérification sérieuse, par fois pas), et des adresses provenant du cadastre (là aussi plus ou moins vérifiées). De plus, je le répète une fois de plus... on contribuera à la BAN uniquement si on veut, les contributions OSM n'iront pas dans la BAN car il n'est pas question que des données ODbL soient revendues sans partage à l'identique. Le 18 novembre 2014 21:28, Yves Pratter yves.prat...@gmail.com a écrit : Oui, sauf qu'avec un robot et/ou un filtre en entrée de la base de données OSM, on peut faire une mise à jour de la BAN :) Techniquement on peut, mais la licence ne le permet pas. Le 18 novembre 2014 21:28, Yves Pratter yves.prat...@gmail.com a écrit : La Poste et l'IGN sont encore des services publiques ? Ou ira cet argent ? Comment sera partagé le gâteau entre La Poste, l'IGN... ? Il ne va pas y avoir de gros changement par rapport à la situation actuelle où l'IGN et La Poste commercialisent leur bases d'adresses respectives. Justement, c'est l'incapacité de ce modèle économique à évoluer rapidement qui oblige ces opérateurs à poursuivre leur commercialisation. L'idée aurait été pour l'IGN que l'Etat compense un vrai passage en opendata, mais vu l'état des finance, c'est par pour tout de suite ! En ce qui concerne l'IGN, cela permettra de contribuer au financement des tâches qui lui incombe (carte homogène sur tout le territoire...). Donc pourquoi pas. Oui, l'IGN pourra se concentrer sur les zones où il y a moins de contributions externes qui seront faites. C'est une compensation bien utile pour une couverture homogène du territoire. Dans le dispositif il y a aussi beaucoup d'autres partenaires à prévoir: les communes bien sûr, les EPCI, les collectivités, les SDIS et autres services publics. Bref, l'objectif c'est qu'un maximum de monde collabore pour avoir une base la plus complète, exacte et à jour possible. Le 19 novembre 2014 10:17, Pieren pier...@gmail.com a écrit : C'est toute la question de cette histoire de double license. Je ne sais pas dans quelle mesure il sera légalement possible de distribuer le même jeu de données avec des clauses contradictoires comme le partage à l'identique. De fait, la license payante annule les contraintes de la license libre. Ou inversement... La ville de Paris ou le Grand Lyon le font. -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [vidéo] Charting culture
Le mardi 18 novembre 2014 23:59:59 Philippe Verdy a écrit : Une vidéo avec un usage artistique et didactique des données OSM pour visualiser les migrations au cours des siècles et des continents. Au cas où vous l'auriez manquée. Jolie vidéo. Cependant, je ne saisis pas le rapport avec OSM. Un indice ? -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Le 19 novembre 2014 11:08, Charles Nepote char...@nepote.org a écrit : Merci Vincent. Oui c'est le long terme qui m'intéresse. Dégommer du rouge n'a pas de sens car c'est reculer pour mieux sauter dans ce cas. Il y a un moment il faudra un feedback aux agents qui complètent le FANTOIR et il nous faut donc garder la mémoire de la divergence. En attendant la mise en oeuvre de ton excellente proposition (que j'avais loupée) je préfère ne rien rapprocher du tout et laisser les avertissements. Vous avez déjà des contacts avec la DGFip pour savoir comment ils bossent sur ces données (comment il les collectent, comment il les corrigent) ? Je peux me renseigner via Etalab mais comme Christian est déjà dans la place je suppose qu'il a toute latitude aussi ;-) Maintenant qu'on a avancé avec l'IGN et La Poste, je vais retourner voir mes voisins de bureau de la DGFiP (étage au dessus, au bout du couloir) ;) Mieux comprendre le FANTOIR, sa constitution, voir comment on peut créer un vrai lien avec la BAN... voilà les enjeux futurs. Je pense que c'est très important de documenter un peu ce genre de cas : les cas de co-production / co-correction entre acteurs publics et communautés pourraient se multiplier au bénéfice de tous. Il faut des exemples solides pour convaincre plus d'acteurs. Rajouter les ref:FR:FANTOIR permet aux scripts de faire les rapprochements et aussi de détecter les différences et donc de les remonter comme telles. J'ai par exemple remonté près d'un millier de planches cadastrales raster à la projection incorrecte à la DGFiP avec un grand merci de leur part. Je pense que pour FANTOIR une remise au propre ne pourra pas faire de mal. Le coût de la non qualité est élevé ! -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Carto-partie ce samedi 22 novembre à Réserve Naturelle de Saucats (33)
Bonjour Frédéric, Peut-etre sera-t-il possible de relever quelques numéros de pylônes RTE dans ce coin ? http://www.openstreetmap.org/?mlat=44.654037952423096mlon=-0.5967378616333008#map=16/44.6139/-0.6160 A utliser avec le tag ref=*, je ne pourrai pas être dans ce coin samedi Bonne carto-partie :) François -- *François Lacombe* fl dot infosreseaux At gmail dot com www.infos-reseaux.com @InfosReseaux http://www.twitter.com/InfosReseaux Le 19 novembre 2014 12:00, Frédéric Rodrigo fred.rodr...@gmail.com a écrit : Bonjour, Ce samedi est organisé une cartopartie à Réserve Naturelle de Saucats-la Brède, réserve naturelle géologique en Gironde. Elle est co-orgnaisé par Les Petits Débrouillards Aquitaine dans le cadre du projet OpenAquiMap. Rendez-vous de 10h à 17h, point de départ la Maison de la réserve à Saucats. Pensez à apporter votre pique nique. http://osm.org/go/b~~CDiLs?m= Inscription facultative sur : http://framadate.org/aj2t43cz68pmcmub Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Le 19/11/2014 11:28, Pieren a écrit : 2014-11-19 11:08 GMT+01:00 Charles Nepote char...@nepote.org: En attendant la mise en oeuvre de ton excellente proposition (que j'avais loupée) je préfère ne rien rapprocher du tout et laisser les avertissements. Je ne pense pas que ce soit une bonne idée. A terme, la base adresse unitifée devra identifier les divergences sur les noms de voies (ou abréviations) entres les divers bases nationales (IGN, la poste, cadastre, etc). Le moyen le plus facile pour comparer ces noms sera d'abord d'utiliser l'identifiant unique qu'est le code fantoir. En l'ajoutant dans OSM, tu valides le fait que le nom dans OSM est le nom correct. Oui ça valide *implicitement* que le nom OSM est correct mais sans certitude : un mappeur pourrait vouloir attacher un code FANTOIR à une rue en dehors de toutes considération de véracité. Dire implicitement qu'un libellé FANTOIR est incorrect en rapprochant via le code ne dit pas explicitement pourquoi il y a une erreur et où est l'erreur. Le moment venu ne faudra-t-il pas refaire le travail d'explication ? On pourrait mettre l'explication dans le champ note= ? Aux autres ensuite de s'adapter. Et en leur fournissant le code fantoir depuis OSM, tu facilites la tâche de rapprochement. Je comprends bien mais je me dis que tant qu'à passer du temps sur un bug autant aller jusqu'au bout. Je me disais qu'il valait mieux commencer par traiter ceux qui ne posent pas de problème. Les autres vous fonctionnez comme Pieren sur ce sujet ? Si c'est le cas je m'incline sans problème (c'est aussi très plaisant de nettoyer du rouge ;-) Charles. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] création semi automatique d'associed street
+1 Les 2 modèles existent et cohabitent au niveau mondial, il n'y a pas de raison de privilégier un modèle plutôt qu'un autre, c'est plus une question de choix personnel. Si les adresses sont déjà dans OSM et qu'il n'y a pas d'erreur, il n'y a pas de raison de les éditer. Francisco - Mail original - De: Pieren pier...@gmail.com À: Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé: Mercredi 19 Novembre 2014 11:49:47 Objet: Re: [OSM-talk-fr]création semi automatique d'associed street 2014-11-19 11:38 GMT+01:00 Frédéric Rodrigo fred.rodr...@gmail.com: J'ai fait un script pour ça. Je me demande si ça ne faudrait pas le coup d'en faire un service web sur une commune (id de relation). Attention, Je suis contre un tel changement automatisé. Il faudrait qu'il y a un consensus d'abord sur ce sujet. Et je pense qu'il reste trop de problèmes avec la relation associatedStreet qui est aussi critiquée dans d'autres pays. Denis a raison de pointer ses avantages mais il y a aussi des inconvénients majeurs comme la complexité accrue de modifier ces données par des nouveaux arrivants (esayez de déplacer un numéro d'un bâtiment vers un autre ou l'attacher à une autre rue avec iD pour comprendre). L'immense majorité des contributeurs font moins de 10 contributions au total mais ce sont les plus précieux car ils corrigent ce qu'ils reconnaissent comme une erreur (le terrain, toujours le terrain). Alors que la quasi totalité de nos adresses proviennent du cadastre et qu'on y connait un taux d'erreur non négligeable. Faut-il rappeler que l'édition automatique de données OSM doit suivre certaines règles ([1]). Je sais que certains passent déjà outre cette règle et ont déjà massivement modifier les addr en relations (je ne suis pas idiot non plus). Mais j'ai laissé faire tant que c'était des initiatives personnelles. Je pourrais moi aussi faire un script (ou un plugin) qui permettrait ces changements dans le sens inverse (beaucoup plus simple à faire dans ce sens). Ca serait dommage d'en arriver là. Ou même d'en passer par le DWG car j'ai toujours estimé que nous étions assez grands pour nous mettre d'accord tous seuls. Pieren [1] http://wiki.openstreetmap.org/wiki/Mechanical_Edit_Policy ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] création semi automatique d'associed street
Le 19/11/2014 11:49, Pieren a écrit : 2014-11-19 11:38 GMT+01:00 Frédéric Rodrigo fred.rodr...@gmail.com: J'ai fait un script pour ça. Je me demande si ça ne faudrait pas le coup d'en faire un service web sur une commune (id de relation). Attention, Je suis contre un tel changement automatisé. Il faudrait qu'il y a un consensus d'abord sur ce sujet. Et je pense qu'il reste trop de problèmes avec la relation associatedStreet qui est aussi critiquée dans d'autres pays. Denis a raison de pointer ses avantages mais il y a aussi des inconvénients majeurs comme la complexité accrue de modifier ces données par des nouveaux arrivants (esayez de déplacer un numéro d'un bâtiment vers un autre ou l'attacher à une autre rue avec iD pour comprendre). L'immense majorité des contributeurs font moins de 10 contributions au total mais ce sont les plus précieux car ils corrigent ce qu'ils reconnaissent comme une erreur (le terrain, toujours le terrain). Alors que la quasi totalité de nos adresses proviennent du cadastre et qu'on y connait un taux d'erreur non négligeable. Faut-il rappeler que l'édition automatique de données OSM doit suivre certaines règles ([1]). Je sais que certains passent déjà outre cette règle et ont déjà massivement modifier les addr en relations (je ne suis pas idiot non plus). Mais j'ai laissé faire tant que c'était des initiatives personnelles. Je pourrais moi aussi faire un script (ou un plugin) qui permettrait ces changements dans le sens inverse (beaucoup plus simple à faire dans ce sens). Ca serait dommage d'en arriver là. Ou même d'en passer par le DWG car j'ai toujours estimé que nous étions assez grands pour nous mettre d'accord tous seuls. Je parlais juste de générer les relations hors OSM, pour intégration à la main, pour ceux qui souhaitent le faire. Pas de le faire automatiquement et encore moins en masse dans OSM. Je fais bien évidement parti des relationnisites. Mais il me semble que la question n'est pas ici pour ou contre. Frédéric. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base d’adresse : union de raison entre l’IGN et OpenStreetMap
Ronan Morin wrote aucune donnée insérée directement dans OSM ne se retrouvera dans la BAN C'est en effet ce que je comprends aussi. Ce schéma le clarifie assez bien: OSM n'est pas à coté de l'IGN et la poste mais à part (car licence ODBL qui empêcherait la revente en non libre donc, pas de flux OSM-BAN). Et je vois peut être le mal partout et/ou je n'ai pas assez bien suivi toute cette histoire, mais je vois que dans la communication, et ce schéma en particulier, est bien laissé de coté (comprendre: non représenté) le fait que la contribution à OSM par citoyen/entreprises/communes en direct reste possible. Il n'y a pas de flèche qui passe outre le portail adresse.gouv.fr ce qui laisse entendre, comme j'ai pu le lire ici même dans ce fil de discussion, que les actuels contributeurs d'openstreetmap et les futurs seront vivement conseillés, voire se conseillerons entre eux, de passer par portail adresse.gouv.fr car plus simple, pas de double saisie et pot commun. La flèche qui passe par le portail pour aller à OSM représente peut-être ça, flèche qui me semble un non sens dans la réalité puisque OSM se placera après l'export de la BAN en ODBL et non après le portail adresse.gouv.fr qui ne permettra pas la saisie direct dans osm (doubons, API non compatibles, users, etc.) Ronan Morin wrote J'avoue ne pas bien voir l'interet de l'état/IGN/La Poste de s'associer avec nous alors qu'on ne leur apportera pas nos données J'ai moi aussi du mal à comprendre cela. Et comme avec toute peur, tout ce que je ne comprend pas m'effrait. Est-ce juste pour faire bien sur la photo ? comme dit pieren ? C'est à dire pour bien indiquer que openstreetmap , défenseur des licences libres est bien d'accord avec ce projet. Mais cela veut il dire dire qu'osm doit recommander aux contributeurs de passer par le portail plutôt que par josm/id ? Contribuer par le portail, malgré toute la louabilité de la mise en pot commun ne doit pas faire perdre de vue, si j'ai bien compris, que ces contributions renonceront au partage à l'identique puisque distribuer en double licence implique aussi de distribuer en pas libre. Note de fin positive: Pouvoir disposer des données poste/ign en odbl est une excellente nouvelle qu'il ne faut surtout pas négliger, bravo à tout ce travail accompli. Note de fin prudente: je m'abstiendrais, en attente d'une lecture approfondie des conditions de contributions sur le portail du gouvernement, de recommander aux contributeurs actuels d'osm de l'utiliser plutôt qu'une contribution direct, et ce, quelles qu'en soient les contraintes techniques de dédoublonnement. -- sly -- View this message in context: http://gis.19327.n5.nabble.com/Base-d-adresse-union-de-raison-entre-l-IGN-et-OpenStreetMap-tp5824479p5824876.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base d’adresse : union de raison entre l’IGN et OpenStreetMap
@Ronan Morin*La licence d'OSM ne permet pas aux partenaires fondateurs de revendre sans partage les données d'OSM donc ils devront faire sans.* Humm oui mais! Ils vendront leurs produits et les données OSM manquantes seront moulinées dans un produit complémentaire sous licence OSM comme un produit cadeauxavec la licence proposé par OSM Je pense que ça c'est pas incompatible. ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] BANO-FANTOIR : Terrasse vs Traverse à Marseille
Ces problèmes de Terrasses et Traverses sont dues à des dizaines d'années d'errances, notamment liées à la norme postale qui si vous la lisez bien ne norme rien du tout...Comment le pourrait-elle d'ailleurs compte tenu des contraintes drastiques qu'elle s'impose (longueur restreinte des champs texte). En soit ce n'est pas grave puisque en soit une norme n'est pas un référentiel. Les problèmes sont apparus lorsque les référentiels ou apparentés ont voulu eux-même remplir cette norme postale... L'idée même d'utiliser des abréviations au lieu de noms en clairs est l'une des pires catastrophes qui puisse les affecter. Et à ma connaissance (RGE, Fantoir, RIL Insee) pour ceux que je connais, ont tous ce travers. Par rapport à ces référentiels OSM et ses produits dérivés (BANO) auront à terme une réelle supériorité. Le Mercredi 19 novembre 2014 12h01, Christian Quest cqu...@openstreetmap.fr a écrit : Le 19 novembre 2014 11:08, Charles Nepote char...@nepote.org a écrit : Merci Vincent. Oui c'est le long terme qui m'intéresse. Dégommer du rouge n'a pas de sens car c'est reculer pour mieux sauter dans ce cas. Il y a un moment il faudra un feedback aux agents qui complètent le FANTOIR et il nous faut donc garder la mémoire de la divergence. En attendant la mise en oeuvre de ton excellente proposition (que j'avais loupée) je préfère ne rien rapprocher du tout et laisser les avertissements. Vous avez déjà des contacts avec la DGFip pour savoir comment ils bossent sur ces données (comment il les collectent, comment il les corrigent) ? Je peux me renseigner via Etalab mais comme Christian est déjà dans la place je suppose qu'il a toute latitude aussi ;-) Maintenant qu'on a avancé avec l'IGN et La Poste, je vais retourner voir mes voisins de bureau de la DGFiP (étage au dessus, au bout du couloir) ;) Mieux comprendre le FANTOIR, sa constitution, voir comment on peut créer un vrai lien avec la BAN... voilà les enjeux futurs. Je pense que c'est très important de documenter un peu ce genre de cas : les cas de co-production / co-correction entre acteurs publics et communautés pourraient se multiplier au bénéfice de tous. Il faut des exemples solides pour convaincre plus d'acteurs. Rajouter les ref:FR:FANTOIR permet aux scripts de faire les rapprochements et aussi de détecter les différences et donc de les remonter comme telles. J'ai par exemple remonté près d'un millier de planches cadastrales raster à la projection incorrecte à la DGFiP avec un grand merci de leur part. Je pense que pour FANTOIR une remise au propre ne pourra pas faire de mal. Le coût de la non qualité est élevé ! -- Christian Quest - OpenStreetMap France ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base d’adresse : union de raison entre l’IGN et OpenStreetMap
Le 19/11/2014 17:47, Jérôme Seigneuret a écrit : / / @Ronan Morin /La licence d'OSM ne permet pas aux partenaires fondateurs de revendre sans partage les données d'OSM donc ils devront faire sans./ Humm oui mais! Ils vendront leurs produits et les données OSM manquantes seront moulinées dans un produit complémentaire sous licence OSM comme un produit cadeauxavec la licence proposé par OSM Je pense que ça c'est pas incompatible. Mais le cadeau reste sous la même licence. Les clients seront donc contraints, et ne seront pas dupes. -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [vidéo] Charting culture
Tu as regardé le générique à la fin ? Le 19 novembre 2014 12:00, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le mardi 18 novembre 2014 23:59:59 Philippe Verdy a écrit : Une vidéo avec un usage artistique et didactique des données OSM pour visualiser les migrations au cours des siècles et des continents. Au cas où vous l'auriez manquée. Jolie vidéo. Cependant, je ne saisis pas le rapport avec OSM. Un indice ? -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Base d’adresse : union de raison entre l’IGN et OpenStreetMap
Si on pense aux applications qui ont besoin de la fraicheur des données et plus de couverrture du terrain (malgré une marge d'erreur possible) je pense qu'il y a moyen de les satisfaire. Pour ces besoins, où il est acceptable d'avoir une marge d'erreur (qui peut s'évaluer par l'expérience et se comparer aux taux d'erreurs et aux risques liés aux retards si on ne dispose pas de ces données complémentaires) on aura des clients favorables à cela, à commencer par les services en charge de l'urgence et du secours aux personnes, ou les services d'investigation (sécurité civile, pompiers, police-secours, et services d'enquête judiciaire) qui tentent d'utiliser toute source disponible d'information et asument eux-même les vérifications nécessaires (et maintiennent aussi des fichiers complémentaires d'annotations prises sur le terrain et de leurs propres expériences). OSM est une bonne source grâce à ses nombreux contributeurs disséminés qui relèvent foule de détails absents des fichiers officiels. Les mêmes services n'ont par ailleurs aucun problème à utiliser aussi des données trouvées dans des services propriétaires et ils utilisent Google comme tout le monde. Ils ne se contentent pas des données officielles même si elles offrent un cadre général de base rassurant limitant l'étendue des dégats possibles en utilisant d'autres sources (libres ou non). On est dans le cadre non pas d'établir des adresses officielles et associées à des données nominatives à valeur légale ou contractuelle, mais dans celui de la recherche sur tout ce qui ne se trouve pas dans les données officielles (parce que la loi ne prévoit pas d'obligation à tout le monde, personne physique ou morale, de déclarer ces données ou les officialiser ou les maintenir à jour en permanence; la loi prévoir bien des déclarations obligatoires pour les questions fiscales, mais pas en permanence et ces déclarations sont confidentielles et partagées de façon limitées entre les services publics). Dans le monde de la prospection commerciale ou la recherche statistique, un taux de marge faible mais mesurable par sondage, est tout à fait acceptable et économiquement viable. On a beaucoup plus à gagner qu'à perdre en acceptant d'utiliser des données dont on sait qu'elles ont des incertitudes mesurables et mesurées. Bref pour bien vendre nos données OSM, on aurait à gagner si on faisait des sondages représentatifs de l'état de nos données, et plus on aura d'analyses sur la qualité de nos données mieux ce sera : c'est d'ailleurs ces outils qui sont à la base du crédit apporté aux données officielles (qui comme les autres ne prétendent pas à l'exhaustivité partout et à tout moment mais font l'objet de mesures qualitatives et d'un suivi en continu, mais aussi avec du personnel et des moyens dédiés à ça, ce qui a un coût et freine encore les ardeurs à rendre tout ce travail sous forme de données entièrement libres et utilisables sans aucun effort ni apport par des acteurs économiques). Ce qui effraie les administrations c'est le mot libre qu'elles interprètent comme étant sans condition de retour. Pourtant le partage à l'identique s'impose aussi aux données dérivées, ce qui permet un retour d'information, même s'il est plus limité que les données libres fournies d'origine. Pourtant c'est en libérant plus de données qu'on permet à plus d'intitiatives innovantes d'apparaitre, et on voit que si elles utilisent des données libres, elles ont aussi un intérêt à les soutenir aussi en y contribuant et en aidant aussi ceux qui ont fait le travail avant eux et qui ont aussi une expérience précieuse. S'enferme dans un modèle propriétaire c'est commencer à y accumuler des coûts de maintenance et se fermer la porte à des aides extérieures (qui auront du mal à accepter elles aussi d'aider celui qui veut ensuite s'approprier les données dans des licences restrictives. Le libre est rentable il permet d'investir plus là où c'est nécessaire et où il n'y a pas encore de collaboration sérieuse disponible (une chose que Microsoft n'a toujours pas compris et qu'il commence à payer cher maintenant, mais Apple ne sera bientôt pas en reste; Google devrait aussi se méfier de la façon dont il gère Android, même si ce ce point de vue là au moins il est disponible dans deux licences; Samsung en revanche se comporte très mal et ne donne rien en retour). Et comment ne pas oublier le consortium MPEG LA qui refuse de lâcher le moindre pouce en libérant des tas de brevets de base, mais s'est engagé dans des batailles judiciaires contre un acteur du libre (VideoLAN). Le monde du libre a aussi été faussement accusé de promouvoir le piratage (notamment dans la musique ou le cinéma), ce qui est faux. Le plus gros du piratage vient d'une attaque en règle par détournement des catalogues par de puisssants acteurs commerciaux (à commencer par Apple, mais les opérateurs télécom ne sont pas en reste et ne se sont pas privés de se pirater entre eux, massivement, et sans reverser les parts dues aux ayant-droits
Re: [Talk-GB] Allegedly named motorways
I wonder how motorway services get their post delivered. If they have a
letter box, must they have a postcode and therefore a street address? I
know in NL motorways sometimes have official names for this purpose, to
fulfill referential integrity requirements. Typically it is something
obvious like M1 Northbound but it is in the official street name
register.
Colin
On 2014-11-19 08:50, Andy Robinson wrote:
When I put the M6Toll in I named it originally Midlands Expressway as that's
the name it had right through till the DfT/Secretary of State decided it
should be branded M6Toll.
Plenty of similar examples, such as the Preston Bypass which formed an early
part of the M6.
Where these names are no longer used on the ground then a former_name tag
would be appropriate.
Cheers
Andy
FROM: Colin Smale [mailto:colin.sm...@xs4all.nl]
SENT: 19 November 2014 07:21
TO: talk-gb@openstreetmap.org
SUBJECT: Re: [Talk-GB] Allegedly named motorways
Most of the names in the South East seem to have been added by two
(prolific) specific mappers. Has anyone asked them about their source and
motivation? It would sound fair to consult them and hear them out.
Having said that, one of the top rules in my mkgmap[1] style is
highway=motorway {delete name;}...
Colin
[1] mkgmap produces Garmin satnav maps from OSM, in case anyone is wondering
On 2014-11-19 02:12, Andrew Black wrote:
There is some evidence of these names being used when the roads were built
eg
http://discovery.nationalarchives.gov.uk/details/r/C1459443 [2]
South Wales Motorway (M4): Chiswick to Langley Special Road; contract for
Boston Manor Bridge
But I don't think they are useful now.
On 18 Nov 2014 23:49, Steve Doerr doerr.step...@gmail.com wrote:
On 18/11/2014 23:06, SomeoneElse wrote:
There's a similar issue a bit further out, the Slough-Maidenhead By-Pass:
http://www.openstreetmap.org/way/81517663 [3]
http://ris.dev.openstreetmap.org/oslmusicalchairs/map?osl_id=18177 [4]
Again that sounds like a description; I've never seen that sign on the M4.
Slough By-Pass is used on OS maps from 1964 to 1975:
https://www.old-maps.co.uk/#/Map/498008/178760 [5]
--
Steve
---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com [6]
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb [1]
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb [1]
-
No virus found in this message.
Checked by AVG - www.avg.com [7]
Version: 2014.0.4765 / Virus Database: 4189/8590 - Release Date: 11/18/14
Links:
--
[1] https://lists.openstreetmap.org/listinfo/talk-gb
[2] http://discovery.nationalarchives.gov.uk/details/r/C1459443
[3] http://www.openstreetmap.org/way/81517663
[4] http://ris.dev.openstreetmap.org/oslmusicalchairs/map?osl_id=18177
[5] https://www.old-maps.co.uk/#/Map/498008/178760
[6] http://www.avast.com
[7] http://www.avg.com
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb
