[Talk-hr] Virtualni dan slobodnih i otvorenih tehnologija
U nedjelju 16.3.2014. s početkom u 15:00h bit će održan prvi Virtualni dan slobodnih i otvorenih tehnologija. Kako bi mogli pratiti virtualni dan trebaju vam sljedeći linkovi: HULK onAir youtube kanal gdje ćete moći uživo pratiti predavanja: http://www.youtube.com/channel/UCWoo0bw0zponWhRms1powEQ IRC kanal gdje ćete postavljati pitanja: https://webchat.freenode.net/ IRC korisničko ime - koje želite IRC ime kanala - #hulk-leadership Predavanja će nakon prijenosa uživo ostati na HULK onAir youtube kanalu Detalji na linku ispod: https://www.dropbox.com/s/z2dgi4kn6rkd9ml/VSIOT.pdf RASPORED 15:00 - 15:05 -Otvaranje virtualnog dana- Jasna Benčić 15:05 - 15:35 -Kako se uključiti u svijet slobodnih i otvorenih tehnologija- Lucija Pilići Jasna Benčić 15:35 - 16:05 -Open Street Map- slobodna karta svijeta - Matija Nalis 16:05 - 16:35 -NetBeans i GDB na Linuxu- Domagoj Stolfa 16:35 - 17:05 -Projekt otvorena mreža- Valent Turković 17:05- 17:30 -Razno, otvorena pitanja publike i završna riječ Predavanja će trajati po 20 min, nakon svakog predavanja slijedi10 minuta za pitanja posjetitelja Ksenija ___ Talk-hr mailing list Talk-hr@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-hr
[OSM-talk-be] Knooppunten Limburg
Hoi, Ter info: http://www.toerismelimburg.be/nl/content/werken-op-het-fietsroutenetwerk Eind maart 2014 is de nieuwe fietskaart voor het toeristisch fietsroutenetwerk beschikbaar. Na een periode van 5 jaar zonder grote wijzigingen op het fietsroutenetwerk, gaan er dit jaar heel wat nieuwe knooppunten en aangepaste routes op de kaart komen. Daarom worden er momenteel dan ook een heel aantal nieuwe borden en knooppunten geplaatst langs de Limburgse fietspaden, zodat alles klaar is bij de lancering van de nieuwe fietskaart eind maart. Helaas kan dit wel wat verwarring scheppen bij de fietsers die deze dagen hun fiets reeds uit zijn winterslaap gehaald hebben. Hiervoor onze excuses. Ik ben al een paar nieuwe en verplaatste knoopunten tegengekomen. De fietsers onder ons gaan weer weten wat doen. Groetje, Stijn ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Knooppunten Limburg
On Friday 14 March 2014 11:26:51 Stijn Rombauts wrote: Ik ben al een paar nieuwe en verplaatste knoopunten tegengekomen. De fietsers onder ons gaan weer weten wat doen. Ook in de provincie Antwerpen worden er deze maanden heel wat routes aangepast, dus nog meer werk :-) Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] welcoming new mappers
Hi Jorieke, Thanks for the feedback. I like copy paste, so I will copy your questions and answer them one by one. - now the oldest member is on top, maybe it is interesting to put the newest member on top? Good idea: https://docs.google.com/spreadsheet/pub?key=0Aph66Gc0kPLddEhoSmhUc0Fqbm5HeFk2ZXRMVTFzMUEsingle=truegid=2output=html - is there a possibility we can extend this list with old users? I think this can be interesting to have an overview of all the Belgian mappers. I'm sure Pascal Neis will be able to provide such a list. (I might be in able to do so in a couple of months). I think he uses something like 'main area of activity' to define your country. The question is, what are you going to do with it? You get a bulk list of users, but you still have to send them a message one by one. - are mappers who are creating just one node in Belgium also included in this list? How is it exactly working? There's a neis explanation (pun very much intended) on this webpage: http://neis-one.org/2012/04/where-are-the-new-openstreetmap-contributors/ In short: yes. If your first changeset is in Belgium, you are Belgian, no matter how small the change. Of course, you can do a manual check using the HDYC or userlink. Which I do, to educatedly guess their language. There was one user with just a node, but he changed the name of a shop, so that's a realy useful contribution. - will you add this document somehow to the Belgian wiki? Tell me where, and I will do it. Then again, it's a wiki, so go ahead and copy-paste my diary post anywhere you see fit. - In your welcoming message, you wrote something like type on google wiki OpenStreetMap and what you want to map. I think it is better to point here to the help tab on osm.org My welcoming message is very much my personal take on what's important to know. From may 1st I will be living in a motor home, somewhere deep in countryside South America, so do write your own take on it and start sending it around! I thought about following your suggestion, but I checked. And Google (unfortunately) wins: http://wiki.openstreetmap.org/w/index.php?search=garbage+bintitle=Special%3ASearch(correct answer: no 5) versus https://www.google.be/search?q=wiki+openstreetmap+garbage+binoq=wiki+openstreetmap+garbage+binaqs=chrome..69i57j69i60j69i64l3.6154j0j7sourceid=chromeespv=210es_sm=122ie=UTF-8(correct answer no1). I'm still using Google Maps in those few uses where it's till better than OSM. Please don't burn me at the stake :) And two questions for the rest of you: anyone has 10 minutes a week available to follow up? It is but a copy-paste affair. I would hate to see this die on may 2nd. I need someone with decent (preferably native) French to write a welcome message too. I don't intend to welcome anyone in French with hair upon, if you know what I mean. Joost ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Géomatique Wallonne - strategic plan
Hi Julien, I already read part of your comments but I will try and have a closer look soon... I also received word that OKFN is doing the same. Maybe we could merge this work with theirs? Best Regards, Ben ___ Talk-be mailing list Talk-be@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-legal-talk] HRS.com uses OpenStreetMap-data without credit
Do you have any indication from when the data may be? At least roughly pre/post licence change (pre-licence change data would naturally pose a number of questions)? In general attribution of OSM in the context of non-map uses is not particularly good and hasn't been policed at the same level. We probably need to do the same as for map and give a couple of examples of what we would be happy with. Simon Am 12.03.2014 13:04, schrieb pmsg: Hello, last year, I discovered a strange result when searcing for a hotel near Rostock Seehafen at HRS.com: One suggestion is point of interest - Rostock Seehafen Nord (Außer Betrieb). That is the name of a railway station, as it was once incorrectly tagged in OpenStreetMap. Incorrect because außer Betrieb means no service and should never have been tagged as part of the name. It can easily be verified that HRS.com uses names of railway stations in Germany from OSM for their search. Try also Genshagener Heide, which was/is also tagged incorrectly in OSM. There are several more obvious examples of railway stations in Germany. I cannot find any credit of OpenStreetMap at HRS.com. I assume they are breaching the license. I did inform the company about my assumption on February 18th via off...@hrs.de and received no answer. What steps could be taken? It would be great if HRS.com would add proper attribution and pay OSMF a compensation for the license breach. However, I'm not sure whose rights were infringed, if any. Regards, Nils ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Paweł Paprota writes: Unless you protect and license your work, you *will* be exploited by a powerful corporation. It is not possible for any powerful corporation to exploit OpenStreetMap data. That's because OpenStreetMap is not way #20101312, it is Paweł Paprota. OpenStreetMap is not node #1511064846, it is Richard Weait. OpenStreetMap is not relation #445288, it is Ian Dees. Etc. Someone could take those ways, nodes, and relations and do something with them. We would still have our own copy of them. We would still have Paweł Paprota, Richard Weait, and Ian Dees. Nobody can take that away from us. We cannot be exploited, because we are not the data, we *create* the data. It would not be difficult to change the license, because the choice of license now lies with the OSM Foundation. I would note that one of the potential customers of OSM data -- the USGS -- would require that the data be in the public domain -- which is the license[1] I have always advocated for, from the day I heard about a potential license change. My understanding is that the license is the only thing keeping the USGS from using, and thus contributing to, OSM. [1] Or distribution policy; whatever; not an interesting discussion. --- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Alex Barth writes: http://www.openstreetmap.org/user/lxbarth/diary/21221 Another aspect of where the ODbL hurts us: Because we are using a restrictive license, we cannot argue against other parties that use a restrictive license. Look at New York State's GIS Clearinghouse. Individuals not welcome. For-profit corporations not welcome. OpenStreetMap users not welcome. NY government entities? Welcome! Non-profits? Welcome! We can't argue against that on principle because we're just as bad. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
On Thu, Mar 13, 2014 at 10:26:23AM -0400, Alex Barth wrote: Hello everyone - I've been sitting on writing about the detrimental effects of OpenStreetMap's share-alike license (ODbL) for a while and finally decided to, um, share. I've been listening long to many OpenStreetMappers I respect a ton telling me it's not so bad and it's just what we're stuck with right now. But given how bad share alike is for OpenStreetMap I don't think we should give up for pushing for a more open license. Here's why I think share-alike hurts OpenStreetMap and how this keeps OpenStreetMap from having the full impact it could have: http://www.openstreetmap.org/user/lxbarth/diary/21221 I was in favor of dropping Share-Alike when we switched from CC-BY-SA and all my arguments have come reality. From how many geocoding responses to store it becomes a Database under the Terms of the ODbL etc ... All these uncertinity harms OSM from adoption. Using tiles is simple - Using for more advanced stuff becomes more and more a nightmare. Its all a matter of interpreting the license as other have stated in this thread. I thought we were switching from CC-BY-SA because we didnt want any interpretation anymore. It might be that under some jurisdications the CC-BY-SA would not have hold up but it was the declared will. So with the ODbL we have the same situation but only MUCH MORE complex. And in the End - All those how fear the big bad google for taking our work and earning money with it if we dont make it share alike - Have you followed data contributions lately? Contributions are not coming because people are forced to do so - but because maintainance of data is much easier. This has been the case for the Linux Kernel and this is the same with the OSM Database. (Yes - there were a few litigations concerning the GPL - but compare that to contributions of formerly closed source drivers etc) There was a time when Share Alike was THE only way of forcing other to contribute. This was well before the Internet was a so widespread and the tasks were much smaller. Since 1995 or something we have solved this issue - I am Linux and Open Source _only_ since around that time. 2/3rds of my life i have been using and developing Open Source/Free Software and sharing without any restrictions. Putting a Share Alike on OSM felt like beeing back in the stone ages of early computing - full of fear of the big corps stealing our freedom. I thought we had left this behind. Today maintaining the Linux Kernel or OSM without a HUGE community is a lost fight so there is nothing to gain by taking this data _from_ the community. Those who do this are the ones to loose, not the ones giving away their code/data. IMHO Share Alike is proposed by those full of fear. Instead we should relax and try to make OSM the most useful collection of data for everyone not just the ones beeing able to understand the ODbL. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/14/2014 12:41 AM, Michael Kugelmann wrote: Am 13.03.2014 15:26, schrieb Alex Barth: Looking forward to your comments, No! Stay at Share alike to avoid misuse of open data! Compare it to the GPL which is frequently used in OS-Sortware. Am I correct when I say ODBL is more like LGPL than GPL? Afaik it is ok to use OSM data without any obligations on your work, as long as you don't mix the data. Would that be correct? And to the topic. It might not always be easy to enforce the share-alike clause, but I really like the fact that we have it and may enforce it if necessary. I don't see why this should render OSM non-free. Norbert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIsJeAAoJEN1BMR2v0jNa1akP/id1wZFHEc61zffZMITCsRN6 liKJprbyw8nleb6bBLPBeFAYXkSN/7voO3Xa6Jtr45kVNWSib3rc2FrsF7rFnmJl zMjXNeIBvxyF3afPK1dNMAC1gvhenrtU2bnTKFg4Wg7KO8OgW8zhKe8pw04y8+nq k5MivlDUAXD7A2Oowheh9RkKj+pwY0zjqG7Z+YY6L5KCqw1tGacXdt5Zu7N7EGEe LuoxYCGLYRrUOEjZEGFKdx+u2LjqQNXhCTYujSmElyuQIszb2Njl+2wRzfkxXHYn P4yr/UbOTnFOBNGrUw6Z1NRWN0qC9FFjtgsyMQGJwmZ+4NpMYzXS8AtO1bEZaWji z9pq9Z2xyBJynBuSNlbKGWse7UpYjJ4xPMHP6at6qichRYe+YSIAZz1aYMPHtKhx +LNe/pfHcpyTEwHeay8hUrzVRNwt37ETo1+YXoKi9g+vcNw3VMWerEXLlexaGMWF wMJBNs8xRtw0Ewcuoj0A2tF8T+bwti71I3v9qNLrvaxYrId3ElrncGAXoiCq7cD6 uNt6DUr8AvhQ6a8USr5xBUW6UITpsYIO2VJ1ol/vy4f3+2/1xmkW8AQ2RbqHcJSD jRdxbsf5wWtQ1zTUtrcb4ipjxV7J0v4PYRkc3yQEqKkgflxN7NMhb5sSKRmNZIV0 F+oPiMNUt/MxAn5TIzMu =KvXH -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
With current ODbL I'm mainly concerned about 1. small and medium corporations as well as 2. government entities. I'm not so concerned about big companies, especially G* exploiting OSM (although I dislike some behaviours of G*). So I'm in favor of CC-BY (e.g. http://creativecommons.org/licenses/by/4.0/ ). Yours, Stefan 2014-03-14 9:48 GMT+01:00 Norbert Wenzel norbert.wenzel.li...@gmail.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/14/2014 12:41 AM, Michael Kugelmann wrote: Am 13.03.2014 15:26, schrieb Alex Barth: Looking forward to your comments, No! Stay at Share alike to avoid misuse of open data! Compare it to the GPL which is frequently used in OS-Sortware. Am I correct when I say ODBL is more like LGPL than GPL? Afaik it is ok to use OSM data without any obligations on your work, as long as you don't mix the data. Would that be correct? And to the topic. It might not always be easy to enforce the share-alike clause, but I really like the fact that we have it and may enforce it if necessary. I don't see why this should render OSM non-free. Norbert -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIsJeAAoJEN1BMR2v0jNa1akP/id1wZFHEc61zffZMITCsRN6 liKJprbyw8nleb6bBLPBeFAYXkSN/7voO3Xa6Jtr45kVNWSib3rc2FrsF7rFnmJl zMjXNeIBvxyF3afPK1dNMAC1gvhenrtU2bnTKFg4Wg7KO8OgW8zhKe8pw04y8+nq k5MivlDUAXD7A2Oowheh9RkKj+pwY0zjqG7Z+YY6L5KCqw1tGacXdt5Zu7N7EGEe LuoxYCGLYRrUOEjZEGFKdx+u2LjqQNXhCTYujSmElyuQIszb2Njl+2wRzfkxXHYn P4yr/UbOTnFOBNGrUw6Z1NRWN0qC9FFjtgsyMQGJwmZ+4NpMYzXS8AtO1bEZaWji z9pq9Z2xyBJynBuSNlbKGWse7UpYjJ4xPMHP6at6qichRYe+YSIAZz1aYMPHtKhx +LNe/pfHcpyTEwHeay8hUrzVRNwt37ETo1+YXoKi9g+vcNw3VMWerEXLlexaGMWF wMJBNs8xRtw0Ewcuoj0A2tF8T+bwti71I3v9qNLrvaxYrId3ElrncGAXoiCq7cD6 uNt6DUr8AvhQ6a8USr5xBUW6UITpsYIO2VJ1ol/vy4f3+2/1xmkW8AQ2RbqHcJSD jRdxbsf5wWtQ1zTUtrcb4ipjxV7J0v4PYRkc3yQEqKkgflxN7NMhb5sSKRmNZIV0 F+oPiMNUt/MxAn5TIzMu =KvXH -END PGP SIGNATURE- ___ 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] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
On Friday 14 March 2014, Florian Lohoff wrote: [...] Today maintaining the Linux Kernel or OSM without a HUGE community is a lost fight so there is nothing to gain by taking this data _from_ the community. Those who do this are the ones to loose, not the ones giving away their code/data. Actually the Linux kernel is a good example how big companies abuse free open products. Most famous example is of course Google with Android which circumvents the weak GPLv2 share-alike provisions and contradicts the spirit of the GPL, namely to ensure the right to freely study, modify and redistribute software by locked hardware and closed source modules. But there are many other examples of closed linux systems (like routers, nas, entertainment) that maybe release an alibi source package but without practical means to acutually make modifications. IMHO Share Alike is proposed by those full of fear. It seems to me it is fairly damaging for the aim of abolishing share-alike to assume its proponents are driven by fear. Unless you try to convince people through arguments you have little chance in changing their opinion. Even if you manage to create a non share-alike, 'more free' OSM this will inevitably fail unless you convince the vast majority of the mappers and you cannot do that by telling them to drop their fear and relax. Keep in mind what you are essentially asking mappers here is to waive their right to freely use improvements others make to their mapping work (which is - as Simon pointed out - where share-alike kicks in). You would need good arguments for that i think and i have not heard them to this point. Note i do not have a clear position on the whole matter - as a data user i see clear disadvantages of share-alike and have to deal with them but i see no perspective to convince me, the mapper, to settle without it just because it would be more convenient/more profitable for me, the data user... ;-) -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
One thing I would like to hear about in this context of this discussion, are examples of concrete use cases that are not happening because of share alike and that are in general things that the community would like to support (so not evil corp can't take the data now and keep it). Concrete in the sense that they are uses that really would happen if share alike would be dropped, not we can build a straw man that shows how bad share alike is. Example: one of the classical straw men is that government GIS offices over the whole world would wide spread directly take OSM data and integrate it in to their own official datasets, if you believe that, I have a number of bridges that I would like to sell :-). The more realistic scenario is that difference between their data and OSM would trigger a resurvey on their side, which is already totally OK. Simon ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
2014-03-14 10:58 GMT+01:00 Simon Poole si...@poole.ch: Example: one of the classical straw men is that government GIS offices over the whole world would wide spread directly take OSM data and integrate it in to their own official datasets, if you believe that, I have a number of bridges that I would like to sell :-). The more realistic scenario is that difference between their data and OSM would trigger a resurvey on their side, which is already totally OK. Already happening http://wiki.openstreetmap.org/wiki/Agenzia_mobilit%C3%A0_ambiente_territorio (sorry, it's in Italian) Simon Regards, Stefano ___ 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] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Norbert, 1. Yes, it would be fair to say that ODbL is much closer to LGPL than it is to GPL. The ODbL does not require Share-Alike merely on combining two datasets, but only if you modify the data that's in OSM in addition to adding your own. 2. Using GPG is good. Using GPG without MIME encapsulation is pretty bad. http://www.phildev.net/pgp/pgp_clear_vs_mime.html#pgpmime - Serge ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
On Fri, 14 Mar 2014 10:58:57 +0100, Simon Poole si...@poole.ch wrote: One thing I would like to hear about in this context of this discussion, are examples of concrete use cases that are not happening because of share alike and that are in general things that the community would like to support (so not evil corp can't take the data now and keep it). Concrete in the sense that they are uses that really would happen if share alike would be dropped, not we can build a straw man that shows how bad share alike is. ... On the flip side of this, if share alike is so great where are the examples of organisations contributing back to OSM because of it? Mostly I think organisations contribute because it is in their interest to do so (a better map makes their product better) not because the license says they have to. Share alike adds massive complexity to the license. This seems indisputable to me and just puts another barrier in the way of adoption. IMHO, share alike is just like DRM on music in that it inconveniences legitimate uses of the data but doesn't stop the crooks who will just rip it off anyway regardless of what the license says. Kevin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
To throw another log into the fire: What about imports? OSM having a share-alike licence enabled us to incorporate (and otherwise use) all kinds of open data sets, which may be licensed PD/CC0, CC-BY, CC-BY-SA or ODbL. (A lot of open government data in the EU is released under CC-BY or even share-alike.) If OSM would switch to something more liberal, we would cut us off from potential source material: If we were going to CC-BY our database, we couldn't use CC-BY-SA and ODbL material any more, and if we were going all the way to CC0, anything other than PD/CC0 would be a no-go. Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Am 14.03.2014 12:43, schrieb o...@k3v.eu: ... On the flip side of this, if share alike is so great where are the examples of organisations contributing back to OSM because of it? Mostly I think organisations contribute because it is in their interest to do so (a better map makes their product better) not because the license says they have to. ... Clarification: share alike does not require that you contribute back to OSM. What typically happens is that the companies in question send their users to OSM to make improvements directly in OSM, which is a clear win-win for both parties, Simon ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
On Fri, Mar 14, 2014 at 7:43 AM, o...@k3v.eu wrote: On the flip side of this, if share alike is so great where are the examples of organisations contributing back to OSM because of it? We see this already. I've spoken to companies and orgs who have said specifically that they would not contribute to OSM if it was not Share-Alike. No one wants to be competing against themselves in the future. You don't see it because it's already part of OSM, rather than something new. - Serge ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Simon Poole wrote: One thing I would like to hear about in this context of this discussion, are examples of concrete use cases that are not happening because of share alike and that are in general things that the community would like to support (so not evil corp can't take the data now and keep it). Concrete in the sense that they are uses that really would happen if share alike would be dropped, not we can build a straw man that shows how bad share alike is. Hi Simon, We have considered that we cannot use OpenStreetMap as a background map in any of the applications where users are sending location aware information back to administration. For showing existing data it would be OK but not for gathering data from users because user could locate a place corner of Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at the OSM map. The interpretation of ODbL is that this location is derived from OSM data and thus the database of the administration would become ODbL. It could be OK in some use cases but some data are confidential and ODbL is not an option. Therefore we do not use OSM at all. We use our own services and Google Maps. This is a concrete example. However, changing the interpretation of ODbL into georeferencing locations by looking at OSM map does not yield a derivative database would not necessarily change the situation in Finland any more because since 2012 most raster and vector data from the National Land Survey of Finland have been open data under attribution-only license. Because of this using the data is simple. This has also helped OSM because raster maps and aerial images can be utilized for digitizing and vector data imports have started this year. Jukka Rahkonen- ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Am 14.03.2014 14:17, schrieb Jukka Rahkonen: .. Hi Simon, We have considered that we cannot use OpenStreetMap as a background map in any of the applications where users are sending location aware information back to administration. For showing existing data it would be OK but not for gathering data from users because user could locate a place corner of Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at the OSM map. The interpretation of ODbL is that this location is derived from OSM data and thus the database of the administration would become ODbL. It could be OK in some use cases but some data are confidential and ODbL is not an option. Therefore we do not use OSM at all. We use our own services and Google Maps. Two remarks/questions: - is the derived data actually being publicly used? - Off Topic: the use doesn't seem to be compatible with what is generally known about googles ToS (naturally I assume that is just a question of money) Simon ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
On 14 March 2014 12:01, Martin Raifer tyr@gmail.com wrote: OSM having a share-alike licence enabled us to incorporate (and otherwise use) all kinds of open data sets, which may be licensed PD/CC0, CC-BY, CC-BY-SA or ODbL. (A lot of open government data in the EU is released under CC-BY or even share-alike.) If OSM would switch to something more liberal, we would cut us off from potential source material: If we were going to CC-BY our database, we couldn't use CC-BY-SA and ODbL material any more, and if we were going all the way to CC0, anything other than PD/CC0 would be a no-go. As I understand it, we can't import things under CC-By-SA at the moment anyway, because the ODbL is incompatible. But there is a very valid point there, that it's not just a matter of asking contributors to agree to change the license, we'd need to review all the imported data to check whether or not the licence it was imported under is compatible with whatever license we're wanting to change to. To this end Ithink it's somewhat unfortunate that OSMF/LWG haven't taken a firmer line on the use of third-party data (not just classical imports, but other manual uses of sources) to ensure that the sources and licences they're used under are properly documented. A change to anything more liberal than either CC-By or ODC-By (the attribution-only version of ODbL) would cut out most attribution requiring imports -- crucially, this would cause vast amounts of damage in the UK, where mappers have been using OS OpenData from the National Mapping Agency to enhance OSM in various ways. As for whether share-alike is a good thing, I would note that the contribute back argument probably hasn't helped us all that much so far -- but I think that's as much down to potential data users being slow to accept the benefits of open data. Yes, some potential users are being put off as a result, but I think in time positions may change, and data owners may well come round to accepting the benefits of open data. Also, it's not entirely clear whether allowing more lberal uses would actually benefit the project that much. (Particularly not if we didn't insist on attribution.) What share-alike certainly does do is to stop companies just ripping off our data and not giving anything back to the community. Philosophically and practically, I think this is a very good thing. Overall, I can see that share-alike may be currently holding back some potential users, but it is also helping us by preventing crowd-serfing. Since corporate and government acceptance of opendata is currently still in its infancy, I think it would be premature to switch to a more liberal licence at this stage. We should wait to see how things develop, as the OpenData movement gains further traction, and the quality of OSM relative to other offerings increases. Robert. -- Robert Whittaker ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Hi Jukka, although I'm curious about an answer from someone who's more competent in the legal things, I'm not sure with your argument here. ODBL does not require Share-Alike for produced works. The map, even when based on OSM data is a produced work. Therefore even if the map is based on osm data, it's not share-alike, and any data based on the map IMHO cannot be share-alike too. Let's assume the opposite: - The map is a produced work and may be published on any license (more restrictive as well as more open than ODBL), so let's assume the map is CC-BY (without Share-Alike), - Then from CC-BY it follows that anyone could derive other stuff from that map without being obliged to follow any share-alike clause. So if anyone would require data gathered on top of an osm map to be share-alike, he's wrong (or ODBL contradicts itself in this example in some way). As I assume the ODBL to be checked many times, I assume yet that therefore your implication chain to be wrong and new data collected on top of an osm based produced work is not tainted with share-alike from ODBL. Nevertheless I am not a lawyer, so someone else may proove me wrong If I am. You mention Google Maps as a possible alternative to prevent this problem. I disagree here, too. If you're talking about a substantial amount of data derived from (or above) an OSM based map, the same would be forbidden with google maps data, too. As the terms of service of google state (German version): Sofern Sie zuvor keine schriftliche Genehmigung von Google bzw. dem Anbieter der betreffenden Inhalte erhalten haben, dürfen Sie (a) den Inhalt weder ganz noch teilweise kopieren, übersetzen, abändern oder abgeleitete Werke daraus erstellen translated by me: without written permission of Google or the affected data providers your are not allowed to copy (in parts or as a whole), translate or modify the content or produce derived works from it. Therefore the same as for OSM holds for any content of Google Maps, and you probably should think about using Google as an alternative from a legal point of view. regards Peter Am 14.03.2014 14:17, schrieb Jukka Rahkonen: Simon Poole wrote: One thing I would like to hear about in this context of this discussion, are examples of concrete use cases that are not happening because of share alike and that are in general things that the community would like to support (so not evil corp can't take the data now and keep it). Concrete in the sense that they are uses that really would happen if share alike would be dropped, not we can build a straw man that shows how bad share alike is. Hi Simon, We have considered that we cannot use OpenStreetMap as a background map in any of the applications where users are sending location aware information back to administration. For showing existing data it would be OK but not for gathering data from users because user could locate a place corner of Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at the OSM map. The interpretation of ODbL is that this location is derived from OSM data and thus the database of the administration would become ODbL. It could be OK in some use cases but some data are confidential and ODbL is not an option. Therefore we do not use OSM at all. We use our own services and Google Maps. This is a concrete example. However, changing the interpretation of ODbL into georeferencing locations by looking at OSM map does not yield a derivative database would not necessarily change the situation in Finland any more because since 2012 most raster and vector data from the National Land Survey of Finland have been open data under attribution-only license. Because of this using the data is simple. This has also helped OSM because raster maps and aerial images can be utilized for digitizing and vector data imports have started this year. Jukka Rahkonen- ___ 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] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Hi, On Fri, Mar 14, 2014 at 10:58:57AM +0100, Simon Poole wrote: One thing I would like to hear about in this context of this discussion, are examples of concrete use cases that are not happening because of share alike and that are in general things that the community would like to support (so not evil corp can't take the data now and keep it). Concrete in the sense that they are uses that really would happen if share alike would be dropped, not we can build a straw man that shows how bad share alike is. I can tell on my own base. I work for a company which does FTTH/VDSL2 infrastructure operation and planning. Internally i am playing with OSM Data mixed with other Telecoms infrastructure data - Using OSRM to calculate infrastructure distances e.g. DSL Speeds etc., construction costs of FTTC, FTTH projects. Never ever that mixed infrastructure data will be available under ODbL. Although the produced work might be interesting to detect internet white spots i cant give it out of my Hands. So it'll stay as little toy project of mine. Whenever there is a need to produce stuff off my hands i'd need to buy commercial map/geodata material. It a matter of fact that i'd need to pay lawyers and find complicated ways to use OSM - So i dont. Complex Licenses or uncertainty is enough for me to not go down that path. Flo -- Florian Lohoff f...@zz.de signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Simon Poole wrote: Two remarks/questions: - is the derived data actually being publicly used? Sometimes is, sometimes not. If it is publicly used then it may be that only part of the attributes are public. Something that is not publicly used right now may come public in the future but still not with all the attributes. With the maps from the National Land Survey there is no need to worry about all that. Unfortunately there is not yet infrastructure for making the use of NLS maps as easy as OSM or Google and that is a trouble for small municipalities, for example. - Off Topic: the use doesn't seem to be compatible with what is generally known about googles ToS (naturally I assume that is just a question of money) I haven't heard about any troubles with Google's ToS and I know that lawyers have been used for checking that. Don't know about money. -Jukka Rahkonen- Simon ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Hate captchas!!!!
Hi, is there really no way to avoid those horrible captchas whenever I add a link to a JOSM bug ticket or another friendly website to the wiki?? There are at least 2 tickets open which could help a lot: *https://trac.openstreetmap.org/ticket/5116 *https://trac.openstreetmap.org/ticket/3898 I need on average 4 captcha-reloads before I get a captcha picture which I can recognise with good enough confidence to even try it. How about an OSM quiz instead of captchas? Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Talk-us] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
I disagree. This is about money; my personal belief is that CloudMade would have made more dollars without having to ShareAlike. More business models open up, and it wouldn’t have had to deal with the community. Indeed I imagine this was a topic of continual discussion. The ODbL requires only two things and my understanding is that MapBox disagree with both of them, or at least Alex does. This shouldn’t be surprising, they hinder making money, like it did for CM. But in those cases, we’re talking about competition in the market via data sets. My personal belief, not speaking for them, is that Telenav has a different focus, in that free-to-the-consumer turn-by-turn navigation doesn’t have these impediments. Therefore it would in theory not be an issue in our case to attribute and ShareAlike. Like in my original slides about OSM from years ago - it’s about moving up the stack and competing at a higher level, not competing over data itself (where attribution and ShareAlike are relevant). Instead, going all-in on OSM and focusing on the product and user experience. Remember, these problems only occur if you don’t want to use OSM, but want to use it with other datasetsets that you don’t want to contribute back. As for legal opinions on the ODbL you should understand that weaker (or, really, any) lawyers don’t like new things. New un-tested things have the potential to blow up in your face and throw you in court. Therefore the calculus is different when you are small and court is a scary place, compared to if you’re a big company say like Microsoft and you’re in court all the time. In my time I’ve met plenty of lawyers who’re fine with the ODbL and it shouldn’t be characterized that all lawyers everywhere somehow have major problems with it. The community norms (and the new ones the LWG is apparently putting together I heard) help very much here, and of course there are always issues with any license. Whether the ODbL is good or bad for OSM is a different question. The ODbL was a very fun multi-year process that I happen to have been deeply involved in. It would be nice if there was data to suggest that one license is measurably better than another (for OSM). Instead, we have a large collections of anecdotes (not data) like “nobody uses OpenBSD because of the license” or “Linux wins because of the license”. We’ve had beliefs like that in the past. For example “lots more people would edit with nicer tools”. This is a belief I shared. So, multiple times, we’ve built nicer tools. And it’s turned out that there is some small grain of truth to that but it’s not really comparable to the effort involved. I was wrong. Alex makes a bunch of these statements like that, I’ll pick three that jump out: 1) the assumption that share-alike encourages contribution is a myth” 2) The reality is that OpenStreetMap is only used extensively in situations where the share-alike license does not apply, for instance, map rendering. 3) OpenStreetMap's current licensing is stunting our growth And respond: 1) Data would be useful either way 2) I’d say that’s because OSM doesn’t contain a lot of address or navigation data (which, as it happens, is where the money is), not because of the license. 3) My personal belief is it might stunt CloudMade or MapBox, but not Telenav or MapQuest, and, http://wiki.openstreetmap.org/wiki/Stats doesn’t show a lot of evidence of being stunted. ct. I’ll sum by saying that when you’re picking licenses you’re really picking business models. We should be very careful when considering license changes and make sure any choice is backed by the best data we can get, not anecdotes or nice sounding stories. The ODbL has got us this far, and all the graphs are up-and-to-the-right. Exponential curves are powerful. Lastly, consider the weight of effort thousands of people put in to mapping before you to get us here, and what terms they did it under. Steve On Mar 14, 2014, at 1:18 AM, Russ Nelson nel...@crynwr.com wrote: Alex Barth writes: http://www.openstreetmap.org/user/lxbarth/diary/21221 Another aspect of where the ODbL hurts us: Because we are using a restrictive license, we cannot argue against other parties that use a restrictive license. Look at New York State's GIS Clearinghouse. Individuals not welcome. For-profit corporations not welcome. OpenStreetMap users not welcome. NY government entities? Welcome! Non-profits? Welcome! We can't argue against that on principle because we're just as bad. -- --my blog is athttp://blog.russnelson.com Crynwr supports open source software 521 Pleasant Valley Rd. | +1 315-600-8815 Potsdam, NY 13676-3213 | Sheepdog ___ Talk-us mailing list talk...@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ talk mailing list talk@openstreetmap.org
Re: [OSM-talk] Hate captchas!!!!
What I saw on Tuesday seem to indicate that ReMAPTCHA (Stefan?) is nearly here. As the name says it is map related. Unluckily it is still a pain to use if you have problems with your eyesight, but at least you are not working for google at the same time. Simon Am 14.03.2014 16:06, schrieb Richard Z.: Hi, is there really no way to avoid those horrible captchas whenever I add a link to a JOSM bug ticket or another friendly website to the wiki?? There are at least 2 tickets open which could help a lot: *https://trac.openstreetmap.org/ticket/5116 *https://trac.openstreetmap.org/ticket/3898 I need on average 4 captcha-reloads before I get a captcha picture which I can recognise with good enough confidence to even try it. How about an OSM quiz instead of captchas? Richard ___ 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] Hate captchas!!!!
On 14.03.2014 16:06, Richard Z. wrote: Hi, is there really no way to avoid those horrible captchas whenever I add a link to a JOSM bug ticket or another friendly website to the wiki?? How about interlinks ? JOSM Trac has some for most common external website (OSM, OSM-wiki, OSM-Trac etc.) This is also needed to stay on the same protocol (https) There are at least 2 tickets open which could help a lot: *https://trac.openstreetmap.org/ticket/5116 *https://trac.openstreetmap.org/ticket/3898 I need on average 4 captcha-reloads before I get a captcha picture which I can recognise with good enough confidence to even try it. How about an OSM quiz instead of captchas? colliar signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
On 14/03/14 15:06, Richard Z. wrote: How about an OSM quiz instead of captchas? You're offering to write one I take it? Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
On Fri, Mar 14, 2014 at 03:43:38PM +, Tom Hughes wrote: On 14/03/14 15:06, Richard Z. wrote: How about an OSM quiz instead of captchas? You're offering to write one I take it? will think about one. In the short term, there are open tickets which should make it a lot easier Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
On 14/03/14 15:50, Richard Z. wrote: On Fri, Mar 14, 2014 at 03:43:38PM +, Tom Hughes wrote: On 14/03/14 15:06, Richard Z. wrote: How about an OSM quiz instead of captchas? You're offering to write one I take it? will think about one. In the short term, there are open tickets which should make it a lot easier Well 5116 doesn't actually specify what it is you actually the admins to do. It asks for known good URLs to be whitelisted without actually defining what constitutes a known good URL. Since I'm pretty sure that both known good and known bad are infinite sets, even if anybody could agree what constituted good or bad in this context, it is really very helpful. I'm sure if you make concrete suggestions for URLs that should be whitelisted then somebody will consider them. I'm not exactly sure what 3898 is asking for because I'm not familiar with the details of that config option, but it sounds like it is just asking for the captcha to be switched off. I'm sure that would be lovely for the real wiki users. I'm equally sure it would be lovely for the spammers, so it's not really a solution for anything. Certainly neither of those tickets seems to represent something trivial or concrete that could be actioned immediately in the way you are implying. Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
On 14.03.2014 17:01, Tom Hughes wrote: On 14/03/14 15:50, Richard Z. wrote: On Fri, Mar 14, 2014 at 03:43:38PM +, Tom Hughes wrote: On 14/03/14 15:06, Richard Z. wrote: How about an OSM quiz instead of captchas? You're offering to write one I take it? will think about one. In the short term, there are open tickets which should make it a lot easier Well 5116 doesn't actually specify what it is you actually the admins to do. It asks for known good URLs to be whitelisted without actually defining what constitutes a known good URL. Since I'm pretty sure that both known good and known bad are infinite sets, even if anybody could agree what constituted good or bad in this context, it is really very helpful. I'm sure if you make concrete suggestions for URLs that should be whitelisted then somebody will consider them. I'm not exactly sure what 3898 is asking for because I'm not familiar with the details of that config option, but it sounds like it is just asking for the captcha to be switched off. I'm sure that would be lovely for the real wiki users. I'm equally sure it would be lovely for the spammers, so it's not really a solution for anything. Certainly neither of those tickets seems to represent something trivial or concrete that could be actioned immediately in the way you are implying. How about interwiki links to *.wikipedia.org, *.openstreetmap.org and josm.openstreetmap.de for a start ? Could be first in the whitelist but interwiki links would be much nicer. cu colliar signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
On Fri, Mar 14, 2014 at 9:15 PM, Serge Wroclawski emac...@gmail.com wrote: We see this already. I've spoken to companies and orgs who have said specifically that they would not contribute to OSM if it was not Share-Alike. No one wants to be competing against themselves in the future. This is actually a pretty good argument for share-alike.By having share-alike, a company that pours time, money, and effort into improving the database will not inadvertently help a competitor that would not give anything back. Sure, a CC-BY or even CC0/PD license is freer than a share-alike license, but only for a data user in isolation (they don't have any onerous obligations and that's freer). But, share-alike ensures that the freedom is sustainable for *everybody* in perpetuity and not just single users. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
On 14.03.2014 17:15, Tom Hughes wrote: I think most of those are already whitelisted aren't they? Unless I'm mistaken, these are the currently whitelisted URLs: http://wiki.openstreetmap.org/wiki/MediaWiki:Captcha-addurl-whitelist ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
2014-03-13 15:26 GMT+01:00 Alex Barth a...@mapbox.com: I've been sitting on writing about the detrimental effects of OpenStreetMap's share-alike license (ODbL) for a while and finally decided to, um, share. I've been listening long to many OpenStreetMappers I respect a ton telling me it's not so bad and it's just what we're stuck with right now. But given how bad share alike is for OpenStreetMap I don't think we should give up for pushing for a more open license. Here's why I think share-alike hurts OpenStreetMap and how this keeps OpenStreetMap from having the full impact it could have: http://www.openstreetmap.org/user/lxbarth/diary/21221 I had a question, starting from this: «Ever tried to get an actual lawyer to provide guidance on the ODbL? That's what I'm talking about. Tried to use the OpenStreetMap Wiki to learn about how the ODbL is interpreted by the licensor, the OpenStreetMap Foundation? That's what I'm talking about.» How many cases of litigation in court over ODbL licensed data do we know about so far? Cristian An interested Wikipedian and mapper. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
On Fri, Mar 14, 2014 at 07:12:13PM +0100, Tobias Knerr wrote: On 14.03.2014 17:15, Tom Hughes wrote: I think most of those are already whitelisted aren't they? Unless I'm mistaken, these are the currently whitelisted URLs: http://wiki.openstreetmap.org/wiki/MediaWiki:Captcha-addurl-whitelist great, hope that will work. Richard ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
Richard Z. ricoz.osm at gmail.com writes: I need on average 4 captcha-reloads before I get a captcha picture which I can recognise with good enough confidence to even try it. You only have to type the right number for the distorted figures. You can type whatever you like for the photograph. -- Andrew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
Andrew, ha, as a rule, you can recognize a photo but not a distorted figures. 2014-03-14 22:50 GMT+01:00 Andrew Hain andrewhain...@hotmail.co.uk: Richard Z. ricoz.osm at gmail.com writes: I need on average 4 captcha-reloads before I get a captcha picture which I can recognise with good enough confidence to even try it. You only have to type the right number for the distorted figures. You can type whatever you like for the photograph. -- Andrew ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk -- Thank you for your time. Best regards. Dmitry. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Hate captchas!!!!
2014-03-14 16:19 GMT+01:00 Simon Poole si...@poole.ch: What I saw on Tuesday seem to indicate that ReMAPTCHA (Stefan?) is nearly here. As the name says it is map related. Wonderful idea! There's a demo/the code somewhere? Cristian ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
On 14/03/2014, o...@k3v.eu o...@k3v.eu wrote: On the flip side of this, if share alike is so great where are the examples of organisations contributing back to OSM because of it? There's one fairly obvious to me : the share-alike requirement is necessary to enforce the attribution requirement (otherwise any user could just change the license to one that doesn't require attribution). And that (c) osm visible in all the websites that use osm, be it fousquare or my cat's blog, is a very powerfull tool to gain recognition, users, and contributors. Without share-alike, companies would listen to their web designers and remove the ugly and useless attribution. Mostly I think organisations contribute because it is in their interest to do so (a better map makes their product better) not because the license says they have to. The user's best interest is the carrot, but the license is the stick. There's no harm using both, it's actually better. I certainly hope that the carrot is the main reason why people contribute :) But the stick has been needed many times as well. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
On 14/03/2014, Jukka Rahkonen jukka.rahko...@latuviitta.fi wrote: For showing existing data it would be OK but not for gathering data from users because user could locate a place corner of Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at the OSM map. The interpretation of ODbL is that this location is derived from OSM data and thus the database of the administration would become ODbL. To me that's a very strict/paranoiac interpretation of the odbl. Especially if locations are looked up on a raster rendering, rather than matched with vector data. As it turns out, OSM itself has decided to use that paranoiac interpretation when looking at aerial imagery for example. Because we need to be paranoiac when using other people's data. But when other people are using our data, we could appease their paranoia if the OSMF released a list of interpretation for the tricky corner-cases. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
On Mar 14, 2014 8:24 AM, Jukka Rahkonen jukka.rahko...@latuviitta.fi wrote: Simon Poole wrote: One thing I would like to hear about in this context of this discussion, are examples of concrete use cases that are not happening because of share alike and that are in general things that the community would like to support (so not evil corp can't take the data now and keep it). Concrete in the sense that they are uses that really would happen if share alike would be dropped, not we can build a straw man that shows how bad share alike is. Hi Simon, We have considered that we cannot use OpenStreetMap as a background map in any of the applications where users are sending location aware information back to administration. For showing existing data it would be OK but not for gathering data from users because user could locate a place corner of Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at the OSM map. The interpretation of ODbL is that this location is derived from OSM data and thus the database of the administration would become ODbL. It could be OK in some use cases but some data are confidential and ODbL is not an option. Therefore we do not use OSM at all. We use our own services and Google Maps. Foursquare uses OSM (and Google maps, depending on which app screen you are in) to derive/verify venue locations. Toby ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Postbussen
Hallo! TL;DR: Is het een goed idee om te proberen de lijst van brievenbussen van PostNL los te peuteren en te importeren in OSM? Ik zie dat ik brievenbussen op de kaart toe kan voegen, maar ik ben er nog geen enkele tegengekomen, laat staan compleet met lichtingsmomenten zoals ze wel op de PostNL site staan. --- Ik ben nieuw hier dus even voorstellen: Ik ben Luc (OSM username lucb1e), doe een hbo ict opleiding in het zuiden van het land, en ben een open-source fan. OSM vind ik een interessant project en ik wil best wat meehelpen door gebieden die ik ken te verbeteren. Misschien dat ik ook links en rechts wat aan bekendheid ga doen. Een ding wat me opviel was dat er weinig brievenbussen op de kaart staan, terwijl PostNL daar gewoon een database voor heeft (er is een zoekfunctie op hun site). Ik heb ernaar gezocht in alle uithoeken van de site, maar er lijkt geen (indexeerbare) lijst te zijn. Vandaag heb ik daarom PostNL gebeld, kort uitgelegd wat OSM is, en gevraagd of ze een lijst van brievenbussen hebben. Meneer had deze niet, en ik werd geadviseerd om PostNL een verzoek per post te sturen (de ironie). Voordat ik mijn tijd en postzegels ga verdoen aan verdere acties ben ik meer gaan lezen over imports, en al snel las ik dat imports soms zelfs negatief zijn in bepaalde gebieden en ik beter eerst de lokale community kan vragen. Dus bij deze: denken jullie dat het nuttig is om brievenbussen op de kaart te zetten? Ik vind het opzich wel leuk om te proberen om deze dataset los te krijgen, dus tenzij het liever niet is ga ik er waarschijnlijk mee verder. Tips zijn ook welkom trouwens. Overigens, mailinglists zijn wel niet helemaal mijn ding en het is pas de tweede keer dat ik naar een lijst post, dus verbeter a.u.b. (netiquette) fouten als ik die maak! Thanks, Luc ___ Talk-nl mailing list Talk-nl@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-ie] mapping roads
I got nothing back. Didn't follow it up. On 14 Mar 2014, at 19:50, Daniel Cussen d...@post.com wrote: I've just got a response from An Garda that my request has been passed up the chain. Fingers crossed. Donie Donie Did you ever get an official response from the Gardai regarding your request to use the data from Gardai.ie speedzones? I am very interested in putting in this data too. If we get the official NO then we can begin mapping them ourselves and proactively seeking them out and marking them. I travel on national routes countrywide quite often so I could start getting the GPS positions of the signs on each side of the road, if we cannot use the Gardai info. So the first thing should be to get an official respose, and if it is yes then it should be easy to map the zones http://wiki.openstreetmap.org/wiki/Tag:highway%3Dspeed_camera http://wiki.openstreetmap.org/wiki/Relation:enforcement On 14/03/2014, Donie Kelly donie.ke...@gmail.com wrote: Can we add the restricted speed zones? The ones the go safe cameras are on? Just the speed limits on those stretches? I'm working on an app for the speed zones and I'd like to be able to pop up the speed limits as they are not always signed. I can statically scan for updates to release to the app when updates on the roads are implemented. Any objections on using the data for this? Donie On 14 Mar 2014, at 18:27, da fo43 daf...@outlook.com wrote: Hello All, First time posting on the mailing list but I've spoken individually to a number of you already. There can't be too many roads still to map in Ireland now so I guess the next step would be to improve the quality by filling in road numbers, names, etc. So I'm going to propose a few standards and see what people think. 1. Map L roads 1000 to 4999 (Local Primary) as 'Tertiary' and all other public roads as 'Unclassified' or 'Residential'. I know people have a lot of differing views on this and will admit that some local primary roads seem to have less importance than Local Secondary and Local Tertiary roads but really I think it's better to go with what is designated rather than making judgement calls. On some parts of the map all roads are being set to 'Tertiary' so really I don't think the current system works. All other roads are mapped as per designation so I personally don't see why this should be any different. 2. Labeling roads L1000- with spaces. I see on some parts of the map that roads are being labelled with a space 'L 1234' instead of 'L1234'. I would be in favour of sticking to one standard, and going with the majority in not using a space. 3. Labeling roads over L. I propose the labeling roads listed as L12341 as L1234-1 as this makes it easier to read and work out which branch of primary/secondary road it belongs to. I guess this might not suit everyone. 4. Non public roads to be displayed as 'Service' or 'Track' only. It's not always obvious if some roads are private (especially some housing estates) but where it is known for certain they are private then I would be in favour of using a 'service' road rather than 'residential' or 'unclassified'. Hopefully we can agree on some things and apologies if I have overwritten anyone's work recently, it's certainly not my intention to do so and I will go with whatever the consensus is. Lastly I was planning on making some small updates to the Wiki page, just a general cleanup on removing dead links and adding a sat nav section, if anyone has any objections please let me know. David ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie ___ Talk-ie mailing list Talk-ie@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ie
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
PessoALL, Sou do Rio de Janeiro e estou dando manutenção no OSM desde novembro de 2013 (estou aprendendo bastante!) e vim pedir ajuda, principalmente aos colaboradores do Rio de Janeiro que conhecem bem os trechos que irei falar... Fiquei bastante contente ao conseguir minha primeira compilação, depois de algumas tentativas e erros, finalmente tenho um script que roda liso. Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Mapa RJ: A ponte Rio/Niterói só vai até a ilha de Mocanguê sentido Niterói/Rio e aparece uma outra estrada ao lado que parece ser ela. O contorno da orla vindo pela Av. do Contorno está dentro d'água e vai assim por toda orla de Niterói, as ruas da Ilha da Conceição(Niterói) estão sobre a Baia de Guanabara. Tracei uma rota de São Gonçalo (onde moro) até João Pessoa e para minha surpresa, o GPS começa a rota por uma estrada(possivelmente a BR-101) só que pelo meio de São Gonçalo e não pela orla (onde ela realmente passa), esta estrada virtual no visual fica por baixo do mapa, só aparece em alguns trechos. Mapa Brasil: A ponte Rio/Niterói aparentemente está correta. Porém a estrada virtual aparece no meio de São Gonçalo e os problemas visuais da orla, ruas dentro d'água continuam. Os mapas disponíveis no projeto COCAR estão com os mesmos problemas, e o do site oficial do OSM tem um problemas parecido no bairro de Alcantara/São Gonçalo, algumas ruas não aprecem no mapa compilado (no GPS). Obrigado pela atenção, Hélio Coutinho. Date: Tue, 11 Mar 2014 11:21:56 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download 335 é o código IBGE para SP. Na verdade 35. O 3 a mais seria região sudeste. Isso é para nos certificar de que não haja colisão de IDs caso o usuário instale mais de um mapa. O do RJ é 333. Mas esse código poderia ser qualquer um que quiséssemos inventar, desde que seja único. Colocarei um link lá no Cocar. Aliás tenho que fazer uma página com a relação de mapas, (que tende a crescer) e citar a cortesia. Os links no menu não vão dar certo. [ ]s e obrigado. Paulo 2014-03-11 9:43 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: --mapid não existe Para family-id e product-id, tem algo em específico para serem 335? Tirando isso, o de SP está aqui: http://naoliv.iq.unesp.br/mapas/gmapsupp.img ___ 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 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Why Imports in OpenStreetMap Are Controversial
Há um novo texto no blog do Serge sobre a dificuldade de manutenção de dados importados no OSM: http://blog.emacsen.net/blog/2014/03/13/the-maintenance-of-imported-data-in-openstreetmap/ On 04-02-2014 19:59, Wille wrote: Compartilho um texto muito bom sobre a questão das importações no OSM: http://blog.emacsen.net/blog/2014/01/25/why-imports-in-openstreetmap-are-controversial/ ___ 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] São Paulo capital, tag reg
Taí uma tag que eu nunca entendi como preencher, REF Sempre que rodo o validador do JOSM, aparecem críticas relacionadas. E é tanta coisa colocada lá que fica dificil saber o que é mesmo para ficar. Marcelo 2014-03-13 23:53 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: On Thu, Mar 13, 2014 at 11:47 PM, Erick de Oliveira Leal erickdeoliveiral...@gmail.com wrote: http://www.openstreetmap.org/way/38709823 http://www.openstreetmap.org/way/237689576 Parece o CEP http://www.openstreetmap.org/way/16973487 http://www.openstreetmap.org/way/37396062 http://www.openstreetmap.org/way/154255950 Inicial de quem inseriu (pedro vida torta - PVT). Pode apagar (é considerado graffiti) Aproveita e manda mensagem para a pessoa parar com isso. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- ... Edileuz, eu não tem nada a ver com Creuza, É mentira da Ivete, não é meu esse caniveete... Halley, Luiz - Poeta, Cantor, Compsitor ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] São Paulo capital, tag reg
ref é uma etiqueta genérica para Código de referência (corrijo o que disse antes, não é número, é código). Assim como para a etiqueta name, tem outras etiquetas relacionadashttp://wiki.openstreetmap.org/wiki/Refpara usos similares, como loc_ref, old_ref, ref:* e outros. A etiqueta ref pode ser utilizada para coisas como números de saída de uma rodovia(junto com motorway_junction=*) e código de identificação de pontos de ônibus. Não é algo tão comum assim de usar. Abs, João Em 14 de março de 2014 09:12, Marcelo Pereira pereirahol...@gmail.comescreveu: Taí uma tag que eu nunca entendi como preencher, REF Sempre que rodo o validador do JOSM, aparecem críticas relacionadas. E é tanta coisa colocada lá que fica dificil saber o que é mesmo para ficar. Marcelo 2014-03-13 23:53 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: On Thu, Mar 13, 2014 at 11:47 PM, Erick de Oliveira Leal erickdeoliveiral...@gmail.com wrote: http://www.openstreetmap.org/way/38709823 http://www.openstreetmap.org/way/237689576 Parece o CEP http://www.openstreetmap.org/way/16973487 http://www.openstreetmap.org/way/37396062 http://www.openstreetmap.org/way/154255950 Inicial de quem inseriu (pedro vida torta - PVT). Pode apagar (é considerado graffiti) Aproveita e manda mensagem para a pessoa parar com isso. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- ... Edileuz, eu não tem nada a ver com Creuza, É mentira da Ivete, não é meu esse caniveete... Halley, Luiz - Poeta, Cantor, Compsitor ___ 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] São Paulo capital, tag reg
2014-03-14 9:12 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Taí uma tag que eu nunca entendi como preencher, REF De forma bem resumida, no Brasil ref vai ser comumente utilizada nas saídas de rodovias (quando na placa tem Saída 430A você vai colocar 430A na ref) e nas rodovias (por exemplo, SP-300 ou BR-101). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] São Paulo capital, tag reg
Alterei a tradução de *Reference* no editor iDhttps://www.transifex.com/projects/p/id-editor/translate/#pt_BR/presets/11487835?q=refpara Código de referência. Em 14 de março de 2014 09:23, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-03-14 9:12 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Taí uma tag que eu nunca entendi como preencher, REF De forma bem resumida, no Brasil ref vai ser comumente utilizada nas saídas de rodovias (quando na placa tem Saída 430A você vai colocar 430A na ref) e nas rodovias (por exemplo, SP-300 ou BR-101). ___ 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] Kit para compilação Garmin em Windows e mapas Garmin para download
2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Eu uso http://gaemin.openstreetmap.nl/ Depois um tempo p gerar (muitos vezes instantanio) a mapa com qualquer poligonio voce quer ser disponível, geralmente gerando somente Brazil, mas dezembro passado girei Brazil com Portugal no mesmo mapa Os arquivos e disponíveis em os mais usados formatos p garmin, eu teve nenhuma problema instalar atravez windows ou mac Aun Johnsen On Mar 14, 2014, at 10:03, Nelson A. de Oliveira nao...@gmail.com wrote: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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] Validador nacional
Osmanianos, Lendo a frase Rivers and streams should not be tagged with layer -1 along long sections of their length, eu entendo que a tag layer NÃO deve ser usada em longas seções de rios e ( seja-lá-o-que-for ) streams. Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em uma camada diferente da entidade que ele cruza. Mais uma frase : A bridge is at layer 1 even if it is only several feet above sea level while the peak of Mount Everest is at layer 0 even though it is 8848 meters above sea level. Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que é o default e por isso não recomendado explicitar, e só se registra layer onde houver claramente uma diferença de camada em um cruzamento. Assim ... Um exemplo prático e mais extremo: suponha que seja um rio com várias pontes atravessando-o, como é o caso do arroio Dilúvio em Porto Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra constar: eu revisei uma por uma, e mapeei as que faltavam.) Usando a minha interpretação da frase inicial, o uso neste exemplo dado pelo Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1 em todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos ou pontos, não em toda sua extensão. E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da terra ( layer=0), o elemento adicional são as pontes. Adicionando uma questão a discussão, que diferença faz usar layer=1 na ponte ou layer=-1 no rio ? - Pra renderização o que ficaria melhor ? - Pra roteamento, o que funcionaria melhor ? - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Marcelo P Em 14 de março de 2014 06:58, Flavio Bello Fialho bello.fla...@gmail.comescreveu: Fernando, acho que não entendeste. Leia a página http://wiki.openstreetmap.org/wiki/Key:layer com calma. Ela diz explicitamente: Do not use layer=-1 to hide warnings about crossing or overlapping ways. Either fix them or leave the easily visible warning so that others can fix them. When ways are passing on different levels apply layer=* only to the way which also has the bridge/tunnel attribute. Only ways with one of the tags/attributes tunnel=*, bridge=*, highway=steps, highway=elevator, covered=* should be tagged with the layer tag, similar for railways and waterways. Rivers and streams should not be tagged with layer -1 along long sections of their length Eles estão dizendo explicitamente para NÃO fazer isso que queres fazer. Se tens alguma dúvida, discuta na comunidade internacional. Esse é o meu último post sobre esse assunto. Em 14 de março de 2014 02:08, Fernando Trebien fernando.treb...@gmail.com escreveu: Mais além: na verdade, em alguns casos, chega a ser pior marcar as pontes com layer=1 porque isso altera a priorização da renderização no Mapnik. Por exemplo, highway=secondary_link com layer=1 é renderizado por cima de highway=primary (com ou sem layer=0). Isso é o oposto do normal e faz o desenho ficar feio. Mas o Mapnik não é o único parâmetro. No wiki diz que algumas ferramentas de QA (mas não todas) exigem que o rio tenha layer=-1 e a ponte tenha layer=1. Nada no restante do artigo sugere que isso é, de fato, necessário (pelo contrário). Pra mim, parece uma escolha arbitrária sem muita justificativa (ou seja, um dogma). Colocar layer=-1 no rio ou layer=1 na ponte estão ambos corretos, mas frequentemente uma das opções requer menos trabalho e resulta numa representação menos complexa. E se o próprio artigo diz que não é necessário colocar layer=0 nos casos em que seria esse o valor, me parece que o ideal é, quase sempre, marcar o rio com layer=-1, e nada mais. Claro, daí algumas pessoas poderiam pensar que não precisam marcar a ponte que passa por cima. Por isso concordo que o validador nacional aponte esses casos como aviso - que deve ser interpretado com bom senso (assim como os demais avisos do validador do JOSM) de acordo com a definição da tag, não necessariamente como erro. On Mar 14, 2014 1:34 AM, Fernando Trebien fernando.treb...@gmail.com wrote: Só complementando, o que layer=0 realmente significa é: desenhe este objeto depois dos que têm layer=-1, e antes dos que tÊm layer=1. Não significa nada além disso. 2014-03-14 1:30 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Exemplo fácil (inclusive já tinha citado antes): 1 rio + 2 linhas de uma via separada. É mais fácil colocar layer=-1 no rio do que colocar 2 tags layer=1, uma para cada linha da via. Um exemplo prático e mais extremo: suponha que seja um rio com várias pontes atravessando-o, como é o caso do arroio Dilúvio em Porto Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o cruzam, versus layer=-1 somente no arroio. 54
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Obrigado!Vou tentar o novo Poly indicado para o Rj.Uma pergunta, e quanto ao mapa do Brasil, aparecem praticamente os mesmos problemas. Você teria como me indicar um outro arquivo Poly para o Brasil? Não querendo abusar, quando faço pesquisa de endereço no GPS com esses mapas, aparecem após a cidade/pais o seguinte ,ABC e as pesquisas ficam incoerentes. O que pode ser isso? Abs, From: li...@gimnechiske.org Date: Fri, 14 Mar 2014 10:06:45 -0300 To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download Eu uso http://gaemin.openstreetmap.nl/ Depois um tempo p gerar (muitos vezes instantanio) a mapa com qualquer poligonio voce quer ser disponível, geralmente gerando somente Brazil, mas dezembro passado girei Brazil com Portugal no mesmo mapa Os arquivos e disponíveis em os mais usados formatos p garmin, eu teve nenhuma problema instalar atravez windows ou mac Aun Johnsen On Mar 14, 2014, at 10:03, Nelson A. de Oliveira nao...@gmail.com wrote: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Validador nacional
- Pra renderização o que ficaria melhor ? Depende do seu renderizador. Para o Mapnik, layer=0 nas pontes fica melhor nesse caso específico porque daí ele consegue conectar o preenchimento e o contorno da via da ponte ao preenchimento e contorno das vias em que a ponte se conecta. Daí, o rio ficaria com layer=-1. Se não quiser colocar layer=-1 no rio todo, pode colocar só no trecho próximo da ponte. Se quiser colocar layer=-1 no rio ou layer=1 na ponte, está correto. Se quiser colocar layer=0 no rio e layer=1 na ponte, está correto. Se quiser colocar layer=-3 no rio e layer=-2 na ponte, está correto. Não é o que se esperaria tipicamente, mas está correto. Todas essas formas levam exatamente ao mesmo rendering, exceto pela questão da conexão entre a ponte e o resto da malha, que pode ser vista como defeito do renderizador. - Pra roteamento, o que funcionaria melhor ? Não faz absolutamente nenhuma diferença, essa é uma tag voltada exclusivamente à renderização. - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Acho melhor entender a semântica da tag. Há muitas outras coisas em que uma padronização seria muito mais importante, nesse caso uma padronização rígida não faz diferença na prática. 2014-03-14 10:21 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Osmanianos, Lendo a frase Rivers and streams should not be tagged with layer -1 along long sections of their length, eu entendo que a tag layer NÃO deve ser usada em longas seções de rios e ( seja-lá-o-que-for ) streams. Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em uma camada diferente da entidade que ele cruza. Mais uma frase : A bridge is at layer 1 even if it is only several feet above sea level while the peak of Mount Everest is at layer 0 even though it is 8848 meters above sea level. Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que é o default e por isso não recomendado explicitar, e só se registra layer onde houver claramente uma diferença de camada em um cruzamento. Assim ... Um exemplo prático e mais extremo: suponha que seja um rio com várias pontes atravessando-o, como é o caso do arroio Dilúvio em Porto Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra constar: eu revisei uma por uma, e mapeei as que faltavam.) Usando a minha interpretação da frase inicial, o uso neste exemplo dado pelo Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1 em todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos ou pontos, não em toda sua extensão. E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da terra ( layer=0), o elemento adicional são as pontes. Adicionando uma questão a discussão, que diferença faz usar layer=1 na ponte ou layer=-1 no rio ? - Pra renderização o que ficaria melhor ? - Pra roteamento, o que funcionaria melhor ? - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Marcelo P Em 14 de março de 2014 06:58, Flavio Bello Fialho bello.fla...@gmail.com escreveu: Fernando, acho que não entendeste. Leia a página http://wiki.openstreetmap.org/wiki/Key:layer com calma. Ela diz explicitamente: Do not use layer=-1 to hide warnings about crossing or overlapping ways. Either fix them or leave the easily visible warning so that others can fix them. When ways are passing on different levels apply layer=* only to the way which also has the bridge/tunnel attribute. Only ways with one of the tags/attributes tunnel=*, bridge=*, highway=steps, highway=elevator, covered=* should be tagged with the layer tag, similar for railways and waterways. Rivers and streams should not be tagged with layer -1 along long sections of their length Eles estão dizendo explicitamente para NÃO fazer isso que queres fazer. Se tens alguma dúvida, discuta na comunidade internacional. Esse é o meu último post sobre esse assunto. Em 14 de março de 2014 02:08, Fernando Trebien fernando.treb...@gmail.com escreveu: Mais além: na verdade, em alguns casos, chega a ser pior marcar as pontes com layer=1 porque isso altera a priorização da renderização no Mapnik. Por exemplo, highway=secondary_link com layer=1 é renderizado por cima de highway=primary (com ou sem layer=0). Isso é o oposto do normal e faz o desenho ficar feio. Mas o Mapnik não é o único parâmetro. No wiki diz que algumas ferramentas de QA (mas não todas) exigem que o rio tenha layer=-1 e a ponte tenha layer=1. Nada no restante do artigo sugere que isso é, de fato, necessário (pelo contrário). Pra mim, parece uma escolha arbitrária sem muita justificativa (ou seja, um dogma). Colocar layer=-1 no rio ou layer=1 na ponte estão ambos corretos, mas frequentemente
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
2014-03-14 10:39 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Uma pergunta, e quanto ao mapa do Brasil, aparecem praticamente os mesmos problemas. Você teria como me indicar um outro arquivo Poly para o Brasil? Tem esse aqui: https://raw.github.com/osmandapp/OsmAnd-misc/master/osm-planet/geo-polygons/south-america/brazil.poly Não querendo abusar, quando faço pesquisa de endereço no GPS com esses mapas, aparecem após a cidade/pais o seguinte ,ABC e as pesquisas ficam incoerentes. O que pode ser isso? Essa parte eu já não sei te dizer (eu não tenho um Garmin para testar). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Em 14 de março de 2014 08:13, Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com escreveu: PessoALL, Sou do Rio de Janeiro e estou dando manutenção no OSM desde novembro de 2013 (estou aprendendo bastante!) e vim pedir ajuda, principalmente aos colaboradores do Rio de Janeiro que conhecem bem os trechos que irei falar... Fiquei bastante contente ao conseguir minha primeira compilação, depois de algumas tentativas e erros, finalmente tenho um script que roda liso. Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: *Mapa RJ:* A ponte Rio/Niterói só vai até a ilha de Mocanguê sentido Niterói/Rio e aparece uma outra estrada ao lado que parece ser ela. Parece ter a ver com o arquivo .poly usado, conforme falado pelo Nelson. Coisa de simples solução. O contorno da orla vindo pela Av. do Contorno está dentro d'água e vai assim por toda orla de Niterói, as ruas da Ilha da Conceição(Niterói) estão sobre a Baia de Guanabara. Pode ser o arquivo de oceano default que vem no mkgmap. Devemos usar um outro e passar para o compilador. Tracei uma rota de São Gonçalo (onde moro) até João Pessoa e para minha surpresa, o GPS começa a rota por uma estrada(possivelmente a BR-101) só que pelo meio de São Gonçalo e não pela orla (onde ela realmente passa), esta estrada virtual no visual fica por baixo do mapa, só aparece em alguns trechos. Isso precisa ser melhor explicado. É problema que veio do mapa-base? Está só no GPS? *Mapa Brasil:* A ponte Rio/Niterói aparentemente está correta. Porém a estrada virtual aparece no meio de São Gonçalo e os problemas visuais da orla, ruas dentro d'água continuam. Que rua virtual é essa? Tem como postar uma captura de tela? Está com outros mapas habilitados no GPS? Os mapas disponíveis no projeto COCAR estão com os mesmos problemas, e o do site oficial do OSM tem um problemas parecido no bairro de Alcantara/São Gonçalo, algumas ruas não aprecem no mapa compilado (no GPS). Ruas faltantes no mapa podem ser acrescentadas editando o mapa. Não estamos mais no Tracksource. ;-P Obrigado pela atenção, Hélio Coutinho. -- Date: Tue, 11 Mar 2014 11:21:56 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download 335 é o código IBGE para SP. Na verdade 35. O 3 a mais seria região sudeste. Isso é para nos certificar de que não haja colisão de IDs caso o usuário instale mais de um mapa. O do RJ é 333. Mas esse código poderia ser qualquer um que quiséssemos inventar, desde que seja único. Colocarei um link lá no Cocar. Aliás tenho que fazer uma página com a relação de mapas, (que tende a crescer) e citar a cortesia. Os links no menu não vão dar certo. [ ]s e obrigado. Paulo 2014-03-11 9:43 GMT-03:00 Nelson A. de Oliveira nao...@gmail.com: --mapid não existe Para family-id e product-id, tem algo em específico para serem 335? Tirando isso, o de SP está aqui: http://naoliv.iq.unesp.br/mapas/gmapsupp.img ___ 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 ___ 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] Kit para compilação Garmin em Windows e mapas Garmin para download
Nelson, Obrigado mais uma vez! Este Poly que você me indicou só tem 5KB o que usei tem 2133KB, é isso mesmo? Abs, Date: Fri, 14 Mar 2014 10:53:03 -0300 From: nao...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br]Kit para compilação Garmin em Windows e mapas Garmin para download 2014-03-14 10:39 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Uma pergunta, e quanto ao mapa do Brasil, aparecem praticamente os mesmos problemas. Você teria como me indicar um outro arquivo Poly para o Brasil? Tem esse aqui: https://raw.github.com/osmandapp/OsmAnd-misc/master/osm-planet/geo-polygons/south-america/brazil.poly Não querendo abusar, quando faço pesquisa de endereço no GPS com esses mapas, aparecem após a cidade/pais o seguinte ,ABC e as pesquisas ficam incoerentes. O que pode ser isso? Essa parte eu já não sei te dizer (eu não tenho um Garmin para testar). ___ 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] Validador nacional
Do not use layer=-1 to *hide warnings* about crossing or overlapping ways. Either *fix them* or leave the easily visible warning so that others can fix them. Quem disse está sendo feito assim para esconder alertas? Eu tratei cada um dos alertas originais, e por fim coloquei layer=-1 no rio. Está de acordo com a instrução. When ways are passing on different levels apply layer=* only to the way which also has the bridge/tunnel attribute. Only ways with one of the tags/attributes tunnel=*, bridge=*, highway=steps, highway=elevator, covered=* should be tagged with the layer tag, similar for railways and waterways. (...) Rivers and streams should not be tagged with layer -1 along long sections of their length Não há uma explicação de por que isso é ruim/errado. Tem algumas pessoas na página Discussion que pensam diferente. Vou copiar alguns trechos: - For complex motorway junctions, bridges may themselves be bridged. In other circumstances, tunnels may themselves be tunneled under. So bridges can be layer +1, +2, etc. A bridge may go over something which has layer -1, so the bridge would be *layer 0* etc. etc. Richard B 12:40, 3 September 2008 (UTC) - It's hardly a big issue to have a few objects tagged in this way. *Just remember also how the renderer works.* Objects in layer -5 are drawn first. Then objects in layer -4 are drawn on top. Then objects in layer -3 etc. Finally objects in layer +5 are drawn last. That has got to be simpler than requiring the renderers to have filters based on defaults for some objects, and still requiring layer tags for more complicated examples. Remember that bridges might be tagged bridge=yes, bridge=true, or even ones that specify what type of bridge it is, bridge=swing etc.For what it's worth, data for the UK shows (on ways tagged bridge=yes and bridge=true); 2 bridges with layer=-2 (0.0%) 59 bridges with layer=-1 (0.4%) 22 bridges with layer=0 (0.2%) 12813 bridges with layer=1 (91.7%) 896 bridges with layer=2 (6.4%) 126 bridges with layer=3 (0.9%) 43 bridges with layer=4 (0.3%) 9 bridges with layer=5 (0.1%) So nearly 10% of all bridges are tagged in a different layer than 1. Tagging something with a layer tag can only be redundant if one implies the other. It clearly does not. Looking at the stats for tunnels in European tagging suggests there are *tunnels tagged between layer=3 and layer=-6*. - *Only the relative order is important*, *not the actual values used*, so there is nothing wrong with non-consecutive layers (e.g. object with layer=4 directly over object with layer=-2), and bridges having negative and tunnels having positive layers. - I use the layer key on all *bridges and tunnels. Usually this means layers 1 and -1*, respectively, but *it gets more complicated in urban environments*. *Rivers through cities typically get layer=-1 because they consistently pass under the street level*. *Bridges over such rivers are often layer=0*, especially if they have intersecting streets immediately at one or both ends of the bridge. The same is true when a motorway is below street level. And when a motorway or rail line is consistently above street level, the whole thing gets layer=1 and not just the parts that are actually on bridges. I also try to make both parts of a divided highway be on the same layer (assuming they're physically at the same level) and make the transition from one layer to another at about the same point. Generally speaking, for any two features that cross or are very close to each other, I try to represent the relative physical height difference. Not only is this a good semantic representation of the physical world, but doing it this way (as opposed to bare-minimum use of the layer key) tends to produce slightly better map renders. That's a win-win. Vid the Kid 23:07, 13 April 2009 (UTC) - This seems self-contradictory: *If layer has no meanings for absolute heights*, then *it doesn't matter whether to put the layer on the stream or the bridge*, and whether to choose layer=-1 for the bridge and layer=-4 for the stream, or 1 and 0 resp. Eu acho que o problema que você quer evitar vem na resposta a essa última observação: - Of course layer is relative, and you could tag the waterway as layer=-5 and the bridge as layer=-4, but *usually the waterway will not be split into a small piece* under the bridge and everything else, so the layer=-5 applies to the whole waterway - and *that is bad*. SvenR 21:07, 23 January 2009 (UTC) Não faz sentido considerar errado, já que não afeta nenhuma aplicação - a não ser validadores, que bem poderiam estar validando uma regra um pouco mais inteligente como esta: alertar quando 2 linhas com o mesmo valor em layer (incluindo layer=0 implícito) se cruzam: - sem ponto compartilhado: quaisquer tipos de vias - com ponto compartilhado: vias de tipos diferentes (highway+waterway) Dito isto, como é feito na prática? O rio Tâmisa, em Londres, o rio Sena, em Paris, e o rio Danúbio, em Viena, estão da forma que você
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
2014-03-14 11:07 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Este Poly que você me indicou só tem 5KB o que usei tem 2133KB, é isso mesmo? Sim, está certo :-) É uma versão mais simplificada, com número menor de nós. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? []s PC Em 14 de março de 2014 10:03, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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] Validador nacional
Qual a origem desse dogma, na minha opinião: ao importar a hidrografia de uma certa região, alguns importadores acharam mais conveniente colocar layer=-1 em todos os rios pra se livrar dos alertas do JOSM do que deixar os alertas e, quem sabe, adicionar as pontes corretamente. Bem, tem 1 coisa errada com essa idéia: o JOSM deveria alertar sobre a falta de uma ponte nesses casos porque layer=-1 não significa subterrâneo. É bem possível também que o próprio importador estivesse entendendo alerta no JOSM como erro, mas são coisas diferentes. Tem outra coisa: o importador deveria ter previsto esse efeito colateral antes de importar. Por isso que não se pode sair importando as coisas de qualquer jeito sem conversar com a comunidade antes pra ver se vai funcionar. Caso isso tenha acontecido (como se pergunta no fim da página de discussão), a melhor forma de resolver a situação é: baixar o mapa, mudar a tag layer dos rios para layer=0 (ou simplesmente excluí-la), rodar o validador, e mapear as pontes onde o validador tiver dado um aviso. Tanto faz o valor que vai em layer, desde que a layer do rio seja inferior à layer da ponte (ou, equivalentemente, que a layer da ponte seja superior à do rio). Ou seja, depois de mapeadas as pontes, daria pra colocar layer=-1 (ou -2, ou -5) de novo nos rios (inclusive durante a mesma edição). Também daria colocar layer nas pontes. Enfim, a escolha é livre. 2014-03-14 10:52 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: - Pra renderização o que ficaria melhor ? Depende do seu renderizador. Para o Mapnik, layer=0 nas pontes fica melhor nesse caso específico porque daí ele consegue conectar o preenchimento e o contorno da via da ponte ao preenchimento e contorno das vias em que a ponte se conecta. Daí, o rio ficaria com layer=-1. Se não quiser colocar layer=-1 no rio todo, pode colocar só no trecho próximo da ponte. Se quiser colocar layer=-1 no rio ou layer=1 na ponte, está correto. Se quiser colocar layer=0 no rio e layer=1 na ponte, está correto. Se quiser colocar layer=-3 no rio e layer=-2 na ponte, está correto. Não é o que se esperaria tipicamente, mas está correto. Todas essas formas levam exatamente ao mesmo rendering, exceto pela questão da conexão entre a ponte e o resto da malha, que pode ser vista como defeito do renderizador. - Pra roteamento, o que funcionaria melhor ? Não faz absolutamente nenhuma diferença, essa é uma tag voltada exclusivamente à renderização. - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Acho melhor entender a semântica da tag. Há muitas outras coisas em que uma padronização seria muito mais importante, nesse caso uma padronização rígida não faz diferença na prática. 2014-03-14 10:21 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Osmanianos, Lendo a frase Rivers and streams should not be tagged with layer -1 along long sections of their length, eu entendo que a tag layer NÃO deve ser usada em longas seções de rios e ( seja-lá-o-que-for ) streams. Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em uma camada diferente da entidade que ele cruza. Mais uma frase : A bridge is at layer 1 even if it is only several feet above sea level while the peak of Mount Everest is at layer 0 even though it is 8848 meters above sea level. Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que é o default e por isso não recomendado explicitar, e só se registra layer onde houver claramente uma diferença de camada em um cruzamento. Assim ... Um exemplo prático e mais extremo: suponha que seja um rio com várias pontes atravessando-o, como é o caso do arroio Dilúvio em Porto Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra constar: eu revisei uma por uma, e mapeei as que faltavam.) Usando a minha interpretação da frase inicial, o uso neste exemplo dado pelo Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1 em todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos ou pontos, não em toda sua extensão. E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da terra ( layer=0), o elemento adicional são as pontes. Adicionando uma questão a discussão, que diferença faz usar layer=1 na ponte ou layer=-1 no rio ? - Pra renderização o que ficaria melhor ? - Pra roteamento, o que funcionaria melhor ? - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Marcelo P Em 14 de março de 2014 06:58, Flavio Bello Fialho bello.fla...@gmail.com escreveu: Fernando, acho que não entendeste. Leia a página http://wiki.openstreetmap.org/wiki/Key:layer com calma. Ela diz explicitamente: Do not use layer=-1 to hide warnings about
Re: [Talk-br] Why Imports in OpenStreetMap Are Controversial
Bom, manter um mapa atualizado é um desafio. Não vejo porque esse seria um problema exclusivo da parte que é importada. Meu primeiro tracklog (enviado ao Tracksource) foi de uma rampa de asa-delta que visitei em Congonhal-MG em 2004. Nem sei se ainda existe. 2014-03-14 8:56 GMT-03:00 Wille wi...@wille.blog.br: Há um novo texto no blog do Serge sobre a dificuldade de manutenção de dados importados no OSM: http://blog.emacsen.net/blog/ 2014/03/13/the-maintenance-of-imported-data-in-openstreetmap/ On 04-02-2014 19:59, Wille wrote: Compartilho um texto muito bom sobre a questão das importações no OSM: http://blog.emacsen.net/blog/2014/01/25/why-imports-in-openstreetmap-are- controversial/ ___ 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 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Paulo Carvalho, - O mapa base pego daqui (como está indicado na BAT do projeto COCAR): http://download.geofabrik.de/south-america/brazil-latest.osm.pbf - Captura: Não estou com o GPS aqui no trabalho, posso enviar a noite... - Procuro sempre habilitar um mapa por vez... - Não é o caso de acrescentar ruas, pelo ID as ruas estão lá bonitinhas e bem desenhadinhas (rsrs). Com as telas capturadas acho que será melhor de nos entendermos. Obrigado, Hélio Coutinho. Date: Fri, 14 Mar 2014 11:09:22 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? []s PC Em 14 de março de 2014 10:03, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Hélio, Se você apontar um exemplo (dando nome da Rua ou apontando no OSM) eu mesmo faço a verificação no meu GPS contra o mapa-base do OSM. [ ]s Paulo Em 14 de março de 2014 11:17, Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com escreveu: Paulo Carvalho, - O mapa base pego daqui (como está indicado na BAT do projeto COCAR): http://download.geofabrik.de/south-america/brazil-latest.osm.pbf - Captura: Não estou com o GPS aqui no trabalho, posso enviar a noite... - Procuro sempre habilitar um mapa por vez... - Não é o caso de acrescentar ruas, pelo ID as ruas estão lá bonitinhas e bem desenhadinhas (rsrs). Com as telas capturadas acho que será melhor de nos entendermos. Obrigado, Hélio Coutinho. -- Date: Fri, 14 Mar 2014 11:09:22 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? []s PC Em 14 de março de 2014 10:03, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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 ___ 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] Kit para compilação Garmin em Windows e mapas Garmin para download
2014-03-14 11:09 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? Posso gerar. Hoje e fim de semana está meio corrido, mas no máximo até segunda eu gero de todos. ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Paulo, segue, https://www.openstreetmap.org/way/204618440#map=19/-22.82102/-42.99988 Rua Almirante Nestor Pinto Alves (ao lado do Supermercado Extra) aparece no ID e não aparece no mapa OSM no GPS, entre outras próximas. Abs, Hélio. Date: Fri, 14 Mar 2014 11:20:38 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download Hélio, Se você apontar um exemplo (dando nome da Rua ou apontando no OSM) eu mesmo faço a verificação no meu GPS contra o mapa-base do OSM. [ ]s Paulo Em 14 de março de 2014 11:17, Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com escreveu: Paulo Carvalho, - O mapa base pego daqui (como está indicado na BAT do projeto COCAR): http://download.geofabrik.de/south-america/brazil-latest.osm.pbf - Captura: Não estou com o GPS aqui no trabalho, posso enviar a noite... - Procuro sempre habilitar um mapa por vez... - Não é o caso de acrescentar ruas, pelo ID as ruas estão lá bonitinhas e bem desenhadinhas (rsrs). Com as telas capturadas acho que será melhor de nos entendermos. Obrigado, Hélio Coutinho. Date: Fri, 14 Mar 2014 11:09:22 -0300 From: paulo.r.m.carva...@gmail.com To: talk-br@openstreetmap.org Subject: Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? []s PC Em 14 de março de 2014 10:03, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-03-14 8:13 GMT-03:00 Hélio Ricardo Pinheiro Coutinho helio_couti...@hotmail.com: Porém, notei que o mapa compilado, já no GPS Garmin, ficou com alguns problemas: Por acaso você está usando o poly daqui http://downloads.cloudmade.com/americas/south_america/brazil/rio_de_janeiro para extrair o estado? Caso sim, esse poly possui um buraco entre Rio e Niterói. Esse http://naoliv.iq.unesp.br/osm/RJ.poly é o contorno do estado definido no OSM. ___ 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 ___ 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 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Kit para compilação Garmin em Windows e mapas Garmin para download
Nélson, não tenha pressa. Pensei que talvez você os já tivesse prontos. Mas se dispondo a gerá-los, só temos a agradecer. []s Paulo Em 14 de março de 2014 11:20, Nelson A. de Oliveira nao...@gmail.comescreveu: 2014-03-14 11:09 GMT-03:00 Paulo Carvalho paulo.r.m.carva...@gmail.com: Boa, Nelson, vou incluir esse poly no kit. A propósito, você teria por aí os polys dos outros estados? Posso gerar. Hoje e fim de semana está meio corrido, mas no máximo até segunda eu gero de todos. ___ 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] Validador nacional
Pra quem quiser acompanhar: https://lists.openstreetmap.org/pipermail/tagging/2014-March/016865.html 2014-03-14 11:10 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: Qual a origem desse dogma, na minha opinião: ao importar a hidrografia de uma certa região, alguns importadores acharam mais conveniente colocar layer=-1 em todos os rios pra se livrar dos alertas do JOSM do que deixar os alertas e, quem sabe, adicionar as pontes corretamente. Bem, tem 1 coisa errada com essa idéia: o JOSM deveria alertar sobre a falta de uma ponte nesses casos porque layer=-1 não significa subterrâneo. É bem possível também que o próprio importador estivesse entendendo alerta no JOSM como erro, mas são coisas diferentes. Tem outra coisa: o importador deveria ter previsto esse efeito colateral antes de importar. Por isso que não se pode sair importando as coisas de qualquer jeito sem conversar com a comunidade antes pra ver se vai funcionar. Caso isso tenha acontecido (como se pergunta no fim da página de discussão), a melhor forma de resolver a situação é: baixar o mapa, mudar a tag layer dos rios para layer=0 (ou simplesmente excluí-la), rodar o validador, e mapear as pontes onde o validador tiver dado um aviso. Tanto faz o valor que vai em layer, desde que a layer do rio seja inferior à layer da ponte (ou, equivalentemente, que a layer da ponte seja superior à do rio). Ou seja, depois de mapeadas as pontes, daria pra colocar layer=-1 (ou -2, ou -5) de novo nos rios (inclusive durante a mesma edição). Também daria colocar layer nas pontes. Enfim, a escolha é livre. 2014-03-14 10:52 GMT-03:00 Fernando Trebien fernando.treb...@gmail.com: - Pra renderização o que ficaria melhor ? Depende do seu renderizador. Para o Mapnik, layer=0 nas pontes fica melhor nesse caso específico porque daí ele consegue conectar o preenchimento e o contorno da via da ponte ao preenchimento e contorno das vias em que a ponte se conecta. Daí, o rio ficaria com layer=-1. Se não quiser colocar layer=-1 no rio todo, pode colocar só no trecho próximo da ponte. Se quiser colocar layer=-1 no rio ou layer=1 na ponte, está correto. Se quiser colocar layer=0 no rio e layer=1 na ponte, está correto. Se quiser colocar layer=-3 no rio e layer=-2 na ponte, está correto. Não é o que se esperaria tipicamente, mas está correto. Todas essas formas levam exatamente ao mesmo rendering, exceto pela questão da conexão entre a ponte e o resto da malha, que pode ser vista como defeito do renderizador. - Pra roteamento, o que funcionaria melhor ? Não faz absolutamente nenhuma diferença, essa é uma tag voltada exclusivamente à renderização. - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Acho melhor entender a semântica da tag. Há muitas outras coisas em que uma padronização seria muito mais importante, nesse caso uma padronização rígida não faz diferença na prática. 2014-03-14 10:21 GMT-03:00 Marcelo Pereira pereirahol...@gmail.com: Osmanianos, Lendo a frase Rivers and streams should not be tagged with layer -1 along long sections of their length, eu entendo que a tag layer NÃO deve ser usada em longas seções de rios e ( seja-lá-o-que-for ) streams. Mas deduzo que é possível usá-la em rios nos pontos/trechos onde estiver em uma camada diferente da entidade que ele cruza. Mais uma frase : A bridge is at layer 1 even if it is only several feet above sea level while the peak of Mount Everest is at layer 0 even though it is 8848 meters above sea level. Aqui interpreto que toda a superficie da terra, rios e mares é layer=0, que é o default e por isso não recomendado explicitar, e só se registra layer onde houver claramente uma diferença de camada em um cruzamento. Assim ... Um exemplo prático e mais extremo: suponha que seja um rio com várias pontes atravessando-o, como é o caso do arroio Dilúvio em Porto Alegre. Você teria que colocar layer=1 em cada uma das 54 pontes que o cruzam, versus layer=-1 somente no arroio. 54 tags vs 1 tag. (Só pra constar: eu revisei uma por uma, e mapeei as que faltavam.) Usando a minha interpretação da frase inicial, o uso neste exemplo dado pelo Trebien, seria a de se incluir layer=1 em todas as pontes, ou layer=-1 em todos os trechos do arroio que cruzam as pontes, sejam pequenos trechos ou pontos, não em toda sua extensão. E de acordo com a segunda frase, teríamos que usar o layer=1 para as pontes e não o layer=-1 para o rio, pois esse ainda faz parte da superfície da terra ( layer=0), o elemento adicional são as pontes. Adicionando uma questão a discussão, que diferença faz usar layer=1 na ponte ou layer=-1 no rio ? - Pra renderização o que ficaria melhor ? - Pra roteamento, o que funcionaria melhor ? - Será que não seria bom padronizar ? ( no caso de comportamentos diferentes para cada caso ) Marcelo P Em 14 de março de 2014 06:58, Flavio Bello Fialho
[Talk-br] Porto Velho - Rios sobrepostos
Pessoal, qual devo deixar desses dois rios sobrepostos? http://www.openstreetmap.org/browse/way/151882080 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Porto Velho - Rios sobrepostos
2014-03-14 14:48 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Pessoal, qual devo deixar desses dois rios sobrepostos? http://www.openstreetmap.org/browse/way/151882080 Não é sobreposto. Um é o rio em si e o outro a área do rio. Está certo (só teria que ajustar a área dele) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Porto Velho - Rios sobrepostos
Pelo que eu sei, em rios vc pode desenhar uma área para marcar o espaço que ele ocupa, e também pode desenhar uma linha para marcar o seu curso (principalmente para ser usado quando for feito um planejamento de navegação), Talvez o que precise se feito ali é somente o ajuste do curso do rio. 2014-03-14 14:48 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Pessoal, qual devo deixar desses dois rios sobrepostos? http://www.openstreetmap.org/browse/way/151882080 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br -- Ronaldo Maia ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvidas em Natal
Troquei as respostas :-) Pra http://www.openstreetmap.org/way/42433318 você pergunta para a pessoa. Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro lado da avenida e os trechos dela), deixa a avenida de forma correta (mão dupla). ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvidas em Natal
Do jeito que está está correto. Está assim por causa das obras da copa. 2014-03-14 16:46 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Okay. Vou ver quem esta ativo lá e perguntar. Em 14/03/2014 16:41, Nelson A. de Oliveira nao...@gmail.com escreveu: Troquei as respostas :-) Pra http://www.openstreetmap.org/way/42433318 você pergunta para a pessoa. Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro lado da avenida e os trechos dela), deixa a avenida de forma correta (mão dupla). ___ 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 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvidas em Natal
Braulio. Então nos dois casos é pra deixar? Em 14/03/2014 16:52, Bráulio brauliobeze...@gmail.com escreveu: Do jeito que está está correto. Está assim por causa das obras da copa. 2014-03-14 16:46 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Okay. Vou ver quem esta ativo lá e perguntar. Em 14/03/2014 16:41, Nelson A. de Oliveira nao...@gmail.com escreveu: Troquei as respostas :-) Pra http://www.openstreetmap.org/way/42433318 você pergunta para a pessoa. Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro lado da avenida e os trechos dela), deixa a avenida de forma correta (mão dupla). ___ 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 ___ 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] Dúvidas em Natal
2014-03-14 16:52 GMT-03:00 Bráulio brauliobeze...@gmail.com: Do jeito que está está correto. Está assim por causa das obras da copa. Aqui onde a avenida Aminta Barros, na parte de cima, muda de direção na Rua Professor Antônio Campos (ficando com os dois sentidos dela para uma única direção), está certo? (até o lado direito da Campos é duas mãos; lado esquerdo 2 caminhos pro mesmo sentido) http://osm.org/go/PT3vaLN7v ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvidas em Natal
Sim. Tanto a avenida Amintas Barros como a Miguel Castro (ao sul desta) estão com alguns trechos em mão única, mesmo onde há canteiro central. Há mais alterações além dessas, mas não estou conseguindo acompanhar :(. Mas pelo menos essa mais importantes e duradouras eu coloquei no mapa. 2014-03-14 16:53 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Braulio. Então nos dois casos é pra deixar? Em 14/03/2014 16:52, Bráulio brauliobeze...@gmail.com escreveu: Do jeito que está está correto. Está assim por causa das obras da copa. 2014-03-14 16:46 GMT-03:00 Erick de Oliveira Leal erickdeoliveiral...@gmail.com: Okay. Vou ver quem esta ativo lá e perguntar. Em 14/03/2014 16:41, Nelson A. de Oliveira nao...@gmail.com escreveu: Troquei as respostas :-) Pra http://www.openstreetmap.org/way/42433318 você pergunta para a pessoa. Para http://www.openstreetmap.org/way/205363395 (no caso seria o outro lado da avenida e os trechos dela), deixa a avenida de forma correta (mão dupla). ___ 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 ___ 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 ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvidas em Natal
2014-03-14 16:57 GMT-03:00 Bráulio brauliobeze...@gmail.com: Sim. Tanto a avenida Amintas Barros como a Miguel Castro (ao sul desta) estão com alguns trechos em mão única, mesmo onde há canteiro central. Faltou um note explicando isso então ;-) ___ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-br] Dúvidas em Natal
Braulio. Eu não vou corrigir, vou deixar pra você que tem mais conhecimento do caso. Em 14/03/2014 17:03, Nelson A. de Oliveira nao...@gmail.com escreveu: 2014-03-14 16:57 GMT-03:00 Bráulio brauliobeze...@gmail.com: Sim. Tanto a avenida Amintas Barros como a Miguel Castro (ao sul desta) estão com alguns trechos em mão única, mesmo onde há canteiro central. Faltou um note explicando isso então ;-) ___ 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-de] Hochsitze / Bitte um Entfernung von Daten
Hi! Um wieder auf die Originalmail zurückzukommen: - der Verfasser gibt keine Auskunft über seine Identität oder Legitimation dort überhaupt etwas zu fordern. - er macht eine ominöse Andeutung von erheblichen Problemen, nennt aber die angeblichen Probleme nicht - er spricht von Straftaten, aber wenn man genau liest bringt selbst er diese Straftaten nicht mit OSM in Zusammenhang, er sagt nur dort sei irgendwann irgendwas passiert. Ich sehe keinerlei Grund hier irgendetwas zu löschen. Es handelt sich um Fakten über weithin sichtbare Objekte und ein Betreten ist für das Erfassen der Position nicht erforderlich, dadurch werden keine Rechte berührt. Ich bin mir ziemlich sicher, daß es sich nur um einen Privatmann (vermutlich Jagdpächter) handelt und nicht um z.B. einen Fortsbeamten mit offizieller Befugnis. Eine offizielle Stelle hätte sich mit vollem Namen gemeldet und auf ihre Legitimation und Zuständigkeit hingewiesen. Ich würde dem Verfasser mitteilen, daß ohne konkrete Informationen nichts aus OSM gelöscht wird und ihn auffordern, die Probleme detailliert auszuführen, damit man sich selbst ein Bild von deren Ausmaß machen kann. Vor allem muß er den Zusammenhang zu OSM zu belegen. Ferner wäre es eine Überlegung wert, die Flucht nach vorn antreten und sich beim zuständigen Forstamt nach den angeblichen Problemen und deren Sicht auf die Dinge zu erkundigen. Am besten durch einen ortskundigen Mapper. Das sollte eine objektivere Meinung liefern. Ehrlich gesagt würde ich erwarten, daß das Forstamt nichts von irgendwelchen Problemen weiß oder zumindest keinen Sinn darin sieht, weithin sichtbare Objekte durch Entfernen auf der Karte geheim zu halten. Und dann hätte der Verfasser nichts mehr in der Hand und einen EditWar oder Streitigkeiten fortzusetzen. bye, Nop -- View this message in context: http://gis.19327.n5.nabble.com/Hochsitze-Bitte-um-Entfernung-von-Daten-tp5799540p5799652.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
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
+1 Sachliche Argumentation und sehr gute Vorschläge wie ich finde! Original-Nachricht Betreff: Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten Datum: Fri Mar 14 2014 07:52:10 GMT+0100 Von: NopMap ekkeh...@gmx.de An: talk-de@openstreetmap.org Hi! Um wieder auf die Originalmail zurückzukommen: - der Verfasser gibt keine Auskunft über seine Identität oder Legitimation dort überhaupt etwas zu fordern. - er macht eine ominöse Andeutung von erheblichen Problemen, nennt aber die angeblichen Probleme nicht - er spricht von Straftaten, aber wenn man genau liest bringt selbst er diese Straftaten nicht mit OSM in Zusammenhang, er sagt nur dort sei irgendwann irgendwas passiert. Ich sehe keinerlei Grund hier irgendetwas zu löschen. Es handelt sich um Fakten über weithin sichtbare Objekte und ein Betreten ist für das Erfassen der Position nicht erforderlich, dadurch werden keine Rechte berührt. Ich bin mir ziemlich sicher, daß es sich nur um einen Privatmann (vermutlich Jagdpächter) handelt und nicht um z.B. einen Fortsbeamten mit offizieller Befugnis. Eine offizielle Stelle hätte sich mit vollem Namen gemeldet und auf ihre Legitimation und Zuständigkeit hingewiesen. Ich würde dem Verfasser mitteilen, daß ohne konkrete Informationen nichts aus OSM gelöscht wird und ihn auffordern, die Probleme detailliert auszuführen, damit man sich selbst ein Bild von deren Ausmaß machen kann. Vor allem muß er den Zusammenhang zu OSM zu belegen. Ferner wäre es eine Überlegung wert, die Flucht nach vorn antreten und sich beim zuständigen Forstamt nach den angeblichen Problemen und deren Sicht auf die Dinge zu erkundigen. Am besten durch einen ortskundigen Mapper. Das sollte eine objektivere Meinung liefern. Ehrlich gesagt würde ich erwarten, daß das Forstamt nichts von irgendwelchen Problemen weiß oder zumindest keinen Sinn darin sieht, weithin sichtbare Objekte durch Entfernen auf der Karte geheim zu halten. Und dann hätte der Verfasser nichts mehr in der Hand und einen EditWar oder Streitigkeiten fortzusetzen. bye, Nop ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Original-Nachricht Betreff: Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten Datum: Thu Mar 13 2014 22:15:42 GMT+0100 Von: Christian H. Bruhn br...@arcor.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Hochsitze sind allgemein gut sichtbar, wenn man sich in Wald und Flur bewegt. Die kann man auch ohne OSM finden, und falls doch OSM genutzt wurde, sehe ich darin auch keine Mitschuld. Man kann die Wahrheit nicht verstecken. Nutzen sie nicht OSM, dann vielleicht Google-Satelitenbilder oder sie suchen selbst. In einigen Waldgebieten sind die Hochsitze sogar ausgeschildert. Z.B. habe ich hier in letzter Zeit an Bäumen rosa aufgesprühte Nummern und Pfeile gesichtet, die, wenn man ihnen folgte, zu Hochsitzen führten, die auch jeweils die Nummer trugen... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Hi Nop, volle Zustimmung. Am 14.03.2014 07:52, schrieb NopMap: - der Verfasser gibt keine Auskunft über seine Identität oder Legitimation dort überhaupt etwas zu fordern. Selbst, wenn er Mitarbeiter des Forstamtes/Schießvereins/ Ehrenvorsitzender der Niedersächsischen Jägerschaft wäre, hätte seine Forderung keine Legitimation. Ich bringe mal das Beispiel der Militärfunkstation(en) in Frankreich. https://de.wikipedia.org/wiki/Milit%C3%A4rische_Funkstation_Pierre-sur-Haute 2013 zwang der französische Inlandsgeheimdienst DCRI einen Mitarbeiter der französischsprachigen Wikipedia unter Androhung von Untersuchungshaft, den französischen Wikipedia-Artikel zur Funkstation zu löschen. Nach der Drohung mit Haft für einen Freiwilligen ist es eine Genugtuung, dass der Wikipedia-Artikel nun in über deißig Sprachen existiert. https://de.wikipedia.org/wiki/Streisand-Effekt#Weltweites_Internet Die Herren Hobbyschlachter müssen sich halt damit abfinden, dass ihre Freizeitbeschäftigung bei einem Teil der Bevölkerung nicht besonders hoch angesehen ist. Das widerrechtliche Beschädigen von Leitern, das ich ablehne, kann nicht mit Geheimhaltung verhindert werden. Ebenso wie Spaziergänger darauf achten müssen, nicht gegen Stahlseile ( http://abload.de/img/absperrung1ljsqy.jpg ) zu laufen, die von einem Jäger quer über den Weg gespannt wurden, sollten Letztgenannte im eigenen Interesse die Stabilität ihrer Schießstützpunkte vor dem Erklettern prüfen. Das hat nichts mit OSM zu tun, das ist so. Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Am 14. März 2014 08:56 schrieb Andreas Schmidt schmidt-postf...@freenet.de: Die Herren Hobbyschlachter müssen sich halt damit abfinden, dass ihre Freizeitbeschäftigung bei einem Teil der Bevölkerung nicht besonders hoch angesehen ist. Das widerrechtliche Beschädigen von Leitern, das ich ablehne, kann nicht mit Geheimhaltung verhindert werden. Ebenso wie Spaziergänger darauf achten müssen, nicht gegen Stahlseile ( http://abload.de/img/absperrung1ljsqy.jpg ) zu laufen, die von einem Jäger quer über den Weg gespannt wurden, sollten Letztgenannte im eigenen Interesse die Stabilität ihrer Schießstützpunkte vor dem Erklettern prüfen. Das hat nichts mit OSM zu tun, das ist so. Also bevor das jetzt hier zum Jägerbashing verkommt sollten wir aufhören. Die Sachargumente wurden vorgetragen und haben breite Zustimmung gefunden. In den letzten Beiträgen treten aber vermehrt (also nicht in allen) Argumentationslinien wie (Alle) Jäger sind schlecht, deshalb erst recht nicht auf. Das haben wir nicht nötig, um unseren hier gefundenen Standpunkt zu vertreten. Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Hallo Alle, zur Frage welche Karten Hochsitze anzeigen. Ich habe auf meinem Android Smartphone die App MapsWithMe: http://mapswith.me/de/home installiert. Die verwendet OSM als Basis. Rendert aber offensichtlich selbst, denn Hochsitze werden angezeigt. Hallo Hartmut, Am 13.03.2014 13:13, schrieb Hartmut Holzgraefe: On 03/13/2014 12:06 PM, Frederik Ramm wrote: Jetzt mal ganz blöd gefragt: werden Hochsitze auf den gängigen Karten überhaupt gerendert? Mir ist noch nie einer aufgefallen, das kann aber auch einfach daran liegen das hier in der Gegend keiner erfasst ist ... Selbst wenn ja: dann sehe ich darin immer noch keinen Beihilfe Aspekt. Und wenn nicht: wenn sich da jemand tatsächlich die Mühe macht potentielle Anschlagsziele zB. mit OverPass herauszusuchen dann wird derjenige entsprechende Informationen auch anderweitig beschaffen können (zB aus History-Daten selbst wenn wir die vorhandenen Hochsitz-Objekte löschen, oder auch aus ganz anderen nicht-OSM Quellen) Die All-in-one-Garmin-Map* stellt Hochsitze dar. https://github.com/aiomaster/aiostyles/blob/master/basemap_style/points Als ich mit OSM im Jahr 2011 angefangen habe, war das ein schönes Feedback auf meinem Garmin. (Ich habe nämlich damals vor allem Feld- und Waldwege sowie Hochsitze und andere Outdoor-Sachen gemappt). So sieht es aus, wenn mehrere Hochsitz-Mapper (fast alle, die die verlinkten Hochsitze gemappt haben, kenne ich persönlich): http://overpass-turbo.eu/s/2Lo http://overpass-turbo.eu/s/2Lq Anders sähe das für mich erst zB. bei Nist- und Brutplätzen aus, oder wenn Dinge wie Hier wächst ein Enzian engetragen werden ... Nist- und Brutplätze sind oft (nicht bei allen Arten) temporär und daher für OSM nur bedingt geeignet. :) Viele Grüße Michael *) Derzeit scheint die AIO laut Wiki wieder nicht mehr aktuell zu sein. - -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTIh97AAoJEB87G9rMCMyIZf4P/0jSFjtbmlS7XepqKecKBPfE zBVWp4gt0MVsEA0B6Z3qZgC1pvtqjXb1G4rZGw8ZrWJQgpHFN1jFxhPDnQzGRN1M 7X9dleev3u/Pd6Ti2hD58p5NOxFx0JNn4hzt2+iz0RfPd1zPu7crHC4uXXxXpK/B 7FswbdnrDMAelfaqYryEXGWAycLpLQ+22+wldbebyofiT1k6JzAZvHOuFiCR6W1m BhyovWySZxpoaBUgGmDZkPhc5mniZYziPppUYhvaMxDRKD/P5aYxlpx6WNvYbXcC XMo1/5CzapWjV7c0ffReHYyvKqDuQLsbHvBQYv9oQAf9umVtrcGgEfqNsd0cNd0/ qqretTwKXTlc7dG/0a5Bj3yAFAhUzATFxPiGZ3OX60M3nZPPuDnxJXuTdBiKcfhz PVL2hFIc1eMmSZgS/bHlsgVeQ8RWTwSYd4428q7FNAZLHx5RrXnzdxduJqku5x+q ZXc9IXT5AuNr2Y04lTeRX0qqsAXwWz+KPUKxLvXVz1oNj4rw8hqGAYweRSaVyAUI 2DslBP0OtjSHaM4jpYJkleZDSyP+/M3JkUI5RO2D0gviV5dxA4AY12+6CG5HPnTC oWxoo4r2pXXmFx+iefY9NIagyxeWw1S6HkJGChrYDzr2PNx8cZgd6o0mVkR3xdY9 lcGI1zI0Gjtkmg7ptr5K =2F/q -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
On 03/14/2014 09:14 AM, Lothar Beck wrote: Nist- und Brutplätze sind oft (nicht bei allen Arten) temporär und daher für OSM nur bedingt geeignet. :) ich stoße hier im Wald immer wieder mal auf fest installierte Nistkästen und -hilfen, die meisten davon mit einer deutlich lesbaren Nummerierung ... trage die aber trotzdem nicht ein weil ich potentiellen Nesträubern dann doch nicht zuarbeiten möchte ... im Gegensatz zu Hochsitzen sehe ich in diesem Fall schon eher ein ähnliches Schutzinteresse wie zB. bei Frauen- oder Mädchenhäusern die auch aus gutem Grund nicht findbar sein wollen ... ok, der Vergleich hinkt, wie alle Vergleich, aber ich denke es ist klar was ich meine und wo ich persönlich die Grenze sehe, auf jeden Fall eindeutig noch nicht bei Hochsitzen (oder Hochspannungsmasten, da war ja damals auch mal was ...) -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 14.03.2014 08:56, schrieb Andreas Schmidt: [...] Die Herren Hobbyschlachter [...] Ich verbitte mir eine solche Ausdrucksweise in öffentlichen Diskussionen. Man mag zur Jagd stehen wie man will, aber man sollte auch Menschen, deren Hobby man ablehnt, mit Respekt begegnen. Du willst ja auch, dass uns Mappern Respekt entgegen gebracht wird. Viele Grüße, Andreas - -- Andreas Neumann http://map4Jena.de http://Stadtplan-Ilmenau.de -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQGcBAEBAgAGBQJTItiQAAoJENEKAxYRlUN9WjEL/14h2UfyBlnEXKHn8HuvtMKI tOJ3/m0LdBZY0d25gL7LkdeCpOqrGYdo3aOYAjfaC1kgLv6s6UyFqV5/FrUansYz sAva65y8RpASMClP5yWXGga7J+2Iw0/16W5oa/14BCHqtwYVecOfHKEdiawBtAsa Fu0TtI6gh4EEkw4OfH0QaFqOGhdNu78bkjqpNLB9IApAp7kmzuft1dscbppnSnJP SyzoiyANmWy5LBlCVwEu0rMN4b9HNp+9unBQEbmUldEtIdOjUu58xG1R9xxsStw1 wPrES+SrKNDpVDQ303TxADZFf+JkDBp1G0sQw3XokHmfCMzjxgSEQ2058CL8Kz+o z8pG2VMFWjFQ34KhhqNWE2Sf1kdLDW8ZViG8H8ginqfpPIVHCfygbR2DkXJ/uPcd sFAQMOVW0ow7+/Sc1lFhbneka1648Dp6MbdB31cIxBdlL1yam3gPLApDMmIU61vg vRBHgu9TZCZNJ+Wt1mE8qqs/MXsklx07YQe72+0PrQ== =KlSX -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Am 13.03.2014 22:14, schrieb Michael Reichert: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Frederik, Am 13.03.2014 20:21, schrieb Dirk Sohler: Frederik Ramm schrieb: Ich weiss nicht ganz, wie ich darauf reagieren soll. Gar nicht. Hat er sich überhaupt mit mehr Informationen als seinem Benutzernamen bei dir gemeldet? Behörden machen auch in der Regel nichts, wenn man sich als superjaege...@yahoo.com bei ihnen meldet. So lange du die Hochsitze nicht betrittst, und der Wald öffentlich zugänglich ist, gibt es nichts, was gegen das Erfassen von Hochsitzen spricht, außer die Einzelmeinung desjenigen, der dich angeschrieben hat. Wir erfassen ja mittlerweile auch die Farbe von Gebäuden, die Privateigentum sind. Solange die Erfassung legal ist, gibt es IMHO keinen Grund das zu löschen. m.E. kann man bei uns alles erfassen, was von öffentlichem bzw. freigegebenen Grund aus zu sehen ist. Lediglich was man nur von privatem Grund aus sehen kann, mag eingeschränkt verfügbar sein. Da gab es vor einigen Jahren eine Diskussion bzgl. Fotorechten von Objekten in Sanssouci: die Fotos durfte man nicht so einfach nutzen / verkaufen, weil nur aus dem Park (Eintritt etc.) zu sehen / aufgenommen. (Weiß aber nicht, obs abschließend entschieden ist) So einen Hochsitz: natürlich kann man den kartieren. Die Wälder sind hier betretbar und ein Hochsitz ist auch eine Art Landmarke. Gegen Rowdytum muss sich der Jäger woanders / an anderer Stelle einsetzen. Freizeitheime oder so ... Grüße Ich finde das aber mit den Straftaten ein bisschen komisch, das klingt, als wollte man den Mapper unter Druck setzen und ihn zum Mittäter machen, wenn er nicht freiwillig seine Hochsitze löscht... Genau das. Daher: Einfach ignorieren. Soll derjenige doch klagen, mal sehen, wie weit er kommt :) Nicht antworten, ignorieren, aussitzen und abwarten, bis Gras darüber gewachsen ist, finde ich die beste Lösung. Wenn es ihm wichtig ist, wird er sich bestimmt nochmal melden. Also einfach gar nicht antworten, nicht ablehnen und nicht bestätigen/zustimmen. Das schlimmste, was passieren kann, ist, dass er (falls er überhaupt Jäger ist), von einem angesägten Hochsitz stürzt und dann zur Lokalzeitung rennt und die dann titelt: Computerfreaks helfen militanten Tierschützern oder Computerfreaks sabotieren Hochsitze :) Hoffen wir mal, dass er hier nicht mitliest und diese öffentliche Diskussion nicht über Google findet. Sollte er, weil du nicht antwortest, selber aktiv werden, hast du schon seit mehreren Monaten genügend Gründe für eine endgültige Sperre. http://www.openstreetmap.org/user_blocks/396 Wie lange sind wir dem Schleswiger hinterhergejagt? http://forum.openstreetmap.org/viewtopic.php?id=16891 Ok, es war nervenaufreibend und sollte vermieden werden. Fazit: Ignoriere es, erfreue dich der weiteren Antworten hier und kümmer dich um wichtigere Dinge. Viele Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] SOTM-EU - Vorträge einreichen
Hallo! Bitte Vorträge für die SOTM-EU einreichen, die Frist endet am 17. März! Details: https://sotm-eu.org/en/pages/cfp /al ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
On Fri, Mar 14, 2014 at 11:23:18AM +0100, Andreas Neumann wrote: Am 14.03.2014 08:56, schrieb Andreas Schmidt: [...] Die Herren Hobbyschlachter [...] Ich verbitte mir eine solche Ausdrucksweise in öffentlichen Diskussionen. Man mag zur Jagd stehen wie man will, aber man sollte auch Menschen, deren Hobby man ablehnt, mit Respekt begegnen. Du willst ja auch, dass uns Mappern Respekt entgegen gebracht wird. wir sind die Hobbymapper und stolz darauf! Wenn andere Probleme mit ihrem Image haben ist das nicht unser Problem. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Hartmut Holzgraefe hartmut.holzgra...@gmail.com wrote: Jetzt mal ganz blöd gefragt: werden Hochsitze auf den gängigen Karten überhaupt gerendert? Mir ist noch nie einer aufgefallen, das kann aber auch einfach daran liegen das hier in der Gegend keiner erfasst ist ... Die Reit- und Wanderkarte und diverse Garminkarten stellen sie dar. Sven -- Das Internet wird vor allem von Leuten genutzt, die sich Pornografie ansehen, während sie Bier trinken, es ist daher für Wahlen nicht geeignet (Jaroslaw Kaczynski) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Am 13/mar/2014 um 15:42 schrieb Falk Zscheile falk.zsche...@gmail.com: Vielleicht kann eine teporäre Herausnahme (z.B. durch Änderung des Keys) den Jäger davon überzeugen, dass seine Hochsitze auch ohne OSM beschädigt werden und die Leute auch so in den Wald gehen. dagegen Immerhin hat der Jäger angefragt, wenn auch nicht sehr höflich, und nicht gleich Hand an die Daten gelegt. wahrscheinlich wusste er nicht, wie es geht ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Hallo, Am 14.03.2014 16:50, schrieb Martin Koppenhoefer: Am 13/mar/2014 um 15:42 schrieb Falk Zscheile falk.zsche...@gmail.com: Immerhin hat der Jäger angefragt, wenn auch nicht sehr höflich, und nicht gleich Hand an die Daten gelegt. wahrscheinlich wusste er nicht, wie es geht ;-) Ich glaube, dass er das schon weiß. Wenn man einen User mit dem Namen Fidibus21 sucht, findet man zwei aufgehobene Sperren. Die Edits dieses Users zeugen von Löschkenntnissen (Daten, nicht Feuer): http://www.openstreetmap.org/user_blocks/396 Ich denke, dass er absichtlich gefragt hat, anstatt selbst Hand anzulegen, damit die DWG keine Rechtfertigung hat, Fidibus21 und alle künftig von ihm zum Löschen angelegten Sockenpuppen-Accounts zu sperren. Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Moin, mich erschreckt die kompromisslose Haltung und die teils aggressive Wortwahl als Reaktion auf eine höflich geschriebene Bitte. Ich habe in einigen Fällen darauf verzichtet, mir bekannte Fakten in OSM einzutragen. Einen Seeadlerhorst und den stationären Bauwagen eines Waldkindergartens habe ich gar nicht erfasst, ein außerhalb des Ortes gelegenes Vereinsheim ohne Beschilderung nur mit building=yes. Wir sollten in wenigen Einzelfällen auf Eintragungen in OSM verzichten, auch wenn kein gesetzlicher Anspruch darauf besteht. Hochsitze haben m.E. nur eine geringe Relevanz, da sie nicht zum Gebrauch für die Allgemeinheit bestimmt sind und wegen der getarnten Bauweise und relativ häufiger Standortänderungen auch schlecht als Wegmarke geeignet sind. Falls es in einer Region zu starkem Vandalismus an Hochsitzen gekommen ist oder der Anfragende sogar plausibel machen kann, dass OSM-Karten für gezielte Beschädigung genutzt wurden, könnte ich mir eine Entfernung dieser Daten vorstellen. Don't be evil. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Am 14. März 2014 18:11 schrieb Stephan Wolff s.wo...@web.de: Wir sollten in wenigen Einzelfällen auf Eintragungen in OSM verzichten, auch wenn kein gesetzlicher Anspruch darauf besteht. ja, aber darum geht es ja gar nicht. Klar trägt jeder nur das ein, was ihm sinnvoll vorkommt, und das er verantworten kann. Es geht hier darum, dass jemand darum gebeten hat, das von anderen eingetragene wieder zu löschen. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Meiner Meinung nach sollte man die Hochsitze nicht löschen, um keinen Präzedenzfall zu schaffen. Die Erfassung von Hochsitzen ist datenschutzrechtlich nicht zu beanstanden. Demnächst fordert dann jemand, wir sollten Höhlen aus OSM löschen (wie kürzlich bei Wikipedia geschehen) oder irgendein anderes Feature, weil das böse OSM angeblich zu Straftaten anstiftet/Hilfe leistet. Einen Beweis bleibt der Herr natürlich schuldig, oder hat er mit den noch nicht gefassten Tätern gesprochen? Am besten löschen wir auch gleich noch die Waldwege, damit sich auch ja niemand mehr im Wald orientieren kann. Bei der Beschädigung von Hochsitzen handelt es sich um eine strafbare Handlung. Man sollte dem Herrn daher ans Herz legen, diese bei der Polizei zur Anzeige zu bringen. Gruß Archer Am 14. März 2014 18:38 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 14. März 2014 18:11 schrieb Stephan Wolff s.wo...@web.de: Wir sollten in wenigen Einzelfällen auf Eintragungen in OSM verzichten, auch wenn kein gesetzlicher Anspruch darauf besteht. ja, aber darum geht es ja gar nicht. Klar trägt jeder nur das ein, was ihm sinnvoll vorkommt, und das er verantworten kann. Es geht hier darum, dass jemand darum gebeten hat, das von anderen eingetragene wieder zu löschen. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Università con più sedi e campus.
ciao a tutti. oggi il mio dubbio riguarda le grandi università che spesso non sono localizzate in un unico punto, ma il discorso può essere esteso a svariati ambiti (ospedali, circoli scolastici etc etc) nello specifico oggi ho provato a sistemare il Politecnico di Milano secondo la suddivisione fornita dal politecnico stesso: università-sedi-campus per cui uno o più campus formano una sede e più sedi compongono l'universita università (in questo caso sono 7 delle quali solo due a milano in quartieri diversi..le altre sono ognuna in una città diversa della lombardia). come faccio a classificarle e a mapparle? intanto il metodo: attualmente viene usato un sistema per cui tutti i campus appartengono a 3-2 relazioni multipoligono: una relazione riferita a tutte le sedi del politecnico (tag amenity=university + name=Politecnico di milano ecc ecc), una relazione per la propria sede di appartenenza (tag name=Politecnico di Milano, Sede Nome Sede) e una relazione se necessaria che definisce l'appartenenza di varie aree ad un campus (se non è necessaria la relazione i tag relativi sono applicati direttamente alla way perimetrale) Non sono sicuro questo sia il metodo migliore e più elegante...si protrebbero usare le parentele tra relazioni per cui le relazioni e le way che delimitano i campus diventerebbero relazioni figlie dei multipoligoni riferiti alle sedi e questi figli della relazione del università. un altro metodo potrebbe essere l'utilizzo delle relazioni site ma non ho assolutamente idea di come gestirlo (anche qui poi come? usando il metodo delle singole relazioni applicate ai singoli elementi o una gerarchizzazione tramite parentele?). altro dubbio è dove mettere i vari tag e che nome dare alle varie relation. direi di sicuro amenity=universityisced:level=4 e name=Politecnico di milano alla relazione che comprende tutti i campus. ma alle relazioni delle sedi e a quelle dei campus (o loro way chiusa perimetrale)? che nomi e tag uso? basta il nome della specifica sede e campus o devo ripetere ogni volta politecnico di milano da notare poi che nei campus non viene specificata la sede nel nome, ma il nome del campus e basta. quindi la sede a bovisa è al momento politecnico di Milano, Sede Bovisa mentre uno dei suoi campus a via La Masa è Politecnico di Milano, Campus La Masa a parte il fatto che la sede dal sito del poli viene chiamata Sede *di Milano* Bovisa c'è anche da capire se la virgola si possa usare all'interno del nome e non sia per caso più appropriato un altro segno. per sedi e campus da notare che teoricamente, a parte eventuali indicazioni sugli indirizzi, hanno solo il tag name e viene di volta in volta ripetuto il tag amenity=university...che non mi sembra corretto se è già sulla relazione generale del politecnico (quella con tutti i campus per intenderci). cosa e come faccio? grazie, ciao. ps: nominatim non sembra gestire bene i nomi lunghi delle varie sedi e campus :( - Ciao, Aury -- View this message in context: http://gis.19327.n5.nabble.com/Universita-con-piu-sedi-e-campus-tp5799685.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] commento su licenza odbl
Ciao, ieri, Simon Poole, chairman della openstreetmap foundation ha pubblicato un entry nel suo diario osm in cui parla delle clausole share-alike della ODBL: http://www.openstreetmap.org/user/SimonPoole/diary/21225 sabas, sbiribizio e io lo abbiamo tradotto in italiano e pubblicato al volo: http://openstreetmap.it/2014/03/in-quali-casi-vengono-attivate-le-clausole-di-condivisione-allo-stesso-modo-share-alike/ PS: se trovate errori, segnalatemelo per favore. -- -S ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: coperture in cemento - amianto
Cristian Consonni wrote Ecco qui di seguito cosa produce una ricerca in Emilia per roof:material=eternit nella pagina wiki per roof:material mi sembra ci sia un po' di confusione... oltre al discusso tag roof:material=eternit (forte comunque dei numeri in taginfo), c'è una classificazione mista materiale/conformazione mentre eternit e asbestos sono dei materiali, vegono definite anche tiles (tegole) e slates (lastre); la foto che ritrae quest'ultima poi rivela delle slates di eternit; credo che con questo sistema non si possa classificare bene. [1] http://wiki.openstreetmap.org/wiki/Key:roof:material - -- cascafico.altervista.org twitter.com/cascafico -- View this message in context: http://gis.19327.n5.nabble.com/coperture-in-cemento-amianto-tp5797289p5799696.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