Re: [OSM-legal-talk] [Talk-ca] Nouvelle licence de données ouvertes au Québec
Municipalities and government of Québec will adopt the CC BY 4.0 Diane Le 2014-02-21 07:04, Simon Poole a écrit : This is I believe a simple misunderstanding: le...@osmfoundation.org is the internal list of the LWG legal-talk@openstreetmap.org is the legal discussion mailing list open to the general public. On the matter at hand: as I write in the quoted mail, we are quite open to taking the results of a review of CC by 4.0 wrt compatibility with our contributor terms and the ODbL 1.0 in to account. Note, as I wrote in my mail, it is likely not worth doing for CC by-SA 4.0 as it is clear that a share alike licence will not be CT compatible. Simon Am 21.02.2014 12:12, schrieb Diane Mercier: Translation in english of the title : Municipalities and government of Québec (Canada) will adopt the CC BY 4.0 - Ref. : https://lists.openstreetmap.org/pipermail/talk-ca/2014-February/006069.html Dear Paul, I am sorry to contradict you, but please find attached copy of my conversation with Simon Poole and le...@osmfoundation.org against the CC 4.0 This conversation includes the response of Simon Poole. I also copy to the list of discussion legal-talk @ I reiterate. It is the responsibility of OSM Foundation to instruct his community of his CC 4.0 interpretation as it has done for the CC 2.0 and CC 3.0 And in my humble opinion, the tiles and the BD licenses should updates to CC 4.0 to reduce proliferation of license, etc. Regards, Note : See press releases http://donnees.ville.montreal.qc.ca/un-avantage-pour-les-citoyens-montreal-disposera-de-la-licence-ouverte-cc-4-une-premiere-au-canada-en-matieres-de-donnees-ouvertes/ http://www.ville.quebec.qc.ca/actualites/fiche_autres_actualites.aspx?id=13362 --- Dre Diane Mercier @MTL_DO | donnees.ville.montreal.qc.ca @okfnca | ca.okfn.org @_FACiL | facil.qc.ca @carnetsDM | dianemercier.com http://about.me/dianemercier http://vizualize.me/oKvvtBkJXK?r=oKvvtBkJXK Webographie du libre : https://www.zotero.org/dmercier/items/order/dateModified/sort/desc « Pas de données ouvertes, sans logiciel libre ni formats ouverts » Le 2014-02-21 01:42, Paul Norman a écrit : No one has raised the issue on legal-talk@ since CC 4 was released. *From:*Pierre Béland [mailto:pierz...@yahoo.fr] *Sent:* Thursday, February 20, 2014 8:43 AM *To:* diane.merc...@gmail.com; Talk-ca (OSM) *Subject:* Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec Merci Diane pour ces infos. Ce sont là de bonnes nouvelles pour la communauté OSM du Québec. Espérons que nous aurons rapidement des nouvelles de la part du comité légal de OSM là-dessus. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-ca] Nouvelle licence de données ouvertes au Québec
On Fri, Feb 21, 2014 at 10:26 AM, Pierre Béland pierz...@yahoo.fr wrote: Eh good news for OSM-Quebec community then. Let's wait for the official confirmation of the exact license adopted. I disagree. Any license drafted or adopted by a Canadian government, other than a no-restrictions, equivalent-to-Public-Domain-license, like ODC-PDDL, will require a waiver or clarification from the municipality (or province / territory, or feds) that attribution as provided by OpenStreetMap (wiki page, probably listed on a sub-page) meets their interpretation of attribution. So, adoption of CC-anything-but-0 is bad for local OSM communities. It would likely work out okay in the end for those local OpenStreetMap communities. To my knowledge, every municipality approached for such a waiver has granted it. To OpenStreetMap Foundation at least. For the Open Data community at large, and for the municipality / governement itself, adoption of any restricting license is a disaster. For one thing, not every potential open project will be on the radar of a municipality in the same way that OpenStreetMap is. Too bad for that potential Open Data Project. Perhaps they'll get the waiver they need, perhaps they won't. Again, any government open data publication in Canada must be licensed ODC-PDDL, or else it is a not-open-enough-closed-data-failure. Another sign of bizarre, Open-blindness. I've had government open data representatives say to me, the equivalent of, So what if the license says something complicated. It's open, just do what you want. We won't go after anybody who breaks the license. We just need to be able to shut down anybody who embarrasses us. Ahem. No. 0) If you plan to grant wavers and exemptions anyway, why not just use an unrestricted license? Oh, did you want to only grant exemptions for projects / persons of whom you approve? That doesn't sound very open. 1) If you don't plan to enforce your license terms, why select (or worse, why draft) a license with restrictions? Select ODC-PDDL instead. 2) If you want developers to work with your data, do you want developers who care enough to read, understand and follow your terms, or not? Because your license with restrictions just cut out a portion of those developers. You can still keep the developers that don't read licenses, or don't care about the terms. Congratulations. 3) What, you want to shut down a use of the data that embarrasses you? No. It doesn't work that way. If Open Data can be shown to expose that your mayor is a pathologically lying, bullying, drug addict with possible links to organized crime, you don't get to shut down the analysis just because your boss finds it embarrassing. (It's just a hypothetical example) 4) If you really do plan to grant a waiver or exemption to every project / user who asks for it, shouldn't you have selected an unrestricted Open Data License that didn't place the burden of that extra waiver step upon you (and each potential user) ? ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-ca] Nouvelle licence de données ouvertes au Québec
On Fri, Feb 21, 2014 at 1:14 PM, Richard Weait rich...@weait.com wrote: On Fri, Feb 21, 2014 at 10:26 AM, Pierre Béland pierz...@yahoo.fr wrote: Eh good news for OSM-Quebec community then. Let's wait for the official confirmation of the exact license adopted. I disagree. Any license drafted or adopted by a Canadian government, other than a no-restrictions, equivalent-to-Public-Domain-license, like ODC-PDDL, will require a waiver or clarification from the municipality (or province / territory, or feds) that attribution as provided by OpenStreetMap (wiki page, probably listed on a sub-page) meets their interpretation of attribution. So, adoption of CC-anything-but-0 is bad for local OSM communities. It would likely work out okay in the end for those local OpenStreetMap communities. To my knowledge, every municipality approached for such a waiver has granted it. To OpenStreetMap Foundation at least. For the Open Data community at large, and for the municipality / governement itself, adoption of any restricting license is a disaster. For one thing, not every potential open project will be on the radar of a municipality in the same way that OpenStreetMap is. Too bad for that potential Open Data Project. Perhaps they'll get the waiver they need, perhaps they won't. Again, any government open data publication in Canada must be licensed ODC-PDDL, or else it is a not-open-enough-closed-data-failure. I agree that all PSI ought be public domain, with ODC-PDDL or CC0 or some other public domain instrument, since the sane default isn't the default. But calling attribution-only terms a closed-data-failure (BTW, what does that make ODbL? Is OSM the only entity in the world that can use non public domain terms and not be a closed data fail?) seems over the top. Asking for a clarification that provided attribution is OK seems over the top too, at least for CC-BY, especially CC-BY-4.0, given You may satisfy the [attribution conditions] in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. If every attribution needs to be clarified with the licensor to determine if it is OK, then attribution licenses truly are a fail. But that practice is certainly not the intent of such licenses. IMO, IANAL, etc etc. The remainder below is most excellent. Another sign of bizarre, Open-blindness. I've had government open data representatives say to me, the equivalent of, So what if the license says something complicated. It's open, just do what you want. We won't go after anybody who breaks the license. We just need to be able to shut down anybody who embarrasses us. Ahem. No. 0) If you plan to grant wavers and exemptions anyway, why not just use an unrestricted license? Oh, did you want to only grant exemptions for projects / persons of whom you approve? That doesn't sound very open. 1) If you don't plan to enforce your license terms, why select (or worse, why draft) a license with restrictions? Select ODC-PDDL instead. 2) If you want developers to work with your data, do you want developers who care enough to read, understand and follow your terms, or not? Because your license with restrictions just cut out a portion of those developers. You can still keep the developers that don't read licenses, or don't care about the terms. Congratulations. 3) What, you want to shut down a use of the data that embarrasses you? No. It doesn't work that way. If Open Data can be shown to expose that your mayor is a pathologically lying, bullying, drug addict with possible links to organized crime, you don't get to shut down the analysis just because your boss finds it embarrassing. (It's just a hypothetical example) 4) If you really do plan to grant a waiver or exemption to every project / user who asks for it, shouldn't you have selected an unrestricted Open Data License that didn't place the burden of that extra waiver step upon you (and each potential user) ? ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-ca] Nouvelle licence de données ouvertes au Québec
On Fri, Feb 21, 2014 at 4:58 PM, Mike Linksvayer m...@gondwanaland.com wrote: On Fri, Feb 21, 2014 at 1:14 PM, Richard Weait rich...@weait.com wrote: [ ... ] Again, any government open data publication in Canada must be licensed ODC-PDDL, or else it is a not-open-enough-closed-data-failure. I agree that all PSI ought be public domain, with ODC-PDDL or CC0 or some other public domain instrument, since the sane default isn't the default. But calling attribution-only terms a closed-data-failure (BTW, what does that make ODbL? Is OSM the only entity in the world that can use non public domain terms and not be a closed data fail?) seems over the top. Government Open Data, and OpenStreetMap Open Data are different kettles of fish. And so different goal posts apply to each. Government Open Data is more-correctly Citizen Open Data. For that same government to attempt to then restrict the use of that data by the citizens who own it, and pay for it (and, in fact who own the government :-) ) well, that's the part that is over the top. :-) OpenStreetMap data is created by the OpenStreetMap contributors. Where those same contributors decide to place themselves, as a group, along the Open Spectrum has nothing to do with government, er, *strikeover* citizen data. It might also be a a long-standing and heated discussion amongst those same contributors. :-) Thanks, Mike. Cheers. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] [Talk-ca] Nouvelle licence de données ouvertes au Québec
CC BY 3.0 and earlier had onerous attribution requirements for data. I believe 4.0 fixes this. I don't think anyone has suggested contacting a data provider who's licensed under CC 4.0 licenses to clarify attribution. The issue with 3.0 attribution are not purely theoretical, there have been providers who have objected to how we have attribution and we've been unable to use their data. Sent from my iPad On Feb 21, 2014, at 1:58 PM, Mike Linksvayer m...@gondwanaland.com wrote: Asking for a clarification that provided attribution is OK seems over the top too, at least for CC-BY, especially CC-BY-4.0, given You may satisfy the [attribution conditions] in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. If every attribution needs to be clarified with the licensor to determine if it is OK, then attribution licenses truly are a fail. But that practice is certainly not the intent of such licenses. IMO, IANAL, etc etc. ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] Not attaching polygons to roads
Hi Frederik, I agree - but only in parts. If the other mapper shares nodes between the road and the field, and the field is surrounded (and tagged as such) with a fence, so the field is e.g. landuse=farmland, barrier=fence, then this is an error in the map as it states that the fence is in the middle of the street or it's not possible to decide where relative to the street the fence is. In this case dividing them without adding new features IMHO is fixing a bug in the map data, and joining a fence with a way along several nodes in a line is an error - if not vandalism when doing it repeatingly while igoring personal messages according to the same issue. Nevertheless of course you're right: Changing the way of mapping without adding value/improvement (!) is not okay. regards Peter Am 20.02.2014 23:40, schrieb Frederik Ramm: Hi, On 20.02.2014 23:04, Dave F. wrote: There's a general consensus that attaching polygons to ways that represent roads was a bad idea. Not really. There is not a consensus but a ceasefire. Everyone is free to map this as they like, and to change it if there's a need - e.g. someone else has connected the field to the road, now you want to map the fence, so you need to split it apart. That's ok. Similarly, someone re-doing the whole area from better imagery or whatever has every right to map as he pleases - if they thing they can be more efficient by joining boundaries, more power to them. What is *not* ok is one person cleaning up after the other without actually adding any other improvement. I.e. if the other guy has connected the fields and the roads and you have been *only* pulling them apart without contributing anything else to the area in question, then you should have let them be; on the other hand, if the other guy has merged fields and roads that previously were separate, then they shouldn't have done that. This whole question is essentially a matter of taste, and you are allowed to map according to your taste, and discouraged from enforcing your taste for others. Bye Frederik ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Potlatch deprecation
On Thu, Feb 20, 2014 at 9:51 PM, Fernando Trebien fernando.treb...@gmail.com wrote: When I cannot use JOSM for any reason, I'm still using P2 to retrieve the history of an object and P1 is the only one I know which is able to find and display deleted ways. Two helpful features for data maintenance. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On Fri, Feb 21, 2014 at 9:19 AM, Peter Wendorff wendo...@uni-paderborn.de wrote: If the other mapper shares nodes between the road and the field, and the field is surrounded (and tagged as such) with a fence, so the field is e.g. landuse=farmland, barrier=fence, then this is an error in the map as it states that the fence is in the middle of the street or it's not possible to decide where relative to the street the fence is. That's maybe an original issue with landuse polygons. Once you go to this level of details (fence), the border line between landuse's is not a clear sharp line. As suggested by Shaun, once you add fences and detach the farmland, you should also fill the gap created and make the landuse=highway. People detaching landuse from road lines are most of the time doing half of the job. Changing the way of mapping without adding value/improvement (!) is not okay. At least, new contributions shouldn't decrease the quality. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
Am 21.02.2014 10:44, schrieb Pieren: On Fri, Feb 21, 2014 at 9:19 AM, Peter Wendorff wendo...@uni-paderborn.de wrote: If the other mapper shares nodes between the road and the field, and the field is surrounded (and tagged as such) with a fence, so the field is e.g. landuse=farmland, barrier=fence, then this is an error in the map as it states that the fence is in the middle of the street or it's not possible to decide where relative to the street the fence is. That's maybe an original issue with landuse polygons. Once you go to this level of details (fence), the border line between landuse's is not a clear sharp line. As suggested by Shaun, once you add fences and detach the farmland, you should also fill the gap created and make the landuse=highway. People detaching landuse from road lines are most of the time doing half of the job. I may agree here, but in OSM I think doing half the job is better than mapping wrong stuff. OSM is a database, not (only) a map, and there isn't something like once you go to this level of details. Let's extend the example slightly: Let there be from left to right a field, a fence, a street, a hedge and a park. Let the fence in addition be not around the field, but only at the borderline to the street (so it's not a tag on the field polygon any more, while the hedge surrounds the park (where entrances are mapped as such on nodes). Now Mapper A starts mapping with low detail from aerial imagery: he draws a polygon for the field, another polygon for the park, and a way for the street, and tags it as landuse, leisure and highway respectively. He omits the fence and the wall. As you said, this is perfectly valid (although it's a little bit ugly to detect that it's not a park directly beside a field, because you would have to create the corresponding buffer for the highway for that; it's not possible to calculate the exact area of the field, as we're wrong by 6 meters for half the street width.) Mapper B is on the ground a while later and recognizes that there's a fence and a hedge. Adding the hedge seems to be easy: she adds the barrier=hedge-tag to the park. Adding the fence is easy, too, but how to do this? She definitively has to draw a new way as there's no geometry matching the fence. But where? By the rules applied in this scenario up to now it would be fine to add the fence as a way sharing the nodes that are already shared by park, highway, hedge and field. But what happens when doing this? There is a set of nodes that is hedge and fence. Might be possible: I would interpret this as a fence inside a hedge, which is possible and well known in the wild. But what's the matter with the highway? well... then the highway must be in between the hedge with fence and the field with the wall... Well - wait... it could be a fence on top of a wall instead - now the fence is on the other side of the way... Or it could be a fence in the middle of the street - strange... In fact the map says, there's a fence, a wall and a street's center line at the same position. Independent of the level of detail I would assume for the application this is simply wrong, and keep in mind: the coordinates are in a level of detail of 10cm or better, with no way to see what level of detail is ment by any particular mapper with any particular object. Let's invite Mapper C. He - as you suggests would like to clean up the mess produced by A and B, and it's going to be hard work. Without being on the ground it seems to be possible to detach the park with the hedge from the way on the first glance, but damn it - what to do with the wall? Isn't it wrong to detatch the fence if it might be possible that in fact the fence is on top of the wall? If so it would be necessary to detatch the fence, too and let fence and wall share nodes. If not, this would create a different but completely wrong situation. So nothing can be made better without being on the ground. C decides to take his bike and and ride a whole day to that place as unfortunately there's no active mapper any more (A and B stopped mapping months ago). Now he knows what's the situation on the ground and has to detatch lines from each other, stumbling over several ugly issues in the osm editor software available: - How to select one of many ways sharing the same nodes? - how to minimize breaking object history - but remapping everything would be more simple to do. If A and B would have drawn lines in parallel, leaving a gap for the highway in between it would be much easier. Changing the way of mapping without adding value/improvement (!) is not okay. At least, new contributions shouldn't decrease the quality. +10, but filling the map without empty gaps isn't a good measurement of quality. regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM for Developers Presentation
On Fri, Feb 21, 2014 at 02:53:24PM +0700, Kate Chapman wrote: I'm giving a talk this weekend at the Jakarta Python meet-up. I was wondering if anyone has a good Intro to OSM for Developers talk. Hi, Kate. I gave a 20 minute OpenStreetMap for Perl Developers talk recently. I didn't have time to cover everything I wanted, but I gave an overview of how OSM works from a developer's perspective and described some of the interesting APIs a developer might want to call: http://act.yapc.eu/lpw2013/talk/5152 You can watch my talk here: http://www.youtube.com/watch?v=GrS8mXVW2lw Tom ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 20/02/2014 22:40, Frederik Ramm wrote: Hi, On 20.02.2014 23:04, Dave F. wrote: There's a general consensus that attaching polygons to ways that represent roads was a bad idea. Not really. There is not a consensus but a ceasefire. Everyone is free to map this as they like, and to change it if there's a need - e.g. someone else has connected the field to the road, now you want to map the fence, so you need to split it apart. That's ok. Similarly, someone re-doing the whole area from better imagery or whatever has every right to map as he pleases - if they thing they can be more efficient by joining boundaries, more power to them. What is *not* ok is one person cleaning up after the other without actually adding any other improvement. I.e. if the other guy has connected the fields and the roads and you have been *only* pulling them apart without contributing anything else to the area in question, then you should have let them be; This bit I disagree with. Field or cemetery boundaries etc don't go to the centreline of the road. Pulling them apart placing them where they are in reality is improving OSM by making it more accurate. Even if not boundary is added. on the other hand, if the other guy has merged fields and roads that previously were separate, then they shouldn't have done that. This whole question is essentially a matter of taste, and you are allowed to map according to your taste, and discouraged from enforcing your taste for others. Disagree again, I'm afraid. Improving OSM's accuracy supersedes taste. To clarify I'm only referring to instances of polygons attached to roads. Differing landuse areas abutting each other, fields to residential, for example, is OK. However on saying that it does often make selecting a polygon difficult if attached on all sides. Cheers Dave F. --- 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
Re: [OSM-talk] Not attaching polygons to roads
Agreed. If you have a property that is 20m x 100m = 2,000m², you could be adding, for example, 5m x 100m = 500m² to it by attaching it to the road, resulting in 2500m², i.e., a *25% increase in area*. A really big accuracy error, in my opinion. On Fri, Feb 21, 2014 at 8:41 AM, Dave F. dave...@madasafish.com wrote: On 20/02/2014 22:40, Frederik Ramm wrote: Hi, On 20.02.2014 23:04, Dave F. wrote: There's a general consensus that attaching polygons to ways that represent roads was a bad idea. Not really. There is not a consensus but a ceasefire. Everyone is free to map this as they like, and to change it if there's a need - e.g. someone else has connected the field to the road, now you want to map the fence, so you need to split it apart. That's ok. Similarly, someone re-doing the whole area from better imagery or whatever has every right to map as he pleases - if they thing they can be more efficient by joining boundaries, more power to them. What is *not* ok is one person cleaning up after the other without actually adding any other improvement. I.e. if the other guy has connected the fields and the roads and you have been *only* pulling them apart without contributing anything else to the area in question, then you should have let them be; This bit I disagree with. Field or cemetery boundaries etc don't go to the centreline of the road. Pulling them apart placing them where they are in reality is improving OSM by making it more accurate. Even if not boundary is added. on the other hand, if the other guy has merged fields and roads that previously were separate, then they shouldn't have done that. This whole question is essentially a matter of taste, and you are allowed to map according to your taste, and discouraged from enforcing your taste for others. Disagree again, I'm afraid. Improving OSM's accuracy supersedes taste. To clarify I'm only referring to instances of polygons attached to roads. Differing landuse areas abutting each other, fields to residential, for example, is OK. However on saying that it does often make selecting a polygon difficult if attached on all sides. Cheers Dave F. --- 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 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Potlatch deprecation
Indeed that's a nice feature I've known to be unique to Potlatch. Anyway, I might have been misinformed about Potlatch being deprecated (if it was, I was trying to ask people to hurry), but since it's not, I'm not asking for it either. Instead, the issues I've pointed out (http://forum.openstreetmap.org/viewtopic.php?id=24381) need attention. They've been happening since I started in OSM over one year ago, and it's been hard lately to keep up with the growing introduction of these errors as the Brazilian community has grown a lot. Knowing that countries like the UK, Germany and Russia have a lot more edits, I'm actually puzzled: how do they manage these problems there? I only revert someone else's changeset as a last resort (when the user has really misunderstood almost everything), and these mistakes I've talked about are often part of a larger edit (where the idea of reverting does is problematic, as there's useful information in it). I know many tools (JOSM's validator, Geofabrik, KeepRight!, etc.) are able to detect problems, but none helps you quickly recover the previous state of a single broken relation along with the previous version of its members while still being consistent with the new data (some of the new ways might need to be deleted, some of their tags may need to be imported to the old ways, etc.). So relations can be broken in seconds, then people who are concerned about data integrity (particularly about the integrity of what they've previously mapped) end up spending many minutes every time such a mistake happens. And for that reason, I've been recommending against using streets as boundaries for suburbs - instead, drawing an independent way for that (which is inaccurate and should not be necessary). I've also been recommending people to use multipolygons only when extremely necessary. I shouldn't be recommending neither of the two, but I see no other way to prevent what I've pointed out. On Fri, Feb 21, 2014 at 6:10 AM, Pieren pier...@gmail.com wrote: On Thu, Feb 20, 2014 at 9:51 PM, Fernando Trebien fernando.treb...@gmail.com wrote: When I cannot use JOSM for any reason, I'm still using P2 to retrieve the history of an object and P1 is the only one I know which is able to find and display deleted ways. Two helpful features for data maintenance. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
Dave F. wrote: This whole question is essentially a matter of taste, and you are allowed to map according to your taste, and discouraged from enforcing your taste for others. Disagree again, I'm afraid. Improving OSM's accuracy supersedes taste. To clarify I'm only referring to instances of polygons attached to roads. Differing landuse areas abutting each other, fields to residential, for example, is OK. However on saying that it does often make selecting a polygon difficult if attached on all sides. A lot of my own time when I do get to run some data in is pulling apart these very 'matter of taste' mapping choices. The tools make it all to easy to 'default' to a macro mapping view, which may be fine in areas where there is no data, but where we are now adding the fine detail, such as dropping in the footpath down the side of a road, having to pull apart the field boundary first reduces productivity? This is an area where the simplistic approach to polygons does not help. If I need to add the dry stone wall to one side of the field and fences or hedges to the other boundaries then we end up with additional ways overlaying the base polygon, and which are then even more difficult to see and manage? It is about time we started to look at combining ways in the same way we currently do with nodes? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM for Developers Presentation
Hello Kate, I gave this talk at a British Computer Society meeting last year: http://www.free-map.org.uk/~nick/OSM_0313.odp Not hugely in-depth but might be of some use. Nick -Kate Chapman k...@maploser.com wrote: - To: osm talk@openstreetmap.org From: Kate Chapman k...@maploser.com Date: 21/02/2014 08:00AM Subject: [OSM-talk] OSM for Developers Presentation Hi All, I'm giving a talk this weekend at the Jakarta Python meet-up. I was wondering if anyone has a good Intro to OSM for Developers talk. I'm putting one together myself, but I'm looking to see what things others cover. Basically I want to give an overview of resources for developers, this isn't really a workshop just a 20 minute presentation. Thanks, -Kate ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM for Developers Presentation
Kate, I put together a little explanation of the rendering side of OSM a few years ago: http://www.slideshare.net/jones139/rendering-openstreetmap-data-using-mapnik . It might be out of date now though! Graham. On 21 February 2014 18:38, Nick Whitelegg nick.whitel...@solent.ac.ukwrote: Hello Kate, I gave this talk at a British Computer Society meeting last year: http://www.free-map.org.uk/~nick/OSM_0313.odp Not hugely in-depth but might be of some use. Nick -Kate Chapman k...@maploser.com wrote: - To: osm talk@openstreetmap.org From: Kate Chapman k...@maploser.com Date: 21/02/2014 08:00AM Subject: [OSM-talk] OSM for Developers Presentation Hi All, I'm giving a talk this weekend at the Jakarta Python meet-up. I was wondering if anyone has a good Intro to OSM for Developers talk. I'm putting one together myself, but I'm looking to see what things others cover. Basically I want to give an overview of resources for developers, this isn't really a workshop just a 20 minute presentation. Thanks, -Kate ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Graham Jones Hartlepool, UK. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On 21/02/2014, Dave F. dave...@madasafish.com wrote: On 20/02/2014 22:40, Frederik Ramm wrote: On 20.02.2014 23:04, Dave F. wrote: What is *not* ok is one person cleaning up after the other without actually adding any other improvement. In cases that can be likened to a change code indentation commit I agree, but... I.e. if the other guy has connected the fields and the roads and you have been *only* pulling them apart without contributing anything else to the area in question, then you should have let them be; This bit I disagree with. Field or cemetery boundaries etc don't go to the centreline of the road. Pulling them apart placing them where they are in reality is improving OSM by making it more accurate. Even if not boundary is added. That's the crux of it. Separating the area from the road *is* an improvement in itself (at least if you've got high-res imagery to place the polygon more precisely). If that changeset gets reverted to re-glue the area to the line (especially without engaging in conversation with the orther contributor), it's a step backward. This whole question is essentially a matter of taste, and you are allowed to map according to your taste, and discouraged from enforcing your taste for others. Disagree again, I'm afraid. Improving OSM's accuracy supersedes taste. I agree with the matter of taste argument insofar as I dont complain to mappers who initially glue areas to lines. It's just data that can be improved like any other, and if it tastes easyer to that mapper, it's fine. You really shouldn't force anybody to be more accurate than they care to be. But again, if a mapper reduces accuracynfor taste reasons, it's bad. If he ignores communication aboutnit, it's aggravating. There are many mapping alternatives that are a matter of taste or up for debate. But I do think that this particular issue is matematically clear-cut, it's basic geometry. See https://help.openstreetmap.org/questions/17501/when-mapping-polygons-surrounded-by-streets-should-they-share-nodes-or-be-traced-separately/17505 for another writeup of my views on the subject. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
There are many mapping alternatives that are a matter of taste or up for debate. But I do think that this particular issue is matematically clear-cut, it's basic geometry. See https://help.openstreetmap.org/questions/17501/when-mapping-polygons-surrounded-by-streets-should-they-share-nodes-or-be-traced-separately/17505 for another writeup of my views on the subject. What is good with the QA is that you can vote. -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
On Fri, Feb 21, 2014 at 1:29 PM, moltonel 3x Combo molto...@gmail.comwrote: I agree with the matter of taste argument insofar as I dont complain to mappers who initially glue areas to lines. It's just data that can be improved like any other, and if it tastes easyer to that mapper, it's fine. You really shouldn't force anybody to be more accurate than they care to be. I think it's important to consider that what we put into OSM is a model of the real world. Roads for example are generally not straight, yet we model them with line segments. A model. To say that the park occupies the space between these four streets is a very reasonable first approximation model. You can go pretty far with the model: the street has cycle tracks left right, the utilities are on poles overhead, the park edge is fenced. All the important data is present and can be conveniently rendered at any scale or with any emphasis. This is very flexible. Cartography rules often render road width not based on physical width, but logical width. The 25' wide highway at one edge of the park is more important than 30' wide residential street on the other three sides. The model handles this just fine: whatever width is not used by the road is used by the polygon. Nobody cares that the park just lost a little space, the map looks great and communicates clearly to the viewer. Flip to a cycling map, and the 30' bicycle-friendly street may be more important than the highway: it still renders fine. --- It's the micro-mapping that brings up hard to process situations. Imagine that same area micromapped: road centerline, cycle tracks, power poles, fence, hedge, imported legal property boundary of the park. To render that well for various needs you've got to start shoving and pushing element. To render the highway fat you need to push out the cycle track and fence lines. Should you also shove over the hedge or just bury it under the roadway? It's unclear what's best. Very often the actual legal boundary does not correspond to the landscaped boundary. The park may be landscaped right to the edge of the tarmac, but the highway department actually owns a wider swath of land. The fence might be within the legal boundary of the park, or outside it. Which one you map depends on your aim: the assessors office wants the legal boundary, the soccer team will play right to the edge of the fence regardless, they only care if the fence is permeable to soccer balls. --- There's no one solution here: in micromapped areas road centerlines are not enough. In many areas (I might hazard 99% of the surface of the planet), the *model* may serve the need better. I think that strong tool support for sharing nodes is good, appropriate, and a great for first efforts at mapping modelling an area. The node sharing is particularly useful for administrative and other areas that do in fact follow a road centerline by fact or convention. Just realize that there's disagreement on this point in part because of valid differences in scale, scope and aim. And that we model reality because models are often more useful than a direct representation. Any difficulty in editing is a tool issue. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Potlatch deprecation
I think all three major editors make it too easy to damage relations. And that starting to damage a relation (by a user) is a perfect teaching opportunity. The moment someone deletes part of a boundary relation, is the perfect teaching moment about boundary relations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Potlatch deprecation
It is not that easy to damage relations in JOSM. Sure, you can, but you get blocking warnings: once, when you change the relation indirectly (perhaps breaking it), and another (issued by JOSM's very comprehensive validator) by the time you attempt to upload your changes. Both warnings stop your work (always! there's no way to turn them off), make you read, ask you to decide how to handle the situation, and are quite informative: they tell you where you acted and what was the result. It sure is a bit low level, but that is good teaching. If you do not understand what you read, you can then go search for help. But if you get no warning (as in Potlatch), you don't even know you need to seek learning about relations. It is very hard to argue that someone can miss both warnings accidentally. Can the user damage the relations with JOSM? Sure. But the user has been warned twice and should know what he/she is doing. They may ignore the warnings if they do not know what they mean, but then you have a better point to later approach the user and tell him/her to be more careful and read more about relations. If you do that to Potlatch users, it is totally fair if they reply: How could I have known? You can't expect them to re-read all that is written everywhere on the UI at every change they perform on the map. Potlatch should call their attention to important things (such as unintentional data loss). Even experienced users may accidentally destroy relations in Potlatch because of a short moment of inattention. In JOSM, you're always reminded. On Fri, Feb 21, 2014 at 9:08 PM, Bryce Nesbitt bry...@obviously.com wrote: I think all three major editors make it too easy to damage relations. And that starting to damage a relation (by a user) is a perfect teaching opportunity. The moment someone deletes part of a boundary relation, is the perfect teaching moment about boundary relations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Importação da Funai
Aliás, gostaria de fazer como se faz para abrir um ticket para pedir que vias não pavimentadas fossem desenhadas de forma diferente. Em 21 de fevereiro de 2014 00:55, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-02-21 0:20 GMT-03:00 Augusto Stoffel arstof...@yahoo.com.br: Mesmo problema que as unidades de conservação: boundary=protected_area não renderiza. Isso é meio que mapear para o renderizador, mas é uma situação extrema: sem tomar alguma licença poética, não tem como fazer as terras indígenas aparecerem no mapa. (Além disso, como eu comentei, terras indígenas tem um forte caráter de conservação da natureza, embora o foco central seja a questão social/política.) Mas o correto é fazer com que o renderizador exiba isso (abrindo um ticket para isso) e não o contrário :-) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
gostaria de saber... Em 21 de fevereiro de 2014 08:01, Paulo Carvalho paulo.r.m.carva...@gmail.com escreveu: Aliás, gostaria de fazer como se faz para abrir um ticket para pedir que vias não pavimentadas fossem desenhadas de forma diferente. Em 21 de fevereiro de 2014 00:55, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-02-21 0:20 GMT-03:00 Augusto Stoffel arstof...@yahoo.com.br: Mesmo problema que as unidades de conservação: boundary=protected_area não renderiza. Isso é meio que mapear para o renderizador, mas é uma situação extrema: sem tomar alguma licença poética, não tem como fazer as terras indígenas aparecerem no mapa. (Além disso, como eu comentei, terras indígenas tem um forte caráter de conservação da natureza, embora o foco central seja a questão social/política.) Mas o correto é fazer com que o renderizador exiba isso (abrindo um ticket para isso) e não o contrário :-) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
2014-02-21 8:01 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Aliás, gostaria de fazer como se faz para abrir um ticket para pedir que vias não pavimentadas fossem desenhadas de forma diferente. O estilo padrão do OSM é o openstreetmap-carto (https://github.com/gravitystorm/openstreetmap-carto/issues) Já existe um ticket aberto para isso: https://github.com/gravitystorm/openstreetmap-carto/issues/110 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
Obrigado. Em 21 de fevereiro de 2014 08:06, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-02-21 8:01 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Aliás, gostaria de fazer como se faz para abrir um ticket para pedir que vias não pavimentadas fossem desenhadas de forma diferente. O estilo padrão do OSM é o openstreetmap-carto (https://github.com/gravitystorm/openstreetmap-carto/issues) Já existe um ticket aberto para isso: https://github.com/gravitystorm/openstreetmap-carto/issues/110 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
OFF TOPIC: Dei meu voto lá. 7 meses depois e cheio de gente pedindo os caras ainda não fizeram E ruim ter que baixar no JOSM, verificar uma-a-uma, clicando e lendo nas tags. Em 21 de fevereiro de 2014 08:06, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-02-21 8:01 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Aliás, gostaria de fazer como se faz para abrir um ticket para pedir que vias não pavimentadas fossem desenhadas de forma diferente. O estilo padrão do OSM é o openstreetmap-carto (https://github.com/gravitystorm/openstreetmap-carto/issues) Já existe um ticket aberto para isso: https://github.com/gravitystorm/openstreetmap-carto/issues/110 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
2014-02-21 8:44 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: OFF TOPIC: Dei meu voto lá. 7 meses depois e cheio de gente pedindo os caras ainda não fizeram E ruim ter que baixar no JOSM, verificar uma-a-uma, clicando e lendo nas tags. Usa esse estilo no JOSM: http://josm.openstreetmap.de/wiki/Styles/Surface-DataEntry O que estiver em amarelo não possui superfície definida. Em verde contínuo superfície pavimentada e em verde tracejado não-pavimentada. Ou esse: http://josm.openstreetmap.de/wiki/Styles/Surface Esse último não é tão rápido e fácil de visualizar quanto o outro, no entanto. Dá para adicionar direto pelo JOSM. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
Obrigado. Em 21 de fevereiro de 2014 08:50, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-02-21 8:44 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: OFF TOPIC: Dei meu voto lá. 7 meses depois e cheio de gente pedindo os caras ainda não fizeram E ruim ter que baixar no JOSM, verificar uma-a-uma, clicando e lendo nas tags. Usa esse estilo no JOSM: http://josm.openstreetmap.de/wiki/Styles/Surface-DataEntry O que estiver em amarelo não possui superfície definida. Em verde contínuo superfície pavimentada e em verde tracejado não-pavimentada. Ou esse: http://josm.openstreetmap.de/wiki/Styles/Surface Esse último não é tão rápido e fácil de visualizar quanto o outro, no entanto. Dá para adicionar direto pelo JOSM. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
7 meses não, 5 anos: https://trac.openstreetmap.org/ticket/1447 2014-02-21 8:44 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: OFF TOPIC: Dei meu voto lá. 7 meses depois e cheio de gente pedindo os caras ainda não fizeram E ruim ter que baixar no JOSM, verificar uma-a-uma, clicando e lendo nas tags. Em 21 de fevereiro de 2014 08:06, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-02-21 8:01 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Aliás, gostaria de fazer como se faz para abrir um ticket para pedir que vias não pavimentadas fossem desenhadas de forma diferente. O estilo padrão do OSM é o openstreetmap-carto (https://github.com/gravitystorm/openstreetmap-carto/issues) Já existe um ticket aberto para isso: https://github.com/gravitystorm/openstreetmap-carto/issues/110 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
Justamente por isso o argumento de o correto é fazer o renderizador exibir isso cada vez mais perde força comigo. Aliás, quem pensa assim deveria estar reforçando essas solicitações nos bugtrackers dos renderizadores - mas não o estão fazendo. (Estou cansando de fazer isso sozinho.) Enunciar um dogma é fácil, difícil é mudar a realidade. O correto mesmo é trazer para o usuário final a informação geográfica que outras pessoas têm e que ele precisa. Esse é o propósito final do OSM, não? E de preferência também mapear de uma forma tal que transformar para a forma ideal de mapear seja algo simples de se fazer depois (provavelmente com scripts). Obviamente isso tem limites, mas do jeito que o Augusto sugeriu eu acho que está 100% ok: é fácil fazer uma query que retorne todas as terras indígenas (e nada mais), e daí é fácil mudar as tags depois. 2014-02-21 10:39 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: 7 meses não, 5 anos: https://trac.openstreetmap.org/ticket/1447 2014-02-21 8:44 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: OFF TOPIC: Dei meu voto lá. 7 meses depois e cheio de gente pedindo os caras ainda não fizeram E ruim ter que baixar no JOSM, verificar uma-a-uma, clicando e lendo nas tags. Em 21 de fevereiro de 2014 08:06, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-02-21 8:01 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Aliás, gostaria de fazer como se faz para abrir um ticket para pedir que vias não pavimentadas fossem desenhadas de forma diferente. O estilo padrão do OSM é o openstreetmap-carto (https://github.com/gravitystorm/openstreetmap-carto/issues) Já existe um ticket aberto para isso: https://github.com/gravitystorm/openstreetmap-carto/issues/110 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
Mas o correto é fazer com que o renderizador exiba isso (abrindo um ticket para isso) e não o contrário :-) +1 Se alguém julgar necessário mostrar que aquilo são terras indígenas antes que o Mapnik as implemente, sempre pode criar uma camada para mostrar em um site específico. Precisaria de uma razão muito boa para etiquetar algo de forma errada (temporariamente). O correto mesmo é trazer para o usuário final a informação geográfica que outras pessoas têm e que ele precisa. Esse é o propósito final do OSM, não? Os dados do OSM não são usados somente no Mapnik, e não são usados somente para a renderização de um mapa. Em 21 de fevereiro de 2014 10:48, Fernando Trebien fernando.treb...@gmail.com escreveu: Justamente por isso o argumento de o correto é fazer o renderizador exibir isso cada vez mais perde força comigo. Aliás, quem pensa assim deveria estar reforçando essas solicitações nos bugtrackers dos renderizadores - mas não o estão fazendo. (Estou cansando de fazer isso sozinho.) Enunciar um dogma é fácil, difícil é mudar a realidade. O correto mesmo é trazer para o usuário final a informação geográfica que outras pessoas têm e que ele precisa. Esse é o propósito final do OSM, não? E de preferência também mapear de uma forma tal que transformar para a forma ideal de mapear seja algo simples de se fazer depois (provavelmente com scripts). Obviamente isso tem limites, mas do jeito que o Augusto sugeriu eu acho que está 100% ok: é fácil fazer uma query que retorne todas as terras indígenas (e nada mais), e daí é fácil mudar as tags depois. 2014-02-21 10:39 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: 7 meses não, 5 anos: https://trac.openstreetmap.org/ticket/1447 2014-02-21 8:44 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: OFF TOPIC: Dei meu voto lá. 7 meses depois e cheio de gente pedindo os caras ainda não fizeram E ruim ter que baixar no JOSM, verificar uma-a-uma, clicando e lendo nas tags. Em 21 de fevereiro de 2014 08:06, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-02-21 8:01 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com : Aliás, gostaria de fazer como se faz para abrir um ticket para pedir que vias não pavimentadas fossem desenhadas de forma diferente. O estilo padrão do OSM é o openstreetmap-carto (https://github.com/gravitystorm/openstreetmap-carto/issues) Já existe um ticket aberto para isso: https://github.com/gravitystorm/openstreetmap-carto/issues/110 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
*double facepalm* Em 21 de fevereiro de 2014 10:39, Fernando Trebien fernando.treb...@gmail.com escreveu: 7 meses não, 5 anos: https://trac.openstreetmap.org/ticket/1447 2014-02-21 8:44 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: OFF TOPIC: Dei meu voto lá. 7 meses depois e cheio de gente pedindo os caras ainda não fizeram E ruim ter que baixar no JOSM, verificar uma-a-uma, clicando e lendo nas tags. Em 21 de fevereiro de 2014 08:06, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-02-21 8:01 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com : Aliás, gostaria de fazer como se faz para abrir um ticket para pedir que vias não pavimentadas fossem desenhadas de forma diferente. O estilo padrão do OSM é o openstreetmap-carto (https://github.com/gravitystorm/openstreetmap-carto/issues) Já existe um ticket aberto para isso: https://github.com/gravitystorm/openstreetmap-carto/issues/110 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
John, todos têm premissas muito similares, e absolutamente nenhum renderiza as reservas atualmente quando mapeadas da forma ideal. Além disso, qual o percentual de usuários que usa sistemas além do que está no site principal? Concorda que quando vendemos por aí a idéia de que o OpenStreetMap é um sistema fantástico, as pessoas COMUNS não vão acessar o ITO Map, nem o MapBox, certo? Existe uma razão para o Google ser famoso: é 1 nome só, e está tudo no mesmo lugar. O usuário comum não quer saber dos detalhes técnicos, 1 nome só e 1 site só é mais fácil. Agora considere isso no contexto de que os desenvolvedores dos componentes do OSM têm sido lentos para atender os nossos pedidos. Pra mim isso é um ótimo argumento em favor de certas concessões (desde que bem analisadas). Um dado no mapa que só serve para quem o colocou lá não é um dado útil para o usuário final. Se você discorda, por junte-se a mim e abra os tickets relativos a cada questão junto aos desenvolvedores dos principais sistemas. Só quero lembrar: abrir o ticket não é garantia de que será feito. Em muitos casos já notei que eles esperam que alguém faça, não necessariamente o desenvolvedor do projeto (provavelmente espera-se que quem solicita faça). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
É, meus dedos estão coçando pra pôr as mãos nesse código. (E quando o fizer, não será só essa alteração, nem só esse ticket.) 2014-02-21 11:13 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: *double facepalm* Em 21 de fevereiro de 2014 10:39, Fernando Trebien fernando.treb...@gmail.com escreveu: 7 meses não, 5 anos: https://trac.openstreetmap.org/ticket/1447 2014-02-21 8:44 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: OFF TOPIC: Dei meu voto lá. 7 meses depois e cheio de gente pedindo os caras ainda não fizeram E ruim ter que baixar no JOSM, verificar uma-a-uma, clicando e lendo nas tags. Em 21 de fevereiro de 2014 08:06, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-02-21 8:01 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Aliás, gostaria de fazer como se faz para abrir um ticket para pedir que vias não pavimentadas fossem desenhadas de forma diferente. O estilo padrão do OSM é o openstreetmap-carto (https://github.com/gravitystorm/openstreetmap-carto/issues) Já existe um ticket aberto para isso: https://github.com/gravitystorm/openstreetmap-carto/issues/110 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
Isso. Meus dedos também estão coçando e há muito tempo. No issue do GitHub há muita discussão e nenhum pull request. Talvez seja só isso mesmo que esteja faltando para a coisa andar. Não parece ser muito difícil: só demorado. Vou dar uma olhada no fim de semana. O mais complicado é montar o ambiente e gerar uns mapas com o resultado da alteração. A alteração no estilo em si parece ser bem simples. 2014-02-21 11:38 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: É, meus dedos estão coçando pra pôr as mãos nesse código. (E quando o fizer, não será só essa alteração, nem só esse ticket.) 2014-02-21 11:13 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: *double facepalm* Em 21 de fevereiro de 2014 10:39, Fernando Trebien fernando.treb...@gmail.com escreveu: 7 meses não, 5 anos: https://trac.openstreetmap.org/ticket/1447 2014-02-21 8:44 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com : OFF TOPIC: Dei meu voto lá. 7 meses depois e cheio de gente pedindo os caras ainda não fizeram E ruim ter que baixar no JOSM, verificar uma-a-uma, clicando e lendo nas tags. Em 21 de fevereiro de 2014 08:06, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-02-21 8:01 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Aliás, gostaria de fazer como se faz para abrir um ticket para pedir que vias não pavimentadas fossem desenhadas de forma diferente. O estilo padrão do OSM é o openstreetmap-carto (https://github.com/gravitystorm/openstreetmap-carto/issues) Já existe um ticket aberto para isso: https://github.com/gravitystorm/openstreetmap-carto/issues/110 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
Existe uma razão para o Google ser famoso: é 1 nome só, e está tudo no mesmo lugar. Isso está longe de ser a principal razão porquê o Google é famoso. Se você discorda, por junte-se a mim e abra os tickets relativos a cada questão junto aos desenvolvedores dos principais sistemas. Eu já abri um *ticket* sobre o OSM antes e também vou atrás de outras questões como a tradução da wiki. Não é como eu não o fizesse, mas só comecei a contribuir para o OSM mesmo só mês passado. Também já vi o Paulo, Arlindo e o Nelson contribuindo discussões nos *tickets* (ou os adicionando). Só talvez não no renderizador principal. Concessões tem que ser dadas só em casos com boas razões. Este caso dessa importação necessita de uma concessão? Em 21 de fevereiro de 2014 11:33, Fernando Trebien fernando.treb...@gmail.com escreveu: John, todos têm premissas muito similares, e absolutamente nenhum renderiza as reservas atualmente quando mapeadas da forma ideal. Além disso, qual o percentual de usuários que usa sistemas além do que está no site principal? Concorda que quando vendemos por aí a idéia de que o OpenStreetMap é um sistema fantástico, as pessoas COMUNS não vão acessar o ITO Map, nem o MapBox, certo? Existe uma razão para o Google ser famoso: é 1 nome só, e está tudo no mesmo lugar. O usuário comum não quer saber dos detalhes técnicos, 1 nome só e 1 site só é mais fácil. Agora considere isso no contexto de que os desenvolvedores dos componentes do OSM têm sido lentos para atender os nossos pedidos. Pra mim isso é um ótimo argumento em favor de certas concessões (desde que bem analisadas). Um dado no mapa que só serve para quem o colocou lá não é um dado útil para o usuário final. Se você discorda, por junte-se a mim e abra os tickets relativos a cada questão junto aos desenvolvedores dos principais sistemas. Só quero lembrar: abrir o ticket não é garantia de que será feito. Em muitos casos já notei que eles esperam que alguém faça, não necessariamente o desenvolvedor do projeto (provavelmente espera-se que quem solicita faça). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Importação da Funai
Se você não se importa que as terras indígenas apareçam no mapa principal juntamente com as demais reservas, provavelmente pensará que a concessão não deve ser dada. Caso contrário, pensará que deve. Acho que leisure=nature_reserve é algo bastante genérico. A descrição no wiki diz (e copia da Wikipédia): A nature reserve is a protected area of importance for wildlife, flora, fauna or features of geological or other special interest, which is reserved and managed for conservation and to provide special opportunities for study or research. Nature reserves may be designated by government institutions in some countries, or by private landowners, such as charities and research institutions. Terras indígenas entrariam no caso de protected area of (...) other special interest. Quando a boundary=national_park, a mesma página diz: Like a nature reserve it is about protecting wildlife etc, and is normally designated by a government. The distinction is unclear and is under discussion, but some suggestions are: nature reserves are smaller areas than national parks. National parks are rather like administrative boundaries around large areas whereas nature reserves are more evident on-the-ground. Então a diferença é o tamanho. A gente já discutiu isso antes: tamanho (comprimento e largura) é dado pela geometria, não pelas tags. (Algo análogo seria você colocar tags numa rodovia dizendo quão longa ela é em quilômetros.) Então, se não há distinção clara, e há uma prática estabelecida de usar as duas juntas (pelo menos nas reservas maiores), e há benefícios para a renderização, ambas podem ser usadas sem que isso constitua um erro. 2014-02-21 12:36 GMT-03:00 John Packer john.pack...@gmail.com: Existe uma razão para o Google ser famoso: é 1 nome só, e está tudo no mesmo lugar. Isso está longe de ser a principal razão porquê o Google é famoso. Se você discorda, por junte-se a mim e abra os tickets relativos a cada questão junto aos desenvolvedores dos principais sistemas. Eu já abri um ticket sobre o OSM antes e também vou atrás de outras questões como a tradução da wiki. Não é como eu não o fizesse, mas só comecei a contribuir para o OSM mesmo só mês passado. Também já vi o Paulo, Arlindo e o Nelson contribuindo discussões nos tickets (ou os adicionando). Só talvez não no renderizador principal. Concessões tem que ser dadas só em casos com boas razões. Este caso dessa importação necessita de uma concessão? Em 21 de fevereiro de 2014 11:33, Fernando Trebien fernando.treb...@gmail.com escreveu: John, todos têm premissas muito similares, e absolutamente nenhum renderiza as reservas atualmente quando mapeadas da forma ideal. Além disso, qual o percentual de usuários que usa sistemas além do que está no site principal? Concorda que quando vendemos por aí a idéia de que o OpenStreetMap é um sistema fantástico, as pessoas COMUNS não vão acessar o ITO Map, nem o MapBox, certo? Existe uma razão para o Google ser famoso: é 1 nome só, e está tudo no mesmo lugar. O usuário comum não quer saber dos detalhes técnicos, 1 nome só e 1 site só é mais fácil. Agora considere isso no contexto de que os desenvolvedores dos componentes do OSM têm sido lentos para atender os nossos pedidos. Pra mim isso é um ótimo argumento em favor de certas concessões (desde que bem analisadas). Um dado no mapa que só serve para quem o colocou lá não é um dado útil para o usuário final. Se você discorda, por junte-se a mim e abra os tickets relativos a cada questão junto aos desenvolvedores dos principais sistemas. Só quero lembrar: abrir o ticket não é garantia de que será feito. Em muitos casos já notei que eles esperam que alguém faça, não necessariamente o desenvolvedor do projeto (provavelmente espera-se que quem solicita faça). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
[Talk-br] OSM nas olimpíadas em Sochi
Mais uma matéria interessante sobre a relevância do OSM no mundo: http://www.theatlantic.com/technology/archive/2014/02/in-sochi-open-source-maps-beat-googles/283909/ -- Fernando Trebien +55 (51) 9962-5409 The speed of computer chips doubles every 18 months. (Moore's law) The speed of software halves every 18 months. (Gates' law) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] D-A-CH
Hallo Frederik, wie groß ist denn der Nachteil beim Zusammenbauen? Das Script, das Du angibst, ist ja erstmal nicht so besonders kompliziert; wie viel Laufzeit und Speicher kostet es, entsprechende Extrakte zusammenzubauen? Naiv und ohne Details des osmosis-codes zu kennen müsste doch eigentlich (wenn man voraussetzen kann, dass die Versionen aller Objekte in allen Teilextrakten zusammenpassen) einmal durch alle osm/pbf-Dateien geparst werden, während die bereits übernommenen ObjektIDs gespeichert sind. Das ist also weitgehend lineare Laufzeit in der Größe der Eingabedateien; und wenn man möchte, kann man statt einer Ergebnisdatei ja auch direkt die weitere Verarbeitung - DB-Import etc. anhängen. Eine Umsetzung für unterschiedliche Shells (notfalls einschließlich Windows) sollte auch machbar sein. Wenn also der Overhead zumindest bestimmter Nachbarextrakte nicht zu groß ist, ist es vielleicht eine Überlegung wert, so 'ne Art Download-Paket-Option anzubieten: Man lade DE, A, CH in einen Ordner, in dem auch das merge-Script liegt und starte das Script (das kann für langsame Netzwerkverbindungen bei Bedarf auch schon während des downloads loslaufen); der Rest ergibt sich von selbst. Oder übersehe ich dabei was wichtiges? Gruß Peter P.S.: Deshalb sind natürlich manche Extrakte, gerade für Kontinente etc. trotzdem sinnvoll, weil es bei denen für die Speicherung der schon übernommenen Objekte schon für einen nicht allerneuesten Heim-PC elend viel Speicher braucht... Am 20.02.2014 23:25, schrieb Frederik Ramm: Hallo, On 20.02.2014 21:59, Christian H. Bruhn wrote: Ist der Bedarf nach DACH-Daten tatsächlich so groß? Oder wollen die Leute nicht eher BYBWACH? Das ist ja schon das Alpen-Extrakt ;) Der Bedarf nach DACH ist zumindest der am häufigsten geäußerte. Ich hab mich bislang immer geziert, weil ich wusste, dass dann natürlich all die Fragen nach Benelux, Deutschland+Polen, Ostsee-Anreinerstaaten und und und kommen. Im Grunde kann man sich benachbarte Regionen mit Osmosis zusammenbauen, hier z.B. ein Skript für ein Benelux+Niedersachsen+Nordrheinwestfalen+Rheinlandpfalz-Extrakt: SCHNIPP #!/bin/sh set -e BASE=http://download.geofabrik.de/europe; PIECES=germany/niedersachsen germany/nordrhein-westfalen germany/rheinland-pfalz belgium netherlands luxembourg OUTPUT=meinfile.osm.pbf OSMOSIS=/srv/osmosis/bin/osmosis # hierunter nix aendern NUM=0 MERGE= OSMOSISFLAGS= export NUM MERGE OSMOSISFLAGS for p in $PIECES do NUM=`expr $NUM + 1` wget -qO$NUM.osm.pbf $BASE/$p-latest.osm.pbf OSMOSISFLAGS=$OSMOSISFLAGS --read-pbf $NUM.osm.pbf $MERGE MERGE=--merge done $OSMOSIS $OSMOSISFLAGS --write-pbf $OUTPUT SCHNAPP Das sollte eigentlich auch die wegen Überschneidung doppelten Ways richtig rauswerfen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] D-A-CH
Am 20.02.2014 17:04, schrieb Frederik Ramm: Hi, für den rein hypothetischen Fall ;) dass ich auf download.geofabrik.de auch ein File D-A-CH anbieten würde, statt nur entweder die Länder einzeln oder ganz Europa - würde man dann auch noch Südtirol mit dazu nehmen, oder eher nicht? Bye Frederik Unter dem Titel DACH nicht, höchstens DACH+ oder so. Außerdem wäre die Frage wieso gerade Südtirol und nicht die anderen an Deutschland grenzenden Ländereien mit D-Historie. :) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (über)große relation 1201227
Hallo Thomas, On 20.02.2014 20:17, malenki wrote: [...] Dank der Größe war die Bearbeitung doch nicht ganz trivial. Ich durfte JOSM einige Male abschießen, da nicht offenbar war, ob er die 100% load auf einem Core endlich oder unendlich verursachen würde. Danach durfte ich noch zwei Dateninkonsistenzen durch Bearbeiten der OSM-Datei mit einem Texteditor beheben. Zuletzt hatte nicht einmal der Validator mehr etwas zu schimpfen, zum Prüfen hat er sich aber auch genügend Zeit gelassen: INFO: Test 'Multipolygon' in 1 min 48 s beendet Hab vielen Dank für deine Arbeit. Jetzt ist es wirklich so handlich, das es bei der Verarbeitung nicht mehr negativ auffällt. Viele Grüße Lars ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] D-A-CH
Hi, On 02/21/2014 08:59 AM, Peter Wendorff wrote: Naiv und ohne Details des osmosis-codes zu kennen müsste doch eigentlich (wenn man voraussetzen kann, dass die Versionen aller Objekte in allen Teilextrakten zusammenpassen) einmal durch alle osm/pbf-Dateien geparst werden, während die bereits übernommenen ObjektIDs gespeichert sind. Ich kenne die genaue Implementierung im Osmosis auch nicht; wenn man voraussetzt, dass alle Inputs sortiert sind, und das sind sie hier, dann kann man sich sogar die Liste der bereits übernommenen Objekt-IDs sparen. Das ist also weitgehend lineare Laufzeit in der Größe der Eingabedateien; und wenn man möchte, kann man statt einer Ergebnisdatei ja auch direkt die weitere Verarbeitung - DB-Import etc. anhängen. Denke ich auch. Müsste halt mal jemand machen ;) grundsätzlich sollte es von den Daten her eigentlich gehen. Früher hatte ich mal die Extrakte mit clipIncompleteEntities gemacht, da fehlte dann der über die Grenze ragende Teil eines Ways, aber jetzt sollte eigentlich jeder Way in jedem Extrakt komplett drin sein. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] D-A-CH
Frederik Ramm wrote Ich kenne die genaue Implementierung im Osmosis auch nicht; wenn man voraussetzt, dass alle Inputs sortiert sind, und das sind sie hier, dann kann man sich sogar die Liste der bereits übernommenen Objekt-IDs sparen. Genau, wenn alle Extrakte aus der gleichen Nacht sind, kann man die hemmungslos in beliebiger Reihenfolge mit osmosis oder auch osmconvert mergen. Manche Objekte sind halt in mehreren Extrakten vorhanden, wovon das letzte Objekt überlebt. Aber da sie alle identisch sind, macht das nichts aus. @frededrik: wenn du mal neue Polygone für DE,A,CH,LUX oder LI brauchst (natürlich auch AL4-10): http://osm.wno-edv-service.de:8080/boundaries. Click und Export als Poly. Sollten deine Wunschgrenze von ~1000 Nodes pro Polygon nur leicht überschreiten. Gruss walter - [url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0.2[/url] -- View this message in context: http://gis.19327.n5.nabble.com/D-A-CH-tp5796922p5797011.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [Fwd: [OSGeo-Discuss] Final OSGeo-Live 7.9 testing sprint - call to action]
Hallo, für diejenigen, die noch keine Pläne für das Wochenende haben! Samstag und Sonntag ist der OSGeo-Live Testing Sprint für die neue Version 7.9. Schönen Gruß Astrid Original Message Subject: [OSGeo-Discuss] Final OSGeo-Live 7.9 testing sprint - call to action From:Cameron Shorter cameron.shor...@gmail.com Date:Fri, February 21, 2014 12:20 pm To: osgeo-discuss disc...@lists.osgeo.org live-demo live-d...@lists.osgeo.org -- We are calling for help for the final OSGeo-Live testing sprint, this weekend, 22-23 February 2014, and the following couple of days. We really want OSGeo seasoned developers to find any outstanding issues, rather than having them found in workshops or by new users in the released version. So please consider joining our testing-sprint to verify everything works. (The many testers in our last sprint made a big difference to quality of our 50+ applications) 1. Sign up at:http://wiki.osgeo.org/wiki/Live_GIS_Disc_Press_Release_46#Participants 2. Download ISO from:http://aiolos.survey.ntua.gr/gisvm/7.9/ 3. Chat about your progress with us at:irc://irc.freenode.net#osgeolive 4. Update your testing status at:https://docs.google.com/spreadsheet/ccc?key=0Al9zh8DjmU_RdGIzd0VLLTBpQVJuNVlHMlBWSDhKLXchl=en_GB#gid=13 We aim to have each application tested by both someone familiar with it, and someone less familiar. Schedule * 21 Feb 2014: OSGeo-Live 7.9 RC3 available for download * 22 Feb 2014: UAT testing starts * 07 Mar 2014: OSGeo-Live 7.9 (final) sent to printers -- Cameron Shorter, Software and Data Solutions Manager LISAsoft Suite 112, Jones Bay Wharf, 26 - 32 Pirrama Rd, Pyrmont NSW 2009 P +61 2 9009 5000, W www.lisasoft.com, F +61 2 9009 5099 ___ Discuss mailing list disc...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Nuovo Import
IMVHO se vi danno i dati sabato è abbastanza difficile caricarli il giorno stesso. Il Data Working Group oramai richiede tutta una serie di attenzioni e pianificazioni negli import (giustamente) che possono essere fatti solo una volta che avete i dati in mano. Secondo me è più realistico programmare per sabato tutte le attività di controllo dei dati e pianificazione dell'import, poi potete contattare il DWG e aspettare le loro indicazioni. OSM ha ormai troppi dati per effettuare un import frettoloso. Ciao, Stefano Il giorno 20 febbraio 2014 23:24, Eduard Natale eduard.nat...@gmail.comha scritto: In effetti dovrebbe arrivare anche quella, sarà un insieme di informazioni che ci daranno sabato, ma in realtà non conosciamo con precisione tutti i dettagli. Io vorrei cominciare con le fermate prima e poi con il tempo aggiungere anche le relazioni. L'idea è: supponiamo di avere questo dataset per sabato, possiamo avvantaggiarci in questo lavoro ora in maniera tale che sabato possiamo procedere semplicemente all'upload su OpenStreetMap. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Nuovo Import
Stefano Salvador wrote IMVHO se vi danno i dati sabato è abbastanza difficile caricarli il giorno stesso. ... Secondo me è più realistico programmare per sabato tutte le attività di controllo dei dati e pianificazione dell'import, poi potete contattare il DWG e aspettare le loro indicazioni. +1 sembra il modo migliore di procedere anche per me - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Nuovo-Import-tp5796917p5796979.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] Nuovo Import
Se si conosce la struttura del file la pianificazione la si può fare a monte. Il controllo dei dati sicuramente sabato. Avete effettuato già degli import? Il 21/feb/2014 09:36 Aury88 spacedrive...@gmail.com ha scritto: Stefano Salvador wrote IMVHO se vi danno i dati sabato è abbastanza difficile caricarli il giorno stesso. ... Secondo me è più realistico programmare per sabato tutte le attività di controllo dei dati e pianificazione dell'import, poi potete contattare il DWG e aspettare le loro indicazioni. +1 sembra il modo migliore di procedere anche per me - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Nuovo-Import-tp5796917p5796979.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 ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Nuovo Import
Se sei nuovo di osm, è meglio andarci molto cauti con un import. -- Sent from my rotary phone. Not a fruit. On Feb 21, 2014 9:50 AM, Eduard Natale eduard.nat...@gmail.com wrote: Se si conosce la struttura del file la pianificazione la si può fare a monte. Il controllo dei dati sicuramente sabato. Avete effettuato già degli import? Il 21/feb/2014 09:36 Aury88 spacedrive...@gmail.com ha scritto: Stefano Salvador wrote IMVHO se vi danno i dati sabato è abbastanza difficile caricarli il giorno stesso. ... Secondo me è più realistico programmare per sabato tutte le attività di controllo dei dati e pianificazione dell'import, poi potete contattare il DWG e aspettare le loro indicazioni. +1 sembra il modo migliore di procedere anche per me - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Nuovo-Import-tp5796917p5796979.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 ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Catasto Trentino
I dati sono pubblicati sotto licenza CC-BY, è compatibile con la licenza di OSM che prevede solo l'attribuzione al progetto e non di certo alla provincia di Trento? Il 20/feb/2014 22:27 Maurizio Napolitano napoo...@gmail.com ha scritto: Come credo sappiate la Provincia Autonoma di Trento ha rilasciato i dati del catasto. Oggi sono andato a vedermi i dati e, praticamente, avremmo tutto l'edificato del Trentino (oltre che strade ed altro ancora). Si tratta delle geometrie e non degli attributi specifici (se non sommari ad indicare se si tratta di uso del suolo o abitazioni o edifici). I dati vengono rilasciati ogni sei mesi. Devo ammettere che ho trovato qualche problemino (in primis mancano informazioni sulla proiezione usata), però rimangono una ottima risorsa. Qui la risorsa http://dati.trentino.it/organization/pat-s-catasto qui i dataset dell'edificato http://dati.trentino.it/dataset/cartografica-catastale-numerica-particelle-poligonali -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Catasto Trentino
Sì è compatibile -- Sent from my rotary phone. Not a fruit. On Feb 21, 2014 9:56 AM, Andrea De Gradi dega...@gmail.com wrote: I dati sono pubblicati sotto licenza CC-BY, è compatibile con la licenza di OSM che prevede solo l'attribuzione al progetto e non di certo alla provincia di Trento? Il 20/feb/2014 22:27 Maurizio Napolitano napoo...@gmail.com ha scritto: Come credo sappiate la Provincia Autonoma di Trento ha rilasciato i dati del catasto. Oggi sono andato a vedermi i dati e, praticamente, avremmo tutto l'edificato del Trentino (oltre che strade ed altro ancora). Si tratta delle geometrie e non degli attributi specifici (se non sommari ad indicare se si tratta di uso del suolo o abitazioni o edifici). I dati vengono rilasciati ogni sei mesi. Devo ammettere che ho trovato qualche problemino (in primis mancano informazioni sulla proiezione usata), però rimangono una ottima risorsa. Qui la risorsa http://dati.trentino.it/organization/pat-s-catasto qui i dataset dell'edificato http://dati.trentino.it/dataset/cartografica-catastale-numerica-particelle-poligonali -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] parzialemte OT: codifica per OSMWIKY
per le way
{{BrowseWay|way-id}}
per i nodi
{{BrowseNode|node-id}}
-
Ciao,
Aury
--
View this message in context:
http://gis.19327.n5.nabble.com/parzialemte-OT-codifica-per-OSMWIKY-tp5796974p5796988.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] parzialemte OT: codifica per OSMWIKY
no, aspetta, non sembrano funzionare :(
prova il template Way
{{Way|way-id}}
-
Ciao,
Aury
--
View this message in context:
http://gis.19327.n5.nabble.com/parzialemte-OT-codifica-per-OSMWIKY-tp5796974p5796989.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] stazioni meteo e errore coordinate WTOSM
Il giorno 20 febbraio 2014 17:48, Simone Cortesi sim...@cortesi.com ha scritto: 2014-02-17 13:27 GMT+01:00 Simone F. grop...@gmail.com: Non sono mai stato convinto che sia stata una buona idea aggiungere la categoria Stazioni meteorologiche d'Italia. Non è una categoria così importante e se pensi che le coordinate poco accurate dei suoi articoli in Wikipedia possano portare ad errori di posizionamento in OSM, possiamo toglierla da wtosm. Sarebbe anche l'unico modo per far sparire i suoi marker dalla mappa. possiamo toglierle per favore le centraline? Lo aggiungo alle cose da fare. inoltre, non capisco perche', sebbene abbia corretto questo: https://it.wikipedia.org/wiki/Roca_Vecchia e messe le coordinate corrette del laesino in provincia di Lecce, esso appaia ancora in WTOSM in mezzo al mare. Si erano fermati temporaneamente gli aggiornamenti. Dovrebbe essersi sistemato. Ciao, Simone F. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: parzialemte OT: codifica per OSMWIKY
PERFETTO!
Mille grazie.
Ma un elenco di questi template dove si trova?
Beppe
-Messaggio originale-
Da: Aury88 [mailto:spacedrive...@gmail.com]
Inviato: venerdì 21 febbraio 2014 10:24
A: talk-it@openstreetmap.org
Oggetto: Re: [Talk-it] parzialemte OT: codifica per OSMWIKY
no, aspetta, non sembrano funzionare :(
prova il template Way
{{Way|way-id}}
-
Ciao,
Aury
--
View this message in context:
http://gis.19327.n5.nabble.com/parzialemte-OT-codifica-per-OSMWIKY-tp5796974
p5796989.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
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: parzialemte OT: codifica per OSMWIKY
di nulla ;) non so se esiste un vero e proprio template...io ho trovato quei template per tentativi. puoi provare a mettere nel campo di ricerca Template: e poi nei risultati di ricerca schiacciare su avanzata e impostare non su (main) o (principale) ma su template. - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/parzialemte-OT-codifica-per-OSMWIKY-tp5796974p5797013.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] stazioni meteo e errore coordinate WTOSM
2014-02-21 13:20 GMT+01:00 Simone F. grop...@gmail.com: inoltre, non capisco perche', sebbene abbia corretto questo: https://it.wikipedia.org/wiki/Roca_Vecchia e messe le coordinate corrette del laesino in provincia di Lecce, esso appaia ancora in WTOSM in mezzo al mare. Si erano fermati temporaneamente gli aggiornamenti. Dovrebbe essersi sistemato. grazie! -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiornamenti statistiche GFOss su OSM
2014-02-18 11:48 GMT+01:00 Diego Guidotti - Aedit s.r.l. guido...@aedit.it: il server che ospitava le statistiche non ce la faceva ad aggiornarle, sono riuscito a resuscitare il sito su un altro server. http://95.240.35.64:8181/osmstat/ La soluzione è temporanea, ma intanto dovreste accedere alle statistiche settimanali aggiornate. che potenza di calcolo ti serve? -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [Talk-it-trentino] Catasto Trentino
pensi ad un import? mi piacerebbe, anche ragionando su strumenti che controllano gli aggiornamenti fra le due basi dati. Sul piano delle licenze non ci sono problemi, la questione è invece sulle geometrie. La proiezione usata da dati è necessaria. I ho assegnato una ETRS89 - UTM32N in quanto ho visto che il dataset dei confini dei comuni catastali aveva, fra i metadati, la voce ETRS89 (che vuol dire solo quale è l'ellissoide usato ma non dice altro di più). Il risultato però non sembra proprio perfetto, infatti sovrapponendo le geometrie sulle tile di OpenStreetMap il risultato mostra proporzioni e forme simili ma scostamenti nelle coordinate come si può vedere qui http://umap.openstreetmap.fr/en/map/dati-catasto-di-povo_5149#18/46.06671/11.15183 Risolta quella vedo di capire altro, se intanto qualcuno si vuole divertire :) ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Presto in arrivo gli open data del Friuli Venezia Giulia
L'assessore regionale per la funzione pubblica Paolo Panontin annuncia il rilascio di una legge sull'open data per sostenere sviluppo e imprese http://www.regione.fvg.it/rafvg/comunicati/comunicato.act?dir=/rafvg/cms/RAFVG/notiziedallagiunta/nm=20140221170152017 Qui l'intervista audio http://redazioneinternet.regione.fvg.it/redazione/reposit/allegati/20140221170152017_PPDpanontinAmmRegTrasparente.mp3 l'FVG aveva già messo a disposizione i dati ma non in una reale forma di open data e senza una strategia di incentivo dietro. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] AMAT - primo changeset
Ciao, sono felice di annunciarvi che AMAT ha appena effettuato il primo changeset live su OpenStreetMap. http://www.openstreetmap.org/changeset/20698725 Si tratta di una piccola correzione nel nome di una via, che ne va a completare la toponomastica, espandendola dall'esistente Via Montecuccoli in Via Raimondo Montecuccoli. inoltre è stato aggiunto anche il tag loc_ref ufficiale del Comune di Milano. Il tutto avviene usando un plugin josm custom, rilasciato opensource e già disponibile su github che fa matching fra la la base dati interna comunale e quella openstreetmap. Settimana prossima si inizierà il lavoro di allineamenteo vero e proprio. Commenti? -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] AMAT - primo changeset
On 02/21/2014 07:05 PM, Simone Cortesi wrote: Ciao, sono felice di annunciarvi che AMAT ha appena effettuato il primo changeset live su OpenStreetMap. http://www.openstreetmap.org/changeset/20698725 Si tratta di una piccola correzione nel nome di una via, che ne va a completare la toponomastica, espandendola dall'esistente Via Montecuccoli in Via Raimondo Montecuccoli. inoltre è stato aggiunto anche il tag loc_ref ufficiale del Comune di Milano. Il tutto avviene usando un plugin josm custom, rilasciato opensource e già disponibile su github che fa matching fra la la base dati interna comunale e quella openstreetmap. Settimana prossima si inizierà il lavoro di allineamenteo vero e proprio. Commenti? benebenebene..., :-) :-) :-) ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] AMAT - primo changeset
Ottimo! Complimenti !! E' possibile avere proma o poi dei dettagli tecnici ed organizzativi di come è stato gestito il tutto? Credo che questa possa essere un'ottima best practise a cui si potrebbe far riferimento Il tutto avviene usando un plugin josm custom, rilasciato opensource e già disponibile su github che fa matching fra la la base dati interna comunale e quella openstreetmap. Molto interessante anche questo: anche qui è possibile avere il rifeirmento GitHub del plugin? Grazie Cesare Gerbino http://cesaregerbino.wordpress.com/ http://www.facebook.com/cesare.gerbino http://www.facebook.com/pages/Cesare-Gerbino-GIS-Blog/246234455498174?ref=hl https://twitter.com/CesareGerbino http://www.linkedin.com/pub/cesare-gerbino/56/494/77b Il giorno 21 febbraio 2014 19:05, Simone Cortesi sim...@cortesi.com ha scritto: Ciao, sono felice di annunciarvi che AMAT ha appena effettuato il primo changeset live su OpenStreetMap. http://www.openstreetmap.org/changeset/20698725 Si tratta di una piccola correzione nel nome di una via, che ne va a completare la toponomastica, espandendola dall'esistente Via Montecuccoli in Via Raimondo Montecuccoli. inoltre è stato aggiunto anche il tag loc_ref ufficiale del Comune di Milano. Il tutto avviene usando un plugin josm custom, rilasciato opensource e già disponibile su github che fa matching fra la la base dati interna comunale e quella openstreetmap. Settimana prossima si inizierà il lavoro di allineamenteo vero e proprio. Commenti? -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Mappiamo quel che c'è sul territorio
E' possibile osservare scrupolosamente questo mantra? http://bologna.repubblica.it/cronaca/2014/02/21/foto/la_festa_delle_parole_sbagliate_quando_l_errore_diventa_arte-79256708/1/?ref=fbpr#21 Ciao /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: Nuovo Import
OSM ha ormai troppi dati per effettuare un import frettoloso Questa non la capisco? Puoi spiegarmi meglio cosa centra la dimensione del database di OSM con un import? Grazie Beppe Da: Stefano Salvador [mailto:stefano.salva...@gmail.com] Inviato: venerdì 21 febbraio 2014 09:30 A: openstreetmap list - italiano Oggetto: Re: [Talk-it] Nuovo Import IMVHO se vi danno i dati sabato è abbastanza difficile caricarli il giorno stesso. Il Data Working Group oramai richiede tutta una serie di attenzioni e pianificazioni negli import (giustamente) che possono essere fatti solo una volta che avete i dati in mano. Secondo me è più realistico programmare per sabato tutte le attività di controllo dei dati e pianificazione dell'import, poi potete contattare il DWG e aspettare le loro indicazioni. OSM ha ormai troppi dati per effettuare un import frettoloso. Ciao, Stefano Il giorno 20 febbraio 2014 23:24, Eduard Natale eduard.nat...@gmail.com ha scritto: In effetti dovrebbe arrivare anche quella, sarà un insieme di informazioni che ci daranno sabato, ma in realtà non conosciamo con precisione tutti i dettagli. Io vorrei cominciare con le fermate prima e poi con il tempo aggiungere anche le relazioni. L'idea è: supponiamo di avere questo dataset per sabato, possiamo avvantaggiarci in questo lavoro ora in maniera tale che sabato possiamo procedere semplicemente all'upload su OpenStreetMap. ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Data Working Group
Chi è, cosa fa il Data Working Group? Come si interfaccia con gli utenti e con i gruppi come il list-italiano? Quale autorità ha? Come esercita questa autorità? Chi ha dato a questo DWG questa autorità? Saluti Beppe ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Nuovo Import
Ciao, fossi in te oggi agirei in maniera diversa All'opendataday suppongo ci saranno diverse persone che avranno anche voglia di imparare come si inseriscono dati in OpenStreetMap quindi fare con loro un percorso manuale è, secondo me, vincente. Aggiungi che i dati vanno verificati quindi l'esperienza che si acquisisce è ancora più interessante e crei comunque formi più persone a partecipare al progetto Un import bypassa questo passaggio Sul fronte poi del dataset di origine il mio consiglio è comunque quello di renderlo disponibile come opendata anche fuori dal contesto Openstreetmap Sono curioso di sapere come sarà oggi la vostra giornata Il programma che avete organizza è uno dei piú interessanti di questo OpenDataDay in Italia Ciaooo ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Data Working Group
È tutto scritto qui http://wiki.openstreetmap.org/wiki/Data_working_group È una iniziativa della OSM Foundation Affronta il problema a livello internazionale e, chiunque (compresi gli iscritti a questa ML), si riferisce a quel gruppi di volontari per questioni di problemi sui dati Il 22/feb/2014 07:56 Giuseppe Amici giuseppeam...@virgilio.it ha scritto: Chi è, cosa fa il Data Working Group? Come si interfaccia con gli utenti e con i gruppi come il list-italiano? Quale autorità ha? Come esercita questa autorità? Chi ha dato a questo DWG questa autorità? Saluti Beppe ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] [Talk-it-trentino] Catasto Trentino
ciao, scusa la domanda sicuramente stupida. Come fai a capire che quell'offset è dovuto ad un riferimento della mappa diverso e non ad un offset presente nella ortofoto usata per ricalcare i profili degli edifici? - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Catasto-Trentino-tp5796954p5797070.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-gb-westmidlands] OOC 1:25k OS mapping
My apologies. I had the wrong URL on the wiki page. Fixed now. Make sure you paste it into the bottom box on the tms details entry dialogue. Cheers Andy From: jonathan [mailto:jonat...@bigfatfrog67.me] Sent: 20 February 2014 23:19 To: talk-gb-westmidlands@openstreetmap.org Subject: Re: [Talk-gb-westmidlands] OOC 1:25k OS mapping I couldn't get the imagery overlay working in JOSM, just delivers me a black screen. Jonathan http://bigfatfrog67.me On 20/02/2014 18:27, Rob Nickerson wrote: Hi Andy, That looks great - really sharp. I'll add it to my layers in JOSM and see how it differs from the NLS layer. I think it will be interesting to see how the 1:25k maps evolved over time as towns expanded. Rob On 20 February 2014 17:44, Andy Robinson ajrli...@gmail.com wrote: As an alternative to the NLS facility I've now completed rectification of our own 1:25k OS mapping covering the midlands. For the viewer: http://faffy.openstreetmap.org/?zoom=11 http://faffy.openstreetmap.org/?zoom=11lat=52.51469lon=-2.00935layers=00 0%0AB0 lat=52.51469lon=-2.00935layers=000 B0 For loading into editor for tracing see http://wiki.openstreetmap.org/wiki/Provisional/First_Edition#Use_in_OSM Cheers Andy ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands _ No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3705/7111 - Release Date: 02/20/14 ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
[Talk-gb-westmidlands] FW: [Talk-GB] East Midlands pub meeting
Derby isn't so far away. Anyone else up for gat crashing on Tuesday? Cheers Andy From: SK53 [mailto:sk53@gmail.com] Sent: 21 February 2014 14:27 To: talk...@openstreetmap.org Subject: [Talk-GB] East Midlands pub meeting Just a quick reminder that the Nottingham pub meeting will be in Derby on Tuesday 25th Feb at the Exeter Arms from 19:30. (https://wiki.openstreetmap.org/wiki/Nottingham/Pub_Meetup) I hope we might see some new faces! Jerry _ No virus found in this message. Checked by AVG - www.avg.com Version: 2014.0.4259 / Virus Database: 3705/7111 - Release Date: 02/20/14 ___ Talk-GB mailing list talk...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-gb-westmidlands mailing list Talk-gb-westmidlands@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
[Talk-es] El Hackatón en Almería
Buenas, El 22 y 23 de marzo en Almería se va a realizar un sarao tecnológico llamado El Hackatón que es algo así como un concurso con charlas y lo que se tercie. http://elhackaton.com/ Me han invitado y si no pasa nada voy a dar la brasa sobre OSM. Uno de los organizadores me comenta que si hay gente de OSM que se anime, seguramente habría espacio para una reunión o lo que queramos. Yo me he ofrecido para, ya que estoy por allí, pues aparte de la charla, armar lo que nos apetezca: talleres, editatón, lo que sea. ¿Qué os parece? ¿Hay gente de Almería y alrededores que se anime? -- Jorge Sanz http://www.osgeo.org http://wiki.osgeo.org/wiki/Jorge_Sanz ___ Talk-es mailing list Talk-es@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-es
[Talk-ar] Sabado #OpenDataDay expedición de datos de transporte
Hola! Mañana es el #OpenDataDay en todo el mundo y con @okfnAR y @bikestorming haremos una expedición de datos de transporte Una de las propuestas incluye trabajaremos sobre datos de OSM, estaria buenisimo que los que estén trabajando activamente en esta data local se sumen. Les dejo el link al meetup: http://www.meetup.com/OpenKnowledgeFoundation/Buenos-Aires/1108312/ Saludos, Matías ___ Talk-ar mailing list Talk-ar@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ar
[Talk-at] at.geoview.info
Hallo liebe Kollegen hab gerade die Seite gefunden finde sie etwas komisch, was meint ihr? http://geoview.info/ -Da man OSM Daten angezeigt bekommt aber Google Karten hinterlegt sind. -Warum nimmt den der Betreiber eigentlich nicht gleich die OSM Karte, da er anscheinend nur einzelne tiles anzeigt. -Suchfunktion gibt es nur mit klick zu klick bzw. über Google da er anscheinend auch power: sub_station anzeigt: http://at.geoview.info/arnfelszollhaus,1490675313n -Ich glaub die Seite ist aber anscheinend noch nicht fertig, aber der Betreiber hat Sie schon gut gemacht mit dem Auslesen der Daten. -für Neulinge etwas verwirrend da eben Daten/Karten nicht von selben Anbieter. -gibt sicher auch noch bessere Seiten -der Contact link ist leider 404; darum schreibe ich hier bei talk-at vielleicht liest er mit. PS: Urheberrecht steht unten: This site based on the informations provided by openstreetmap.org, from on Liebe Grüße Johannes ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Als Punkt-POIs getaggte Flächen
Hallo, kann bitte jemand dem User gerdi4711 erklären, daß es nicht sinnvoll ist, FKK-Bereiche (die geometrisch eindeutig Flächen sind) durch massenhaft Punkte mit name=FKK-Bereich (wobei auch die Verwendung des name=-Tags fragwürdig ist) zu taggen? Ich habe es probiert (nachdem ich von ihm per PM beschuldigt wurde, gezielt FKK-Bereiche zensieren zu wollen) und bekam auf meine PM keine Antwort, und einige Tage später hat er dann einfach wieder Punkte eingezeichnet! Siehe z.B.: http://www.openstreetmap.org/changeset/20405634 Ich habe keine Lust, meine Zeit mit Edit-Warring zu verschwenden. :-( Kevin Kofler ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Als Punkt-POIs getaggte Flächen
Ich bin gerade am Übersiedeln und daher ist meine Zeit etwas knapp. Wenn aber nächste Woche alles erledigt ist, werde ich dem User mal schreiben. LG, Christian Am 22.02.2014 04:31, schrieb Kevin Kofler: Hallo, kann bitte jemand dem User gerdi4711 erklären, daß es nicht sinnvoll ist, FKK-Bereiche (die geometrisch eindeutig Flächen sind) durch massenhaft Punkte mit name=FKK-Bereich (wobei auch die Verwendung des name=-Tags fragwürdig ist) zu taggen? Ich habe es probiert (nachdem ich von ihm per PM beschuldigt wurde, gezielt FKK-Bereiche zensieren zu wollen) und bekam auf meine PM keine Antwort, und einige Tage später hat er dann einfach wieder Punkte eingezeichnet! Siehe z.B.: http://www.openstreetmap.org/changeset/20405634 Ich habe keine Lust, meine Zeit mit Edit-Warring zu verschwenden. :-( Kevin Kofler ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Als Punkt-POIs getaggte Flächen
On Sat, 22 Feb 2014 04:31:27 +0100 Kevin Kofler kevin.kof...@chello.at wrote: Hallo, kann bitte jemand dem User gerdi4711 erklären, daß es nicht sinnvoll ist, FKK-Bereiche (die geometrisch eindeutig Flächen sind) durch massenhaft Punkte mit name=FKK-Bereich (wobei auch die Verwendung des name=-Tags fragwürdig ist) zu taggen? Ich habe es probiert (nachdem ich von ihm per PM beschuldigt wurde, gezielt FKK-Bereiche zensieren zu wollen) und bekam auf meine PM keine Antwort, und einige Tage später hat er dann einfach wieder Punkte eingezeichnet! Sind mir auch schon aufgefallen, und nein die Verwendung des Name-Tags in dieser Form ist natürlich nicht richtig (schon alleine wegen der Abkürzung). Es gibt einen passenden nudism=* Tag. Vielleicht kann man ihm den vorschlagen, an der point vs. area-Diskussion ändert das natürlich nix. Die Trafo-Wiese von ihm ist wohl auch eher keine offizielle, in der Realität vorhandene Kennzeichnung (http://www.openstreetmap.org/node/2618403267). Ich bin nicht einmal sicher, ob es die überhaupt in irgendeiner Form gibt... dort wo er sie (als Punkt) gezeichnet hat, ist jedenfalls weder Trafo noch Wiese :) Mal sehen, ob es nochmal kommt... Das passende Overpass Query für JOSM ist übrigens: node(user:gerdi4711);out meta; und wenn ich mir das so ansehe... FKK-Bereiche sind nur ein kleiner Teil des Problems. :/ -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-it-trentino] Catasto Trentino
Mi dici il nome del tuo comune? Da dove hai preso quel valore? Il valore corretto è quello che trovi nella tabella di questo shape file http://dati.trentino.it/dataset/cartografica-catastale-numerica-confine-comune-catastale 2014-02-21 18:05 GMT+01:00 girarsi_liste liste.gira...@gmail.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Il 20/02/2014 22:26, Maurizio Napolitano ha scritto: Come credo sappiate la Provincia Autonoma di Trento ha rilasciato i dati del catasto. Oggi sono andato a vedermi i dati e, praticamente, avremmo tutto l'edificato del Trentino (oltre che strade ed altro ancora). Si tratta delle geometrie e non degli attributi specifici (se non sommari ad indicare se si tratta di uso del suolo o abitazioni o edifici). I dati vengono rilasciati ogni sei mesi. Devo ammettere che ho trovato qualche problemino (in primis mancano informazioni sulla proiezione usata), però rimangono una ottima risorsa. Qui la risorsa http://dati.trentino.it/organization/pat-s-catasto qui i dataset dell'edificato http://dati.trentino.it/dataset/cartografica-catastale-numerica- particelle-poligonali Il codice catastale del mio comune è I557, se guardo nel dataset, vedo fino a 447, può essere che manchino parti locali nel dataset? - -- Simone Girardelli -BEGIN PGP SIGNATURE- Version: GnuPG v1 iF4EAREIAAYFAlMHh2YACgkQoVS0hKoD3PMZYAD9Exhnk4UXlzYPN66saXgWzYlx ygsBSNXLgBnYiFj3zvkA/i0YBV/mjFrutz4qxHaKN/8U9yJhsFYerxEu/m6EjV3D =P3Gt -END PGP SIGNATURE- ___ Talk-it-trentino mailing list Talk-it-trentino@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it-trentino -- Maurizio Napo Napolitano http://de.straba.us ___ Talk-it-trentino mailing list Talk-it-trentino@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it-trentino
Re: [Talk-it-trentino] Catasto Trentino
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Il 21/02/2014 18:11, Maurizio Napolitano ha scritto: Mi dici il nome del tuo comune? Da dove hai preso quel valore? Il valore corretto è quello che trovi nella tabella di questo shape file http://dati.trentino.it/dataset/cartografica-catastale-numerica-confine-comune-catastale Il comune è Scurelle: http://www.comuni-italiani.it/022/171/index.html Praticamente è lo stesso codice catastale che si mette sul 730 nelle informazioni del comune di residenza Comunque scarico il dataset e vedo, grazie. - -- Simone Girardelli -BEGIN PGP SIGNATURE- Version: GnuPG v1 iF4EAREIAAYFAlMHiZ4ACgkQoVS0hKoD3PMJcwEAhrNAM14YqM8D07abg9+vZEFc L0X94XFWE8SIC0O1qtAA+wV8uvzX79nogNM80saASpetpwHE3B4Xb2UiI53V2GUN =oAx8 -END PGP SIGNATURE- ___ Talk-it-trentino mailing list Talk-it-trentino@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it-trentino
Re: [Talk-it-trentino] Catasto Trentino
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Il 21/02/2014 18:17, Maurizio Napolitano ha scritto: Il comune è Scurelle: http://www.comuni-italiani.it/022/171/index.html Praticamente è lo stesso codice catastale che si mette sul 730 nelle informazioni del comune di residenza Comunque scarico il dataset e vedo, grazie. Il fatto è che in Trentino abbiamo ancora il catasto dell'impero austro-ungarico. Tant'è che ci sono i confini catastali anche delle frazioni di Trento. Il codice di cui parli è quello nazionale, e ci pensa il catasto di trento a fare le conversioni. Il codice che cerchi è il 343, quindi basta che apri i file che hanno, nel nome, il codice 343 ed ottieni quello che cerchi. Ciao Comunqe mi son trovato meglio con questo dataset, è più veloce per la ricerca del codice con qgis: http://dati.trentino.it/dataset/limiti-di-comune-catastale/resource/b77d31ee-59c8-4a78-afe0-3bbb681828d0 - -- Simone Girardelli -BEGIN PGP SIGNATURE- Version: GnuPG v1 iF4EAREIAAYFAlMHi7AACgkQoVS0hKoD3PNXqwD/dzzlv5Nwdvi3fIDbk0KzGoVr DyFLWoQMOQ2fEhHbNukA/AzEd0DSDbeu81TAgHmGXsNPNtfewdi6AEVsUrmY7zqn =AhrY -END PGP SIGNATURE- ___ Talk-it-trentino mailing list Talk-it-trentino@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it-trentino
Re: [Talk-ro] Import lista monumente istorice
Salut,
Am aflat azi că cei care mapează pe Google Maps (sau Google România?
nu e prea clar) ar fi semnat o înțelegere cu Agentia Națională pentru
Turism pentru maparea monumentelor istorice. Mi-e puțin neclar ce
treabă are ANT și ce vor mapa efectiv, dar mi s-a părut un incentive
bun să reînviem proiectul ăsta.
Mâine la hackathon sper să mobilizez niște oameni care să facă niște părți:
- identificarea clădirilor monument deja existente, dar nemarcate ca
atare pe OSM
- extragerea coordonatelor din monumentele marcate pe OSM
- găsirea și rezolvarea diferențelor între OSM, Wikipedia și listele
de la Cimec.
Florin, când ai importat muzeele ai marcat și monumentele istorice?
Dacă mai vrea cineva să ajute, chiar remote, mă puteți contacta.
Strainu
În data de 18 iulie 2013, 11:41, Strainu strain...@gmail.com a scris:
În data de 18 iulie 2013, 09:42, Badita Florin baditaflo...@gmail.com a
scris:
Pe siteul http://www.apmnir.ro/map.php sunt 2400 de monumente istorice. Nu
merge downlodata direct baza de date, dar se poate face o interogare si ca
raspuns , prin filebug putem avea output-ul asa
divimg src=/images/yahoo_muzeu_icon_cupoza.jpg alt=monument cu poze
width=18 height=19 hspace=5 vspace=5 align=absmiddle /a href=#
class=link_monument
onClick=loadAction_prototype_detalii($('divnrmonumente'),'/aj_nrmonumente.php',240);
placepoint(map,44.45558,26.088380555,'Cas#259;','Aleea
Alexandru','14',1,240,2,'detalii(imagini/descrieri/comentarii)','Adresa');
Cas#259; - Aleea Alexandru, nr. 14/abr
Din care putem automatiza cu un script sa scoatem un output de genul : nume,
strada, numar, coordonate gps, destul cat sa putem face un import in
OpenStreetMap prin Josm
De aici avem numele monumentului, Casa
strada unde se afla, Aleea Alexandru
numarul strazi 14
precum si coordonatele GPS
44.45558,26.088380555
Stie cineva cum facem cel mai simplu script pentru asa ceva ?
Salut Florin,
Mulțumesc că ai ridicat acest subiect! De vreo 2 ani mă tot gândesc la
un asemenea import.
Cel mai important: Te rog să nu faci importul DOAR de pe harta aceea,
deoarece conține multe erori. Monumentele au fost puse probabil cu
mâna, iar imaginile au un oarecare offset. Dacă faci importul de
acolo, trebuie și corectate de mână.
Listele de monumente istorice de la Wikipedia [1] conțin și
coordonate, în aproximativ 5% din monumente (1500 de monumente). De
fapt, sunt mult mai multe, pentru că multe coordonate sunt puse la
ansambluri, ele putând fi aplicate pentru majoritatea, sau toate,
monumentele din ansamblu. Aceste coordonate sunt luate de multe or
direct din metadatele imaginilor, fiind deci foarte apropiate de
locația reală (câteodată trebuie să le treci pe partea celalaltă a
străzii, dar cele mai multe sunt corecte). Pot fi verificate manual
direct pe harta OSM la [2]. Datele de aici le am în format JSON, deci
ușor reutilizabile de programatori
Problema mai dureroasă și cea care m-a împiedicat să fac importul până
acum e că nu vreau să duplic informația deja existentă: multe dintre
monumente există deja, chiar desenate frumos, cu contur. Aș vrea să le
identific pe acelea și să le adaug codul LMI și să le identific ca
puncte de atracția și de-abia apoi să import alte date.
Eu n-am până mai în toamnă timp să mă ocup de asta, dar dacă vrea
cineva să programeze, vă pot ajuta cu date, cod pentru interacțiunea
cu listele de pe Wikipedia sau sfaturi.
Strainu
[1] https://ro.wikipedia.org/wiki/Lista_monumentelor_istorice_din_Rom%C3%A2nia
[2] http://proiecte.strainu.ro/wiki/wlm/wlm.html
___
Talk-ro mailing list
Talk-ro@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ro
[Talk-ro] Nomenclatorul străzilor - Timișoara
Primăria Timișoara a publicat pe date.gov.ro nomenclatorul străzilor. N-are informații geografice foarte relevante, dar s-ar putea dovedi util în cazul unor discuții gen Calea Călărași/Călărașilor; în plus, e și mai interesant faptul că are *fostele* nume ale străzilor. Nu știu cum pot fi adăugate mai multe nume vechi, dar ar fi interesant. http://data.gov.ro/dataset/nomeclatorul-strazilor-din-municipiul-timisoara/resource/9ab5487d-35b1-4ba1-8dbd-767b3d749b03 Strainu ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
Re: [Talk-ro] Nomenclatorul străzilor - Timișoara
Alt_name ar fi cel mai ok pentru nume mai vechi dar pe care oamenii inca le stiu On Feb 21, 2014 1:17 PM, Strainu strain...@gmail.com wrote: Primăria Timișoara a publicat pe date.gov.ro nomenclatorul străzilor. N-are informații geografice foarte relevante, dar s-ar putea dovedi util în cazul unor discuții gen Calea Călărași/Călărașilor; în plus, e și mai interesant faptul că are *fostele* nume ale străzilor. Nu știu cum pot fi adăugate mai multe nume vechi, dar ar fi interesant. http://data.gov.ro/dataset/nomeclatorul-strazilor-din-municipiul-timisoara/resource/9ab5487d-35b1-4ba1-8dbd-767b3d749b03 Strainu ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro ___ Talk-ro mailing list Talk-ro@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ro
Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec
Translation in english of the title : Municipalities and government of Québec (Canada) will adopt the CC BY 4.0 - Ref. : https://lists.openstreetmap.org/pipermail/talk-ca/2014-February/006069.html Dear Paul, I am sorry to contradict you, but please find attached copy of my conversation with Simon Poole and le...@osmfoundation.org against the CC 4.0 This conversation includes the response of Simon Poole. I also copy to the list of discussion legal-talk @ I reiterate. It is the responsibility of OSM Foundation to instruct his community of his CC 4.0 interpretation as it has done for the CC 2.0 and CC 3.0 And in my humble opinion, the tiles and the BD licenses should updates to CC 4.0 to reduce proliferation of license, etc. Regards, Note : See press releases http://donnees.ville.montreal.qc.ca/un-avantage-pour-les-citoyens-montreal-disposera-de-la-licence-ouverte-cc-4-une-premiere-au-canada-en-matieres-de-donnees-ouvertes/ http://www.ville.quebec.qc.ca/actualites/fiche_autres_actualites.aspx?id=13362 --- Dre Diane Mercier @MTL_DO | donnees.ville.montreal.qc.ca @okfnca | ca.okfn.org @_FACiL | facil.qc.ca @carnetsDM | dianemercier.com http://about.me/dianemercier http://vizualize.me/oKvvtBkJXK?r=oKvvtBkJXK Webographie du libre : https://www.zotero.org/dmercier/items/order/dateModified/sort/desc « Pas de données ouvertes, sans logiciel libre ni formats ouverts » Le 2014-02-21 01:42, Paul Norman a écrit : No one has raised the issue on legal-talk@ since CC 4 was released. *From:*Pierre Béland [mailto:pierz...@yahoo.fr] *Sent:* Thursday, February 20, 2014 8:43 AM *To:* diane.merc...@gmail.com; Talk-ca (OSM) *Subject:* Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec Merci Diane pour ces infos. Ce sont là de bonnes nouvelles pour la communauté OSM du Québec. Espérons que nous aurons rapidement des nouvelles de la part du comité légal de OSM là-dessus. ---BeginMessage--- Good morning Diane There are two aspects to compatibility of a licence with OSM. On the one hand it has to be compatible with our contributor terms which only provide for attribution on request and on the other hand has to be compatible with our current distribution licence. Essentially this rules out any licence with share alike provisions. We can however provide attribution in a limited fashion. In the past we have deemed CC by 2.0 and 3.0 sources as compatible with OSM if the rights owners have agreed with how we do attribution via our website. Outside of this we have no formal approval purpose for licences, which is no surprise given that we have no lawyers on our staff of zero :-). We would make a determination if and when such a need would arise, if OKFN or your organisation would like to initiate such a review we would naturally gladly take the results in to account. Kind regards Simon Poole Am 17.12.2013 20:18, schrieb Diane Mercier, Ph.D.: Hi, The city of Montreal is currently revising its open license so the OpenStreetMap community can reuse our open geospatial data in your databases and applications. The license model should be approved by the OKFN as well as by the OSM to allow greater reuse of our open data. We were getting ready to reuse the Government of Canada (version 2.0) license which is approved by OKFN and OSM. Have you approved - or are you currently approving - CC 4.0 international just as the OKFN is doing (see od-discuss list)? Note : The french version will be the official one because City of Montréal is a French city in Québec, Canada. An english version will be published at the same time ;-) Best Regards, Dre Diane Mercier Ph.D. Sciences de l'information Chargée de projet principale des données ouvertes Division Communications numériques et graphiques Direction des communications Service du capital humain et des communications Ville de Montréal 303, rue Notre-Dame Est, 1A, Montréal QC H2Y 3Y8 dmerc...@ville.montreal.qc.ca @MTL_DO | donnees.ville.montreal.qc.ca 514 872-9702 | donneesouver...@ville.montreal.qc.ca Ambassadrice de l'Open Knowledge Foundation Network - Groupe local au Canada @okfnca | ca.okfn.org @carnetsDM | dianemercier.com « Pas de données ouvertes, sans logiciel libre ni formats ouverts » - Message original - Objet: Re: [Talk-ca] Les licences Creative Commons 4.0 (CC-BY-4.0 et CC-BY-SA-4.0) est-elle acceptée par OSM De: Guillaume Pratte guilla...@guillaumepratte.net Date:Mar 17 décembre 2013 13:05 À: Diane Mercier diane.merc...@gmail.com Bonjour Diane, Tu peux contacter (en anglais) l?équipe légale de la fondation OpenStreetMap à l?adresse suivante: le...@osmfoundation.org Cordialement, Guillaume Le 2013-12-17 à 12:23, Diane Mercier diane.merc...@gmail.com a écrit : Bonjour, Pourriez-vous m'indiquer si OSM accepte les données libérées sous
Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec
Municipalities and government of Québec will adopt the CC BY 4.0 Diane Le 2014-02-21 07:04, Simon Poole a écrit : This is I believe a simple misunderstanding: le...@osmfoundation.org is the internal list of the LWG legal-t...@openstreetmap.org is the legal discussion mailing list open to the general public. On the matter at hand: as I write in the quoted mail, we are quite open to taking the results of a review of CC by 4.0 wrt compatibility with our contributor terms and the ODbL 1.0 in to account. Note, as I wrote in my mail, it is likely not worth doing for CC by-SA 4.0 as it is clear that a share alike licence will not be CT compatible. Simon Am 21.02.2014 12:12, schrieb Diane Mercier: Translation in english of the title : Municipalities and government of Québec (Canada) will adopt the CC BY 4.0 - Ref. : https://lists.openstreetmap.org/pipermail/talk-ca/2014-February/006069.html Dear Paul, I am sorry to contradict you, but please find attached copy of my conversation with Simon Poole and le...@osmfoundation.org against the CC 4.0 This conversation includes the response of Simon Poole. I also copy to the list of discussion legal-talk @ I reiterate. It is the responsibility of OSM Foundation to instruct his community of his CC 4.0 interpretation as it has done for the CC 2.0 and CC 3.0 And in my humble opinion, the tiles and the BD licenses should updates to CC 4.0 to reduce proliferation of license, etc. Regards, Note : See press releases http://donnees.ville.montreal.qc.ca/un-avantage-pour-les-citoyens-montreal-disposera-de-la-licence-ouverte-cc-4-une-premiere-au-canada-en-matieres-de-donnees-ouvertes/ http://www.ville.quebec.qc.ca/actualites/fiche_autres_actualites.aspx?id=13362 --- Dre Diane Mercier @MTL_DO | donnees.ville.montreal.qc.ca @okfnca | ca.okfn.org @_FACiL | facil.qc.ca @carnetsDM | dianemercier.com http://about.me/dianemercier http://vizualize.me/oKvvtBkJXK?r=oKvvtBkJXK Webographie du libre : https://www.zotero.org/dmercier/items/order/dateModified/sort/desc « Pas de données ouvertes, sans logiciel libre ni formats ouverts » Le 2014-02-21 01:42, Paul Norman a écrit : No one has raised the issue on legal-talk@ since CC 4 was released. *From:*Pierre Béland [mailto:pierz...@yahoo.fr] *Sent:* Thursday, February 20, 2014 8:43 AM *To:* diane.merc...@gmail.com; Talk-ca (OSM) *Subject:* Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec Merci Diane pour ces infos. Ce sont là de bonnes nouvelles pour la communauté OSM du Québec. Espérons que nous aurons rapidement des nouvelles de la part du comité légal de OSM là-dessus. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec
Eh good news for OSM-Quebec community then. Let's wait for the official confirmation of the exact license adopted. Bonne nouvelle pour les contributeurs OSM-Québec. Attendons cependant la confirmation officielle de la licence exacte adoptée. Pierre De : Diane Mercier diane.merc...@gmail.com À : Simon Poole si...@osmfoundation.org; Paul Norman penor...@mac.com; 'Pierre Béland' pierz...@yahoo.fr; 'Talk-ca (OSM)' talk-ca@openstreetmap.org; legal-t...@openstreetmap.org; le...@osmfoundation.org Envoyé le : Vendredi 21 février 2014 8h43 Objet : Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec Municipalities and government of Québec will adopt the CC BY 4.0 Diane Le 2014-02-21 07:04, Simon Poole a écrit : This is I believe a simple misunderstanding: le...@osmfoundation.org is the internal list of the LWG legal-t...@openstreetmap.org is the legal discussion mailing list open to the general public. On the matter at hand: as I write in the quoted mail, we are quite open to taking the results of a review of CC by 4.0 wrt compatibility with our contributor terms and the ODbL 1.0 in to account. Note, as I wrote in my mail, it is likely not worth doing for CC by-SA 4.0 as it is clear that a share alike licence will not be CT compatible. Simon Am 21.02.2014 12:12, schrieb Diane Mercier: Translation in english of the title : Municipalities and government of Québec (Canada) will adopt the CC BY 4.0 - Ref. : https://lists.openstreetmap.org/pipermail/talk-ca/2014-February/006069.html Dear Paul, I am sorry to contradict you, but please find attached copy of my conversation with Simon Poole and le...@osmfoundation.org against the CC 4.0 This conversation includes the response of Simon Poole. I also copy to the list of discussion legal-talk @ I reiterate. It is the responsibility of OSM Foundation to instruct his community of his CC 4.0 interpretation as it has done for the CC 2.0 and CC 3.0 And in my humble opinion, the tiles and the BD licenses should updates to CC 4.0 to reduce proliferation of license, etc. Regards, Note : See press releases http://donnees.ville.montreal.qc.ca/un-avantage-pour-les-citoyens-montreal-disposera-de-la-licence-ouverte-cc-4-une-premiere-au-canada-en-matieres-de-donnees-ouvertes/ http://www.ville.quebec.qc.ca/actualites/fiche_autres_actualites.aspx?id=13362 --- Dre Diane Mercier @MTL_DO | donnees.ville.montreal.qc.ca @okfnca | ca.okfn.org @_FACiL | facil.qc.ca @carnetsDM | dianemercier.com http://about.me/dianemercier http://vizualize.me/oKvvtBkJXK?r=oKvvtBkJXK Webographie du libre : https://www.zotero.org/dmercier/items/order/dateModified/sort/desc « Pas de données ouvertes, sans logiciel libre ni formats ouverts » Le 2014-02-21 01:42, Paul Norman a écrit : No one has raised the issue on legal-talk@ since CC 4 was released. From:Pierre Béland [mailto:pierz...@yahoo.fr] Sent: Thursday, February 20, 2014 8:43 AM To: diane.merc...@gmail.com; Talk-ca (OSM) Subject: Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec Merci Diane pour ces infos. Ce sont là de bonnes nouvelles pour la communauté OSM du Québec. Espérons que nous aurons rapidement des nouvelles de la part du comité légal de OSM là-dessus.___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Updating Langley and use of alt_name?
Hi Paul, I was following your message until this statement, where I got confused. Are you saying the city of Langley is not a city? What do you mean by in British English? That's all fairly simple, but the place node is more complicated. Langley is not a city in British English, but a town. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec
On Fri, Feb 21, 2014 at 10:26 AM, Pierre Béland pierz...@yahoo.fr wrote: Eh good news for OSM-Quebec community then. Let's wait for the official confirmation of the exact license adopted. I disagree. Any license drafted or adopted by a Canadian government, other than a no-restrictions, equivalent-to-Public-Domain-license, like ODC-PDDL, will require a waiver or clarification from the municipality (or province / territory, or feds) that attribution as provided by OpenStreetMap (wiki page, probably listed on a sub-page) meets their interpretation of attribution. So, adoption of CC-anything-but-0 is bad for local OSM communities. It would likely work out okay in the end for those local OpenStreetMap communities. To my knowledge, every municipality approached for such a waiver has granted it. To OpenStreetMap Foundation at least. For the Open Data community at large, and for the municipality / governement itself, adoption of any restricting license is a disaster. For one thing, not every potential open project will be on the radar of a municipality in the same way that OpenStreetMap is. Too bad for that potential Open Data Project. Perhaps they'll get the waiver they need, perhaps they won't. Again, any government open data publication in Canada must be licensed ODC-PDDL, or else it is a not-open-enough-closed-data-failure. Another sign of bizarre, Open-blindness. I've had government open data representatives say to me, the equivalent of, So what if the license says something complicated. It's open, just do what you want. We won't go after anybody who breaks the license. We just need to be able to shut down anybody who embarrasses us. Ahem. No. 0) If you plan to grant wavers and exemptions anyway, why not just use an unrestricted license? Oh, did you want to only grant exemptions for projects / persons of whom you approve? That doesn't sound very open. 1) If you don't plan to enforce your license terms, why select (or worse, why draft) a license with restrictions? Select ODC-PDDL instead. 2) If you want developers to work with your data, do you want developers who care enough to read, understand and follow your terms, or not? Because your license with restrictions just cut out a portion of those developers. You can still keep the developers that don't read licenses, or don't care about the terms. Congratulations. 3) What, you want to shut down a use of the data that embarrasses you? No. It doesn't work that way. If Open Data can be shown to expose that your mayor is a pathologically lying, bullying, drug addict with possible links to organized crime, you don't get to shut down the analysis just because your boss finds it embarrassing. (It's just a hypothetical example) 4) If you really do plan to grant a waiver or exemption to every project / user who asks for it, shouldn't you have selected an unrestricted Open Data License that didn't place the burden of that extra waiver step upon you (and each potential user) ? ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OSM-legal-talk] Nouvelle licence de données ouvertes au Québec
On Fri, Feb 21, 2014 at 4:58 PM, Mike Linksvayer m...@gondwanaland.com wrote: On Fri, Feb 21, 2014 at 1:14 PM, Richard Weait rich...@weait.com wrote: [ ... ] Again, any government open data publication in Canada must be licensed ODC-PDDL, or else it is a not-open-enough-closed-data-failure. I agree that all PSI ought be public domain, with ODC-PDDL or CC0 or some other public domain instrument, since the sane default isn't the default. But calling attribution-only terms a closed-data-failure (BTW, what does that make ODbL? Is OSM the only entity in the world that can use non public domain terms and not be a closed data fail?) seems over the top. Government Open Data, and OpenStreetMap Open Data are different kettles of fish. And so different goal posts apply to each. Government Open Data is more-correctly Citizen Open Data. For that same government to attempt to then restrict the use of that data by the citizens who own it, and pay for it (and, in fact who own the government :-) ) well, that's the part that is over the top. :-) OpenStreetMap data is created by the OpenStreetMap contributors. Where those same contributors decide to place themselves, as a group, along the Open Spectrum has nothing to do with government, er, *strikeover* citizen data. It might also be a a long-standing and heated discussion amongst those same contributors. :-) Thanks, Mike. Cheers. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OSM-legal-talk] Nouvelle licence de données ouvertes au Québec
On Fri, Feb 21, 2014 at 1:14 PM, Richard Weait rich...@weait.com wrote: On Fri, Feb 21, 2014 at 10:26 AM, Pierre Béland pierz...@yahoo.fr wrote: Eh good news for OSM-Quebec community then. Let's wait for the official confirmation of the exact license adopted. I disagree. Any license drafted or adopted by a Canadian government, other than a no-restrictions, equivalent-to-Public-Domain-license, like ODC-PDDL, will require a waiver or clarification from the municipality (or province / territory, or feds) that attribution as provided by OpenStreetMap (wiki page, probably listed on a sub-page) meets their interpretation of attribution. So, adoption of CC-anything-but-0 is bad for local OSM communities. It would likely work out okay in the end for those local OpenStreetMap communities. To my knowledge, every municipality approached for such a waiver has granted it. To OpenStreetMap Foundation at least. For the Open Data community at large, and for the municipality / governement itself, adoption of any restricting license is a disaster. For one thing, not every potential open project will be on the radar of a municipality in the same way that OpenStreetMap is. Too bad for that potential Open Data Project. Perhaps they'll get the waiver they need, perhaps they won't. Again, any government open data publication in Canada must be licensed ODC-PDDL, or else it is a not-open-enough-closed-data-failure. I agree that all PSI ought be public domain, with ODC-PDDL or CC0 or some other public domain instrument, since the sane default isn't the default. But calling attribution-only terms a closed-data-failure (BTW, what does that make ODbL? Is OSM the only entity in the world that can use non public domain terms and not be a closed data fail?) seems over the top. Asking for a clarification that provided attribution is OK seems over the top too, at least for CC-BY, especially CC-BY-4.0, given You may satisfy the [attribution conditions] in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. If every attribution needs to be clarified with the licensor to determine if it is OK, then attribution licenses truly are a fail. But that practice is certainly not the intent of such licenses. IMO, IANAL, etc etc. The remainder below is most excellent. Another sign of bizarre, Open-blindness. I've had government open data representatives say to me, the equivalent of, So what if the license says something complicated. It's open, just do what you want. We won't go after anybody who breaks the license. We just need to be able to shut down anybody who embarrasses us. Ahem. No. 0) If you plan to grant wavers and exemptions anyway, why not just use an unrestricted license? Oh, did you want to only grant exemptions for projects / persons of whom you approve? That doesn't sound very open. 1) If you don't plan to enforce your license terms, why select (or worse, why draft) a license with restrictions? Select ODC-PDDL instead. 2) If you want developers to work with your data, do you want developers who care enough to read, understand and follow your terms, or not? Because your license with restrictions just cut out a portion of those developers. You can still keep the developers that don't read licenses, or don't care about the terms. Congratulations. 3) What, you want to shut down a use of the data that embarrasses you? No. It doesn't work that way. If Open Data can be shown to expose that your mayor is a pathologically lying, bullying, drug addict with possible links to organized crime, you don't get to shut down the analysis just because your boss finds it embarrassing. (It's just a hypothetical example) 4) If you really do plan to grant a waiver or exemption to every project / user who asks for it, shouldn't you have selected an unrestricted Open Data License that didn't place the burden of that extra waiver step upon you (and each potential user) ? ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec
This is I believe a simple misunderstanding: le...@osmfoundation.org is the internal list of the LWG legal-t...@openstreetmap.org is the legal discussion mailing list open to the general public. On the matter at hand: as I write in the quoted mail, we are quite open to taking the results of a review of CC by 4.0 wrt compatibility with our contributor terms and the ODbL 1.0 in to account. Note, as I wrote in my mail, it is likely not worth doing for CC by-SA 4.0 as it is clear that a share alike licence will not be CT compatible. Simon Am 21.02.2014 12:12, schrieb Diane Mercier: Translation in english of the title : Municipalities and government of Québec (Canada) will adopt the CC BY 4.0 - Ref. : https://lists.openstreetmap.org/pipermail/talk-ca/2014-February/006069.html Dear Paul, I am sorry to contradict you, but please find attached copy of my conversation with Simon Poole and le...@osmfoundation.org against the CC 4.0 This conversation includes the response of Simon Poole. I also copy to the list of discussion legal-talk @ I reiterate. It is the responsibility of OSM Foundation to instruct his community of his CC 4.0 interpretation as it has done for the CC 2.0 and CC 3.0 And in my humble opinion, the tiles and the BD licenses should updates to CC 4.0 to reduce proliferation of license, etc. Regards, Note : See press releases http://donnees.ville.montreal.qc.ca/un-avantage-pour-les-citoyens-montreal-disposera-de-la-licence-ouverte-cc-4-une-premiere-au-canada-en-matieres-de-donnees-ouvertes/ http://www.ville.quebec.qc.ca/actualites/fiche_autres_actualites.aspx?id=13362 --- Dre Diane Mercier @MTL_DO | donnees.ville.montreal.qc.ca @okfnca | ca.okfn.org @_FACiL | facil.qc.ca @carnetsDM | dianemercier.com http://about.me/dianemercier http://vizualize.me/oKvvtBkJXK?r=oKvvtBkJXK Webographie du libre : https://www.zotero.org/dmercier/items/order/dateModified/sort/desc « Pas de données ouvertes, sans logiciel libre ni formats ouverts » Le 2014-02-21 01:42, Paul Norman a écrit : No one has raised the issue on legal-talk@ since CC 4 was released. *From:*Pierre Béland [mailto:pierz...@yahoo.fr] *Sent:* Thursday, February 20, 2014 8:43 AM *To:* diane.merc...@gmail.com; Talk-ca (OSM) *Subject:* Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec Merci Diane pour ces infos. Ce sont là de bonnes nouvelles pour la communauté OSM du Québec. Espérons que nous aurons rapidement des nouvelles de la part du comité légal de OSM là-dessus. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [Imports] GNS tag cleanup
My comments largely revolve around the use of editor based deprecation. --- One comment is specific to GNS. The gns:uni and gns:ufi are a primary keys in the source data, and as such should definitely be kept to aid in future matching or conflation of the object. See: http://www.geographic.org/geographic_names/definitions.html#UFI And: http://earth-info.nga.mil/gns/html/ Also of some value is gns:fc. gns:nt should have been used during the original import to tag historic names differently and perhaps shuffle some of them to a historic map database. --- In general I feel the editor delete list approach is bad for two reasons: 1) Tags are deleted behind the back of human editors. There's no effective human review since the deletion is done at save time not load time in common editors. 2) Slowly bit-rotting away data does not give data consumers any notice that their tags are going away. Far better that a data consumer notices the deprecation right away. They could then can adjust their software, or argue for restoration of the data, before the data is long gone under a blizzard of overlapping edits. On Thu, Feb 13, 2014 at 11:45 PM, Paul Norman penor...@mac.com wrote: About 6 years ago, a set of data was imported from GNS, consisting of place names, mainly of place=town. Any comments? ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Updating Langley and use of alt_name?
Looking at the Township and City of Langley, I see that these relations are duplicate polygons that share the exact same nodes. Then why two relations? Instead, would it be better to simply use alt_name for the city, added to the Township of Langley. Such Classification where you have two admin_level=8 for the same area is a nonsense to my point of view. To show the inconsistencies that this creates, let's have a look at the Nominatim links below. You will see how the Locality, Suburb, Residential highways etc. are shared between the two. And most of the item are classified under the Township. Some other elements under the City. But searching Nominatims, you will see places classified either und the Township, the City of simply Langley. For example, if you search in Nominatim for * Livingstone, Langley. Canada, this will be reported as Livingstone, Township of Langley, Greater Vancouver Regional District, British-Columbia, Canada * 10 Avenue, Township of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada * Brookswood, Township of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada * 201A Street, Brookswood, Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada The best seems to make a choice for which locality title will be showed to describe Langley and use an alt_name tag to describe the second appellation * City Boundary Township of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada http://www.openstreetmap.org/relation/2031947 http://nominatim.openstreetmap.org/details.php?place_id=9164399767 * City Boundary City of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada http://www.openstreetmap.org/relation/2031946 http://nominatim.openstreetmap.org/details.php?place_id=98083231 Pierre De : William Rieck bi...@thinkers.org À : Paul Norman penor...@mac.com Cc : talk-ca talk-ca@openstreetmap.org Envoyé le : Vendredi 21 février 2014 12h09 Objet : Re: [Talk-ca] Updating Langley and use of alt_name? Hi Paul, I was following your message until this statement, where I got confused. Are you saying the city of Langley is not a city? What do you mean by in British English? That's all fairly simple, but the place node is more complicated. Langley is not a city in British English, but a town. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] [OSM-legal-talk] Nouvelle licence de données ouvertes au Québec
CC BY 3.0 and earlier had onerous attribution requirements for data. I believe 4.0 fixes this. I don't think anyone has suggested contacting a data provider who's licensed under CC 4.0 licenses to clarify attribution. The issue with 3.0 attribution are not purely theoretical, there have been providers who have objected to how we have attribution and we've been unable to use their data. Sent from my iPad On Feb 21, 2014, at 1:58 PM, Mike Linksvayer m...@gondwanaland.com wrote: Asking for a clarification that provided attribution is OK seems over the top too, at least for CC-BY, especially CC-BY-4.0, given You may satisfy the [attribution conditions] in any reasonable manner based on the medium, means, and context in which You Share the Licensed Material. If every attribution needs to be clarified with the licensor to determine if it is OK, then attribution licenses truly are a fail. But that practice is certainly not the intent of such licenses. IMO, IANAL, etc etc. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Updating Langley and use of alt_name?
Oups I was wrong in identifiying the polygons in JOSM. These are two adjacent polygons, the city being surrounded by the township. The difference in spelling comes from the alt_name=Langley. I should have mapped for the Night of the living map instead. Or maybe not! Pierre De : Pierre Béland pierz...@yahoo.fr À : William Rieck bi...@thinkers.org; Paul Norman penor...@mac.com Cc : talk-ca talk-ca@openstreetmap.org Envoyé le : Vendredi 21 février 2014 21h53 Objet : Re: [Talk-ca] Updating Langley and use of alt_name? Looking at the Township and City of Langley, I see that these relations are duplicate polygons that share the exact same nodes. Then why two relations? Instead, would it be better to simply use alt_name for the city, added to the Township of Langley. Such Classification where you have two admin_level=8 for the same area is a nonsense to my point of view. To show the inconsistencies that this creates, let's have a look at the Nominatim links below. You will see how the Locality, Suburb, Residential highways etc. are shared between the two. And most of the item are classified under the Township. Some other elements under the City. But searching Nominatims, you will see places classified either und the Township, the City of simply Langley. For example, if you search in Nominatim for * Livingstone, Langley. Canada, this will be reported as Livingstone, Township of Langley, Greater Vancouver Regional District, British-Columbia, Canada * 10 Avenue, Township of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada * Brookswood, Township of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada * 201A Street, Brookswood, Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada The best seems to make a choice for which locality title will be showed to describe Langley and use an alt_name tag to describe the second appellation * City Boundary Township of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada http://www.openstreetmap.org/relation/2031947 http://nominatim.openstreetmap.org/details.php?place_id=9164399767 * City Boundary City of Langley, Greater Vancouver Regional District, Colombie-Britannique, Canada http://www.openstreetmap.org/relation/2031946 http://nominatim.openstreetmap.org/details.php?place_id=98083231 Pierre De : William Rieck bi...@thinkers.org À : Paul Norman penor...@mac.com Cc : talk-ca talk-ca@openstreetmap.org Envoyé le : Vendredi 21 février 2014 12h09 Objet : Re: [Talk-ca] Updating Langley and use of alt_name? Hi Paul, I was following your message until this statement, where I got confused. Are you saying the city of Langley is not a city? What do you mean by in British English? That's all fairly simple, but the place node is more complicated. Langley is not a city in British English, but a town. ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-cz] Opět hlášení chyb (Re: Minimalis_import)
Dne 21.2.2014 00:36, Dalibor Jelínek napsal: Nó. Vidím tabulku přepěknou, kterou filtrovati, řaditi a exportovati do souboru s hodnotami středníčkem oddělenými dle libosti můžu. :-D Nó, vzhledem k tomu, že je tam jedna hodnota, tak filtr a razeni jsou uz ted funkcni a zabudovane implicitne. Je ale fakt, ze export pres Ctrl+C a Ctrl+V ti tam ty stredniky neda. Sakrys. ;-) Jasne,ze tam muzeme dat tabulku, ale vis, co by jsi si predstavoval za sloupce? Ja to nevim. Asi takhle nějak: http://wiki.openstreetmap.org/wiki/Cs:RUIAN/chyby A asi bych se moc nerozvasnoval s nejakym vetsim resenim. Tady http://wiki.openstreetmap.org/wiki/Cs:Import_DIBAVOD to vypada, ze se do hlaseni chyb nikdo moc nehrnul, takze bych tipoval, ze nejaky sledovaci system fakt nema cenu. Ono záleží, kolik toho bude. Třeba bychom mohli dostat množstevní slevu :-D Včera jsem si ze zvědavosti vyzkoušel Tiny Issue. Instalace jednoduchá, i zbytek je jednoduchý. Až moc jednoduchý. Je tam jen možnost zadat Nadpis, popis (Markdown) a někomu to issue přiřadit. Žádné kategorie, filtry, přehledy, nic takového. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Opět hlášení chyb (Re: Minimalis_import)
Ahoj, Asi takhle nějak: http://wiki.openstreetmap.org/wiki/Cs:RUIAN/chyby Uznávám přede všemi, že tvoje řešení je mnohem hezčí. Jen bych tam doplnil sloupec, který by říkal o jakém RUIAN ID se bavíme, aby se daly rozlišit minimálně SO a AM, možná i TEA. Taky bych dával to číslo klikací s odkazem na VDP RUIANu. TinyIssue - je super, že máš zálohu pro případ velkého pracovního nasazení. Zdraví, Dalibor ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Opět hlášení chyb (Re: Minimalis_import)
Dne 21.2.2014 09:20, Dalibor Jelínek napsal: Ahoj, Asi takhle nějak: http://wiki.openstreetmap.org/wiki/Cs:RUIAN/chyby Uznávám přede všemi, že tvoje řešení je mnohem hezčí. Jen bych tam doplnil sloupec, který by říkal o jakém RUIAN ID se bavíme, aby se daly rozlišit minimálně SO a AM, možná i TEA. Taky bych dával to číslo klikací s odkazem na VDP RUIANu. Jo, klikací čísla jsem byl už líný dodělávat :-D Je to jen návrh, sloupce se můžou upravit. Teď mne třeba napadlo, že by tam mohl být i odkaz na odpovídající OSM prvek. Doufám, že je jasné, že ta data jsou ten příklad, žádné takové AM neexistují ;-) TinyIssue - je super, že máš zálohu pro případ velkého pracovního nasazení. Zálohu? Jen jsem si to zkusil. Vycházím totiž z předpokladu, že těch nalezených chyb bude hodně a bude dobré mít v tom přehled. Pak bude potřeba najít pro každou oblast ten správný kontakt, vyexportovat oblast do excelu a poslat. Předpokládám, že existuje nějaký konverzní nástroj Markdown2csv, takže s tím by až takový problém nebyl. Ta tabulka má jednu zásadní nevýhodu. Lze třídit jen dle jednoho sloupce, takže nejde si nechat zobrazit pouze nevyřešené chybějící definiční body z Velké Lhoty. Moudřejší budeme, až se import rozběhne a chyby se začnou hromadit. Marián ___ Talk-cz mailing list Talk-cz@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Opět hlášení chyb (Re: Minimalis_import)
Ahoj, tak ted zase budu chytrej ja. ;-) http://en.wikipedia.org/wiki/Help:Sorting#Secondary_key Pridat odkaz na OSM to asi jo. V jakym formatu? Takhle http://www.openstreetmap.org/way/26376298 Doufám, že je jasné, že ta data jsou ten příklad, žádné takové AM neexistují ;-) Uplne jasny to teda nebylo bal jsem se zeptat, tak jsem to tam radsi nasel. Zdravi, Dalibor -Original Message- From: Marián Kyral [mailto:mky...@email.cz] Sent: Friday, February 21, 2014 9:58 AM To: OpenStreetMap Czech Republic Subject: Re: [Talk-cz] Opět hlášení chyb (Re: Minimalis_import) Dne 21.2.2014 09:20, Dalibor Jelínek napsal: Ahoj, Asi takhle nějak: http://wiki.openstreetmap.org/wiki/Cs:RUIAN/chyby Uznávám přede všemi, že tvoje řešení je mnohem hezčí. Jen bych tam doplnil sloupec, který by říkal o jakém RUIAN ID se bavíme, aby se daly rozlišit minimálně SO a AM, možná i TEA. Taky bych dával to číslo klikací s odkazem na VDP RUIANu. Jo, klikací čísla jsem byl už líný dodělávat :-D Je to jen návrh, sloupce se můžou upravit. Teď mne třeba napadlo, že by tam mohl být i odkaz na odpovídající OSM prvek. Doufám, že je jasné, že ta data jsou ten příklad, žádné takové AM neexistují ;-) TinyIssue - je super, že máš zálohu pro případ velkého pracovního nasazení. Zálohu? Jen jsem si to zkusil. Vycházím totiž z předpokladu, že těch nalezených chyb bude hodně a bude dobré mít v tom přehled. Pak bude potřeba najít pro každou oblast ten správný kontakt, vyexportovat oblast do excelu a poslat. Předpokládám, že existuje nějaký konverzní nástroj Markdown2csv, takže s tím by až takový problém nebyl. Ta tabulka má jednu zásadní nevýhodu. Lze třídit jen dle jednoho sloupce, takže nejde si nechat zobrazit pouze nevyřešené chybějící definiční body z Velké Lhoty. Moudřejší budeme, až se import rozběhne a chyby se začnou hromadit. Marián ___ 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] RUIAN TMS - chybné objekty
Ahoj,
používám v JOSM vrstu budov z RUIAN tms (
tms:http://tile.poloha.net/budovy/{zoom}/{x}/{y}.png )
Někdy vidím vykouslé/přeříznuté budovy pokud jimi prochází
administrativní hranice viz http://i60.tinypic.com/r6wnm9.jpg
Predpokladam ze to uz je chyba v ruian datech, neb tracer to taky tak
vytrasuje i kdyz hranici posunu ( neprichyti se na administrativni
hranici )
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Stránka o RÚIAN
Ahoj, ještě bych si představoval nějakou stránku, kde by byly shrnuty výraznější změny v RÚIAN souborech, aby bylo vidět, co je kde nového. Něco jsem sepsal do této podoby: http://wiki.openstreetmap.org/wiki/Cs:RUIAN/nove_budovy Zdraví Pavel Kwiecien -- Původní zpráva -- Od: Pavel rattsn...@gmail.com Komu: OpenStreetMap Czech Republic talk-cz@openstreetmap.org Datum: 20. 2. 2014 17:42:25 Předmět: Re: [Talk-cz] Stránka o RÚIAN Super nápad :) Díky Dne 20.2.2014 14:26, Dalibor Jelínek napsal(a): Ahoj, snažil jsem se sledovat celou tuhle diskusi o RÚIAN a hodně se v ní ztrácel, tak jsem připravil na Wiki stránku o RÚIAN, jeho záludnostech a hlavně importních projektech. Ještě zdaleka není hotová, ale byl bych rád, kdyby se do ní psali naše zjištění ohledně RÚIAN a kdyby tam každý, který něco z RÚIAN přetahuje nějakým způsobem do OSM přidal svou sekci, kde by popsal co a jak. V neposlední řadě si na ni můžeme zahlasovat o country a is_in. ;-) Třeba zrovna tenhle poznatek o hlášení chyb v RÚIAN by na ni bylo vhodno přidat. http://wiki.openstreetmap.org/wiki/Cs:RUIAN (http://wiki.openstreetmap.org/wiki/Cs:RUIAN) http://wiki.openstreetmap.org/wiki/RUIAN (http://wiki.openstreetmap.org/wiki/RUIAN) Zdraví, Dalibor From: Václav Řehák [mailto:rehak...@gmail.com(mailto:rehak...@gmail.com)] Sent: Thursday, February 20, 2014 2:14 PM To: OpenStreetMap Czech Republic Subject: [Talk-cz] Opět hlášení chyb (Re: Minimalis_import) Dne 20. února 2014 12:33 Marián Kyral mky...@email.cz (mailto:mky...@email.cz) napsal(a): Ještě přemýšlím, co budeme následně dělat se zjištěnými problémy, Chtělo by to nějak konsolidovat a následně hromadně nahlásit, ať se to nemusí dělat po jedné. Myslíš chyby v RÚIANu? Nedělal bych si iluze, že to půjde v rozumné době opravit. Před 9 dny jsem hlásil na stavební odbor Mladé Boleslavi chybějící souřadnice zde: http://vdp.cuzk.cz/vdp/ruian/adresnimista/26713080 (http://vdp.cuzk.cz/vdp/ruian/adresnimista/26713080) Dneska mi volala paní, že daná parcela (myslela asi budovu) má nějak omylem (prý možná už od války) přidělena 2 č.p. a on když tenhle bod umístí, tak se rozbije zas něco jiného. Takže nejdřív chtějí přes evidenci obyvatel obeslat všechny, kdo tu adresu někde úředně uvádí (škola tam má sídlo, možná někdo bydliště) a nějak to vyřešit. Aby se jí nestalo jako minule, že při smazání už zrušeného č.p. udělala z nějakých lidí úřední bezdomovce. Prý jenom v MB se podobné problémy týkají možná 500 adresních míst. Tolik jen ke kvalitě dat v RUIAN, když budeme posuzovat nějaké konflikty s OSM. Jinak jak jsem psal, navrhuju sporné tagy (country, is_in) neřešit, případně se dají doplnit/smazat nezávisle na importu. V. ___ Talk-cz mailing list a href='mailto:Talk-cz@openstreetmap.org'Talk-cz@openstreetmap.org/a a href='https://lists.openstreetmap.org/listinfo/talk-cz'https://lists.openstreetmap.org/listinfo/talk-cz/a ___ 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
