[OSM-talk] Upload picture from OSM Contributor
Dear all, I am trying to upload a picture from OSM Contributor (Mobile App) but I do not know how to do. Anyone can help me. Thank you very much. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Community Data License Agreement – Permissive and ODbL?
Hi Maurizio, We did discuss CDLA at the last meeting, and are still considering what communications to put out about it. But for your specific situation of whether CDLA Permissive would be a good choice for Italian public administration officials/agencies, it could work, but I am not sure that the administrators would like CDLA Permissive any more than CC-BY. CDLA Permissive is not the same as CC-BY (there are some interesting differences in the details), but at a high level, CDLA would allow the public to use & redistribute the dataset for free. I'm not sure what concern they could have about CC-BY that CDLA would solve. Is this related to section 3.3 that you quoted? Also, (I don't know what you've tried asking the administrators before, so sorry if this is duplicative) have you already tried asking them just for permission to add to OSM? Or to license (or dual-license) under Open Government License or ODbL? Best, Kathleen On Fri, Oct 5, 2018 at 2:33 AM Maurizio Napolitano wrote: > On Wed, Aug 22, 2018 at 7:34 PM Kathleen Lu > wrote: > > > > WOF aside, we can put it on our agenda to discuss whether the > CDLA-permissive license is compatible with ODbL (note that there is also a > CDLA-sharealike, which is not compatible). > > I've started to see it mentioned in other circles as well. > > -Kathleen > > Hi Kathleen > Any news about the compatibility of the CDLA Permissive with the ODbL? > I want understand if the CDLA Permissive is a good license to spread > into the (italian) public administration with the goal to permit - > without problems - the import for OpenStreetMap. > By reading the license i found this point > > 3.3 You and each Data Provider agree that Enhanced Data shall not be > considered a work of joint authorship by virtue of its relationship to > Data licensed under this Agreement and shall not require either any > obligation of accounting to or the consent of any Data Provider. > > PS: > I don't intend to import the WOF data > I want to understand if this is the license to be taken by public > administrators who don't want to give up a license like che cc-by. > > -- > -- > Le informazioni contenute nella presente comunicazione sono di natura > privata e come tali sono da considerarsi riservate ed indirizzate > esclusivamente ai destinatari indicati e per le finalità strettamente > legate al relativo contenuto. Se avete ricevuto questo messaggio per > errore, vi preghiamo di eliminarlo e di inviare una comunicazione > all’indirizzo e-mail del mittente. > > -- > The information transmitted is > intended only for the person or entity to which it is addressed and may > contain confidential and/or privileged material. If you received this in > error, please contact the sender and delete the material. > ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Is it time to redevelop JOSM?
Hi, On Sun, Oct 07, 2018 at 11:26:20PM +0200, Frederik Ramm wrote: > Someone attempted to re-develop JOSM (as "JOSM-ng") in 2008 and even > then (with JOSM having a fraction of the features it has today) it > didn't get anywhere ;) > > I recently (on josm-dev) said that the actual code is not the essence of > JOSM, but the UI and workflow. I said that the actual language in which > it was written is irrelevant and that it could probably rewritten if > need be. But this was an opinion not widely shared among other > participants of the mailing list, and I guess they know what they're > talking about. > Writing a new piece of software that fully mimicks an existing program > is likely to be easier than developing a new editor from scratch, but > it's still a lot of work, and I don't currently see the need. I guess > there will be workarounds for many of the issues you mention, and some > issues are not work-around-able - for example, if your IT admin decides > that you should not be able to install software locally for security > reasons, then it is hard to envisage any kind of "offline editor" > working well. C# won't save you here. Over the last 2-3 years i am getting my trouble with josm because it is no longer an offline editor. Everyone who has tried starting josm on Edge type connections (Yes - i do have DSL Light with 384KBit/s at home) knows what i am talking about. For me the best case starting josm is 2-3 Minutes - YES Minutes. Worst case i am at 35 Minutes - Thats more than half an hour. This happens when some "view" decides that its time to update its png files from the web. The EU Sign file is 42 MByte which is at best case 35KByte/s - 1228 seconds to download. Just count the number of network requests for views, image layers, motd, plugins, user details, user messages and you know the pain. There is no way to make JOSM really an offline editor now. Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Is it time to redevelop JOSM?
On Sun, Oct 07, 2018 at 05:27:19PM -0400, Mike N wrote: > > I'm not saying C# is the only way to go. > > There's a lot to like about a C# solution, but currently lacks a cross > platform desktop graphics library. All the "Desktop pack" GUIs that Dotnet > Core supports are Windows-only. I don't know if there is a good > open-source cross platform desktop GUI for C# yet. Python/QT ? Flo -- Florian Lohoff f...@zz.de UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [HOT] [OSM-dev] Tool update from HOT: MapCampaigner
On Monday 08 October 2018, Harry Wood wrote: > [...] > > These tools have been known in OSM as "Quality Assurance" tools. To > Frederik's point, personally I actually think *this* naming, which we > settled on a long time ago, is weirdly over-broad. We should have > called them "data checks" or "data bugs" or something, because surely > "quality" of a map is much more than counting up how many data > glitches there are, and surely it *does* include how complete the map > is (e.g. complete with more rich POI coverage) Actually what we name quality assurance tools (i.e. Osmose, OSMI and similar) is fairly similar to techniques used in industrial production processes as part of quality assurance and quality management endeavours - with the same advantages and limitations. Like in those cases the term quality assurance is somewhat misleading since watching over process parameters and performing automated checks on its own does not in any way assure a certain level of quality. But detecting and quantifying quality problems is of course the first step towards assuring a certain quality level. And measuring production quantity is usually not part of a quality assurance process - unless it is part of a yield or efficiency measurement, i.e. relative quantity. Of course most of the quality assurance tools we have at the moment only measure plausibility and internal consistency of the data. We have only very few automated QA tools that use any kind of outside reference to gauge accuracy of the data. -- Christoph Hormann http://www.imagico.de/ ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [HOT] [OSM-dev] Tool update from HOT: MapCampaigner
On Mon, October 8, 2018 1:02 am, Harry Wood wrote: > >> Jean-Marc Liotier wrote: >> If one needs number to report back to donors, then integrate this >> sort of thing with the task manager - and explain to donors how >> erroneous data is sharply negative value > > I think this little "number to report back to donors" comment does betray > a belief I've heard expressed quite often in the wider OSM community, that > humanitarian mappers are allowing OpenStreetMap to be co-opted by large > aid organisations [..] In West Africa (the region where I have direct Openstreetmap experience and personal engagement with individuals), most organized mapping projects (rarely the largest contributions in terms of volume of data, but the most productive ones in terms of enrolling new contributors and weaving community connections) have at least some financial backing from organizations, not necessarily large ones. The training cadre spans the whole spectrum from pure volunteers to professionalized - and those are accountable to their backers, who expect a bit of reporting, which includes some measure of quantification. There is nothing wrong with that perfectly normal requirement but, as any manager knows, the temptation is strong to fulfil it using the easily available metrics. Balancing the key performance indicators mix to better align objectives with Openstreetmap's goals looks like a workable avenue of progress to me - to everyone's benefit, but that requires conviction about the complementary merits of quality vs. quantity and consensus about relevant metrics. Completeness measurements such as MapCampaigner's most certainly have a role to play, but my perception from wading in West African changesets is that not producing erroneous data is a higher priority. That conclusion may of course not apply to other regions I have no experience with. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
