Re: [OSRM-talk] Segfault with 5.4.0 osrm-extract and foot.lua
Hi, On 10/07/2016 09:43 AM, Frederik Ramm wrote: > I have finished bisecting the commits and ended up with > 2b466b2fb29c416149b4d881c151349218a63e1e as the first bad commit - > everything before that works, everything after that segfaults. I'll have > a closer look. I'm afraid I couldn't pinpoint the problem. I'm pretty sure there is *some* kind of memory corruption but exactly when and where it hits seems to be dependent on the STXXL configuration among other things. To summarize: * The problem is always reported as "double free or corruption (fasttop)" and leads to a segfault in osrm-extract on Ubuntu 16.04. * The problem affects all OSRM versions from commit 2b466b2fb29c416149b4d881c151349218a63e1e on (this means v5.2.7 is the last-known-good release). I read through that commit and couldn't immediately see anything that looks broken. * The problem does not occur with the "car" profile but it does occur with the "bicycle" and "foot" profiles. * The problem does not occur with data extracts smaller than ~ 2 GB but it does occur with larger ones. Sadly that made it impossible for me to find a very small input file that would provoke the crash, and any "valgrind" debugging was out of the question. I'll leave it at that and work with 5.2.7 which is good enough for my use case. Given that you say all profiles work for you in 5.4, it might be a funny edge case on Ubuntu or even on this particular machine I was running it on. Time permitting I might re-run on a different machine some time later. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSM-talk] Should we send automated "nag" emails?
Hi, On 10/09/2016 07:14 PM, john whelan wrote: > I'm seeing many many ways in the map which are untagged. Some are simply > area=yes and I suspect it is not just HOT mappers. HOT mappers or no, if there are many mappers doing this then the rewards must be calibrated badly. Ordinary mappers' reward, at least when they begin, is to see their stuff on the map. A way tagged area=yes will not be visible, hence no reward. We'd have to find out what (badly calibrated) reward these people get - are they driven by a teacher, a task manager, some leader board? *This* is what we should ask them - why did you map what you mapped, what incentive was there? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSRM-talk] Segfault with 5.4.0 osrm-extract and foot.lua
Hi, On 10/06/2016 09:28 PM, Frederik Ramm wrote: >so all OSRM releases up to 5.2.7 work ok on my machine and with my > input file and the foot profile; all releases from 5.3.0 upwards have > the segfault. I'll continue trying to identify exactly where it was > introduced. I have finished bisecting the commits and ended up with 2b466b2fb29c416149b4d881c151349218a63e1e as the first bad commit - everything before that works, everything after that segfaults. I'll have a closer look. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Segfault with 5.4.0 osrm-extract and foot.lua
Hi, so all OSRM releases up to 5.2.7 work ok on my machine and with my input file and the foot profile; all releases from 5.3.0 upwards have the segfault. I'll continue trying to identify exactly where it was introduced. (It could of course still be a funny problem with 16.04 or with my input file that somehow triggers the segfault, I haven't tried other environments yet.) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [OSRM-talk] Segfault with 5.4.0 osrm-extract and foot.lua
Hi, I've re-run with debug enabled but that wasn't much better: === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x77725)[0x7fd9e4134725] /lib/x86_64-linux-gnu/libc.so.6(+0x7ff4a)[0x7fd9e413cf4a] /lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7fd9e4140abc] osrm-extract(_ZN9__gnu_cxx13new_allocatorISt10_List_nodeIyEE10deallocateEPS2_m+0xc)[0x988c24] osrm-extract(_ZNSt7__cxx1110_List_baseIySaIyEE11_M_put_nodeEPSt10_List_nodeIyE+0xe)[0x988c34] osrm-extract(_ZNSt7__cxx1110_List_baseIySaIyEE8_M_clearEv+0x1d)[0x988c53] osrm-extract(_ZNSt7__cxx1110_List_baseIySaIyEED1Ev+0x9)[0x988c67] osrm-extract(_ZNSt7__cxx114listIySaIyEED1Ev+0x9)[0x988c73] osrm-extract(_ZN5stxxl9lru_pagerILj8EED1Ev+0x1d)[0x988c93] osrm-extract(_ZN5stxxl6vectorIjLj4ENS_9lru_pagerILj8EEELj2097152ENS_2RCEyED1Ev+0xe8)[0x9ad4bc] osrm-extract(_ZN4osrm9extractor20ExtractionContainersD1Ev+0x3c)[0x9ae67c] osrm-extract(_ZN4osrm9extractor9Extractor3runERNS0_20ScriptingEnvironmentE+0xbc2)[0x9bd03a] osrm-extract(main+0x22c)[0x9123cb] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7fd9e40dd830] osrm-extract(_start+0x29)[0x905799] On 10/06/2016 11:05 AM, Daniel Hofmann wrote: > I think we need more details here: first of all, it seems like Ubuntu > 16.04 ships Lua5.3 with apt, for which we saw an immense increase in > memory usage. I didn't get any out-of-memory errors. Also I didn't use Lua5.3, I only have 5.1 and 5.2: % dpkg -l |grep lua ii liblua5.1-0:amd64 5.1.5-8ubuntu1 amd64Shared library for the Lua interpreter version 5.1 ii liblua5.1-0-dev:amd64 5.1.5-8ubuntu1 amd64Development files for the Lua language version 5.1 ii liblua5.2-0:amd64 5.2.4-1ubuntu1 amd64Shared library for the Lua interpreter version 5.2 ii liblua5.2-dev:amd645.2.4-1ubuntu1 amd64Development files for the Lua language version 5.2 ii libluabind-dev 0.9.1+dfsg-10 amd64luabind c++ binding for lua: static library and headers ii libluabind0.9.1v5 0.9.1+dfsg-10 amd64luabind c++ binding for lua: runtime library ii lua5.1 5.1.5-8ubuntu1 amd64Simple, extensible, embeddable programming language ii lua5.2 5.2.4-1ubuntu1 amd64Simple, extensible, embeddable programming language and % ldd /usr/local/bin/osrm-extract |grep lua libluabind.so.0.9.1 => /usr/lib/libluabind.so.0.9.1 (0x7f2207e1f000) liblua5.2.so.0 => /usr/lib/x86_64-linux-gnu/liblua5.2.so.0 (0x7f2207bed000) > Then, can you tell us if you're using the default profile or did you > make any adjustments to it? None, using the standard foot.lua supplied with 5.4.0. I'll try (a) on a 14.04 Ubuntu, (b) with an older OSRM, (c) with a differently-produced Europe file to see what happens. Any other ideas are welcome. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
[Talk-GB] Upper Booth camp site, Pennine Way near Edale
Hi, OSMF board has received a complaint by the operator of the Upper Booth campsite, namely that they're seeing an increase of people trespassing due to OpenStreetMap featuring the campsite toilet as a public toilet. https://www.openstreetmap.org/#map=17/53.36523/-1.84623 I fixed that for them, but they have only replied with more (quote): > I have looked at the map and there are numerous other inaccuracies. > The ONLY footpath is the Pennine way from Edale to Upper Booth. NONE of the > paths indicated on the map that proceed north through Upper Booth Farm are > public footpaths, similarly the P marked is the private parking for campsite > users. > To the west of the farm is a stream running north /south there is only 1 > public footpath that runs alongside the stream NONE of the others indicated > are correct. I don't want to edit things based solely on what they're saying - I know that property owners sometimes have different ideas about which paths are private than the law. Maybe if someone passes that farm on a weekend out they can survey the situation and mark things as private where necessary. I'll place a note there linking to this message. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-de] OSMF-Spendenkampagne
Hi,
On 09/29/2016 10:01 PM, Tobias wrote:
> Gibt es denn einen besonderen Anlass? Gerade jetzt zu spenden? Wird das
> geld akut für etwas benötigt???
Ich habe ein geschätztes Budget für 2017 aufgestellt - also wieviel wir
wofür ausgeben werden und wieviel wir einnehmen - und da kam unten raus,
dass wir ungefähr 70.000 EUR mehr ausgeben werden als wir (ohne
Spendenkampagne) einnehmen. Das war der Auslöser für diese Aktion.
Die Haupt-Kostenstellen sind "Operations" (also Server) und "Legal"
(Markenrechte und Rechtsbeistand in Lizenz- und anderen Fragen), aber
wir haben auch Kosten für Steuerberater, Versicherung, Vorstandsarbeit
und neuerdings eine freiberufliche "Verwaltungskraft" ("admin help"),
die 1,5 Tage pro Woche für uns tätig ist.
Früher hat die SOTM immer genug Überschuss eingespielt, um die laufenden
Kosten der Organisation zu decken. Das ist aber jetzt nicht mehr der
Fall; wir können froh sein, wenn die SOTM eine schwarze Null schreibt.
Auf lange Sicht hoffen wir, mit unserer neuen "Firmen-Mitgliedschaft",
bei der Firmen zwischen 500 und 20.000 EUR im Jahr zahlen, finanziell
wieder sorglos dazustehen, aber im Augenblick sind wir in einer
Situation, in der die Einnahmen aus Mitgliedschaft noch nicht reichen.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMF-Spendenkampagne
Hallo, Mist, jetzt hab ich das wichtigste vergessen. Der FOSSGIS hat erklärt, dass er alle als OpenStreetMap-Spenden markierten Geldeingänge während der Laufzeit der Spendenkampagne an die OSMF weiterreichen wird. Das heisst, ihr könnt auch an einen deutschen gemeinnützigen e.V. mit deutschem Bankkonto spenden (Bankverbindung siehe https://www.fossgis.de/) und so die OSMF unterstützen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSMF-Spendenkampagne
Hallo, die meisten von Euch haben es sicher schon in der Wochennotiz oder im Blog gesehen, dennoch will ich hier noch einmal persönlich für die OSMF-Spendenkampagne werben, die wir auf der "State of the Map" gestartet haben (donate.openstreetmap.org). Viele Mapper und Leute, denen OSM am Herzen liegt, haben sich schon beteiligt. Wir versuchen diesmal aber besonders, auch diejenigen OSM-Nutzer zu erreichen, die nicht unbedingt zum Kern unserer Community dazugehören, sondern die "nur" Nutzer von OSM sind. Wenn ihr Leute kennt, die OSM-Daten regelmäßig nutzen, fragt die doch auch, ob für sie eine kleine Spende in Frage kommt! Wenn ihr OSM-Daten in irgendeiner Form weiterverteilt: Könnt ihr vielleicht Eure Nutzer mit einem kleinen Werbebanner über die Spendenkampagne informieren (so wie ich das z.B. auf download.geofabrik.de gemacht habe)? Vielen Dank für Eure Hilfe. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] Municipal Tree Survey
Hi,
On 09/19/2016 05:13 PM, Adam Old wrote:
> For the most part we would like to send people out using their mobile
> devices and an app like Go
> Map!! https://itunes.apple.com/au/app/go-map!!/id592990211?mt=8
> <https://itunes.apple.com/au/app/go-map%21%21/id592990211?mt=8> or a
> paper survey form that we could then update OSM with. Hopefully this
> would introduce a good number of new people to OSM as mappers and/or
> users.
Sounds like a win-win situation.
Two thinks you should be aware of though:
1. OSM usually maps what is visible on the ground. Whether a tree is
damaged or not, is something an experienced person could probably
determine with the naked eye, so that's ok. If you venture into the area
of rating things ("health of this tree from 1=perfect to 6=rotten") then
it becomes difficult, as people might disagree. Sticking to observable
facts helps avoid problems. "Date last cut" is also something that won't
be visible on the ground and hence isn't strictly something within the
OSM envelope but I guess it's harmless on the scale you're attempting it.
2. Putting data in OSM also means that you're surrendering any authority
over it; others who have no relation to your organisation can and will
modify (hopefully, improve) the data. I assume you'll count that as a
blessing and not a curse and then all is fine. It's just that some
people are peculiar with "their" data ("what, only registered and
trained members of the Springfield City Tree Board can be trusted with
assessing the tree cover, keep out you unwashed public" etc).
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Deleting / Closing / Renaming all places in a chain
Hi, On 09/07/2016 03:25 PM, Greg Troxel wrote: > Your comment comes across as bizarre and hostile to the US mapping > community, as if you think it's horribly broken and proving that > point is more important than improving the map. I think there's a misunderstanding here. I had the same comment when someone in Germany wanted to automatically remove all "Schlecker" drug stores. It is neither bizarre nor hostile. Any map in any country has its weak spots. If a chain restaurant in the US - or in Germany - changes its name overnight, some areas will be fixed quickly because they have local mappers who care, and other areas will take half a year or longer because they lack local mappers who care. This is an undeniable fact, and it doesn't have anything to do with whether this is in the US or in Germany or elsewhere on the planet. To me, *not* running an automated edit means honestly communicating to the map user where the weaker areas are (and that the map is likely more reliable in one part of the country than in another). Running an automated edit hides the weakness but doesn't fix it. There's no shame in admitting to a weakness in the map; on the contrary, admitting it is more likely to attract people who will help fixing it. And no, I don't think the mapping community in the US is horribly broken - it is just developing slower than I had hoped, and I see many attempts to make up for this slow development in ways that ultimately slow things down even further instead of helping. But this has absolutely nothing to do with the topic at hand; as I said, I've made the very same recommendation for the very same reasons in other countrie s. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] OpenStreetMap Awards - The Voting Has Started
Hi, On 09/07/2016 09:40 AM, Martin Koppenhoefer wrote: > as your vote is tied to your user account it should not be counted several > times, regardless how many times you send it in. Damn, NOW you tell me? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Deleting / Closing / Renaming all places in a chain
Hi, On 09/07/2016 02:48 AM, Mike N wrote: > But if one less > thing is wrong or outdated, that makes the data more useful to all clients. Except those humans who could have used that outdated thing as a marker to tell them that the map is dated. Yes they could look at the last modification date of things or analyze how many contributors the area has or myriad other OSM insider things. But seeing a "Domino's Pizza" on the map doesn't need an API, or insider knowledge, it doesn't even need a web site - it is the universal language of map dating. Automatically fixing that is like a car salesperson fixing a leak with bubble gum because it looks better and they can't be bothered to fix it properly. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-de] Karlsruhe Hack Weekend Oktober
Hi, hier die Wikiseite zum Hackweekend im Oktober: http://wiki.openstreetmap.org/wiki/Karlsruhe_Hack_Weekend_October_2016 Wie immer sind alle willkommen; eine fixe Agenda gibt es nicht, ausser, die Teilnehmenden bringen eine mit ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] Deleting / Closing / Renaming all places in a chain
Hi, On 09/06/2016 11:01 PM, Elliott Plack wrote: > Should we launch an automated edit, or some kind of batch process on OSM > to clear the database `name=ITT Tech` (or similar) worldwide? This is a discussion that has happened in the past when Domino's Pizza has rebranded, or when the "Schlecker" drug store chain closed in Germany. I think automated edits are not a good solution mainly for two reasons: 1. In many cases, the world doesn't change instantly at the behest of some guy in marketing or legal. Individual locations might retain their signage for various reasons and we map what's on the ground, not what's in the franchise agreement. Individual shops of a closed-down brand might remain open because of special local agreements that the automated edit has no knowledge of. 2. If a chain is renamed or closed country-wide, and this change is not reflected on OSM in one area, then this can be a valuable sign for lack of mapper attention. A sign that has the best user interface of all: Because for any map user, dealing with an outdated map is normal, and the way you identify just *how* outdated something is is exactly by looking at such things: "Ah, this map seems to be from a time then Domino's was still called Domino's Pizza!" - Leaving these valuable markers of outdated-ness in place tells the map user that this area hasn't been touched for a while and that the other POIs in the vicinity are likely also a bit aged. When a local mapper touches up the area they will likely also update other things than just the closed-down shop, and then the map will be current again. Automatically editing away something country-wide hides the fact that the map lacks attention in an area. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-ca] Forests/Land Use, was: Canvec reverts
Hi,
On Thu, Sep 1, 2016 at 11:27 AM, Adam Martin wrote:
> That is the key here. Deleting information without replacing it with
> something more accurate is inherently destructive. There must be
> some thought as to what will be put back or one is essentially
> ripping the map up simply because you don't like how something looks
> or how it closely it follows a given rule.
On a general note, edits *have* been reverted in the past for the simple
reason of not following a given rule, without looking at whether the
edit improved the visuals or not.
For "normal mappers", OSM ususally encourages them to map what they can
or know - no need to do it perfectly. Even a street drawn from memory
("I know I took a left here and then popped out onto XY road later, so
let me pencil in that road...) is ok for manual mapping.
For imports, we expect a certain minimum quality and if the importer
cannot produce that then we ask them to simply hold off the import until
they (or someone else) can.
The reason for the difference in approaches is that a productive
importer can import data in one day that takes several person-years to
fix and that will even have a detrimental effect on manual mapping of
other features (what Paul Ramsey writes further down-thread), whereas
imperfect data contributed by normal mappers comes at a rate where it is
realistic to assume that other normal mappers can fix it.
Data imports can have a negative effect on map quality (not even talking
of community engagement). "It looks nice on the map" can be a
treacherous criterion; beneath the surfaceit can still be rubbish, and
rubbish should not be imported into OSM even if it looks nice.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec Reverts
Andrew, On 09/02/2016 12:47 AM, Andrew Lester wrote: > If people from outside of Canada have decided that our data is so bad > that it needs to be completely wiped out in its entirety, then I guess > we're going to have to do something drastic to try to prevent this. I think a super good first step would be try and ensure that future imports are done diligently and don't introduce new issues. (This might be the "better documentation" step that Paul mentioned.) It really shouldn't be too hard to detect whether your planned import causes overlapping lakes and forests, but there needs to be an agreement that these things matter and that you cannot simply upload "because if CanVec says that forest and water overlap then this must be true". Then one could take stock of existing issues and make a plan on how to fix them. Whether fixing existing issues will necessitate the wholesale removal of some imports is something that should be decided down the line; I know too little about CanVec imports to say whether some problems are systemic in the data source, or certain regions, or just introduced by clumsy importers. Any large-scale removal of imported data (perhaps to replace it with new, better-imported data) would also have to take into account potential manual work that has been performed on the imported by mappers with local knowledge and it would be sad to lose that. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec Reverts
Sam, On 09/01/2016 11:26 PM, Frederik Ramm wrote: >> I believe the given what we have just spent the last 24 hours discussing >> this request is unreasonable and the issue is not significant. Thoughts? > > An importer who imports data into OSM that doesn't match up with already > existing data and doesn't notice it is careless and should do a better job. > > An importer who is asked to fix non-matching data he has accidentally > imported and responds that the request is "unreasonable" should have his > account taken away. It appears I have mistakenly thought that you, Sam, and the import user "sammuell" were one and the same. Apologies. I still think that if the importer cannot be bothered to fix it, the data should be removed until someone has the time to do it right (rather than keeping bad data in OSM until someone can fix it). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] CanVec Reverts
Hi, On 2016-09-01 21:06:57, Sam Dyck wrote: > I believe the given what we have just spent the last 24 hours discussing > this request is unreasonable and the issue is not significant. Thoughts? An importer who imports data into OSM that doesn't match up with already existing data and doesn't notice it is careless and should do a better job. An importer who is asked to fix non-matching data he has accidentally imported and responds that the request is "unreasonable" should have his account taken away. (This is my personal opinion. DWG is more nuanced but Paul Norman's message which you have read says clearly that the importer has the responsibility to see that the data matches up with existing stuff.) Either https://www.openstreetmap.org/way/406539219 is wrong, or the forest around it is wrong. And to quote someone else from this thread, the result is certainly not aesthetically pleasing either. You should find out which, and take appropriate steps. I am speechless to hear that not only are you importing broken data, but you also consider it unreasonable to fix it. If you can't be bothered to care for quality when importing, then don't, and wait for someone more responsible to come along. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
Re: [OSM-talk] SearchAroundBot: a Telegram Bot for OSM
Hi, On 08/24/2016 03:18 PM, Nicolás Alvarez wrote: >> Please ensure that everyone who contributes data to OSM with this bot >> actually has got an OSM account (and hence has agreed to the OSM >> contributor terms), and that the data is contributed using that OSM >> account (not a generic account that you have created), and that they can >> be reached by OSM user-to-user messaging if necessary. > Aren't there several cases where this isn't followed, like Wheelmap? Wheelmap is the only case I know of. If you know of more, please tell. The wheelmap case has been much discussed and their "wheelmap visitor" edits are tolerated because they never add new objects, and only add/modify one single tag between one of three settings. This was considered limited enough to be unlikely to risk copyright violations or trigger edit wars. Allowing wheelmap to do what they do was, however, never meant as a carte blanche for everyone to add data under "proxy users"; other requests to do that on a broader scale have routinely been rejected because they risk running into all kinds of trouble - legally and community wise. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SearchAroundBot: a Telegram Bot for OSM
Hi, On 08/23/2016 06:04 PM, Federico wrote: > I've recently developed a Telegram Bot > (https://telegram.me/SearchAroundBot) to enable users to easily add POI > (currently only drinking water and toilets amenities) into OSM. Here is > the OSM wiki page here: https://wiki.openstreetmap.org/wiki/SearchAroundBot Please ensure that everyone who contributes data to OSM with this bot actually has got an OSM account (and hence has agreed to the OSM contributor terms), and that the data is contributed using that OSM account (not a generic account that you have created), and that they can be reached by OSM user-to-user messaging if necessary. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MAPS.ME edits - partly sub-standard
John, On 08/18/2016 10:01 PM, John F. Eldredge wrote: > I know I am replying to a two-month-old message, but the idea of > restrictions on entering postal codes is baffling. At least in the USA, > the Post Office encourages the use of postal codes (called Zip codes) on > mail, Most people would think exactly like you do, and would also assume that of course it can only only be in the best interest of the post office if post codes are made available as widely as possible. However, and that's what I was half-jokingly referring to, Canada Post actually tried to shut down a crowd-sourced project that would record postal codes, and only very recently gave up on that. The story is here: http://www.michaelgeist.ca/2016/06/crowdsourcedpostalcodelawsuit/ Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] is legal-talk@openstreetmap.org searchable?
Hi, On 08/18/2016 10:01 PM, Thomas Gertin wrote: > is legal-talk@openstreetmap.org > <mailto:legal-talk@openstreetmap.org> searchable? Does anybody know the > link? There's an archive at https://lists.openstreetmap.org/pipermail/legal-talk/ where full months can be downloaded, but other than that, you need to use your favourite search engine with something like "site:lists.openstreetmap.org legal-talk mykeyword". Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] Deutsche Homepage - Fehlermeldung
Hallo, On 08/16/2016 08:06 AM, goegeo wrote: > Hallo Liste. Seit gestern wird mir beim Abrufen der deutschen > Openstreetmap-Homepage (https://www.openstreetmap.de) folgender > Warnhinweis für eine mangelhafte Seitenkonfiguration dargestellt. Die Seite wurde am Wochenende auf einen neuen Server umgezogen, das Zertifikat kommt noch nach ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-GB] [OSM-ja] wrong tag "tunnel_name" "bridge_name"
_ >>> Talk-ja mailing list >>> talk...@openstreetmap.org <mailto:talk...@openstreetmap.org> >>> https://lists.openstreetmap.org/listinfo/talk-ja >>> <https://lists.openstreetmap.org/listinfo/talk-ja> >>> >>> >>> >>> >>> >>> ___ >>> Talk-ja mailing list >>> talk...@openstreetmap.org <mailto:talk...@openstreetmap.org> >>> https://lists.openstreetmap.org/listinfo/talk-ja >>> <https://lists.openstreetmap.org/listinfo/talk-ja> >>> >>> >>> -- >>> Twitter : @k_zoar >>> OSM: http://hdyc.neis-one.org/?k_zoar >>> <http://hdyc.neis-one.org/?k_zoar> >>> >>> >>> ___ >>> Talk-ja mailing list >>> talk...@openstreetmap.org <mailto:talk...@openstreetmap.org> >>> https://lists.openstreetmap.org/listinfo/talk-ja >>> <https://lists.openstreetmap.org/listinfo/talk-ja> >>> >>> >>> >>> >>> ___ >>> Talk-ja mailing list >>> talk...@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-ja >> >> >> >> ___ >> Talk-ja mailing list >> talk...@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-ja > > > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Newbie in East Midlands asks for help adding data
Hi, guy on the help forum asking for someone to help him edit OSM, perhaps there's a suitable meetup he can be directed to: http://help.openstreetmap.org/questions/51360/newbie-200-places-to-add-and-i-want-to-get-this-right-the-first-time Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-us] [Imports] Proposing import of sidewalk data Seattle, WA, USA
Clifford, On 08/02/2016 05:59 PM, Clifford Snow wrote: > We tell people not to map for the renderer. In the same spirit shouldn't > we tell people not to let the limitations of the editor stop them from > mapping? Usually, when you deal with individual mappers who come up with a tagging scheme, you can simply let them try it because they are just one person and the amount of stuff they can survey in any given time is limited. Before they can break a lot, others will notice what's going on, and a discussion can develop. Importing sidewalks for a large city is something different. It allows you to add thousands of objects in a short time frame. Hence the request to "talk before you import" - something we don't expect from the hobby mapper who adds a few sidewalks according to a tagging schema he has made up. > I'm not following you. They did announce their plans and are discussing > the proposal with the community, including how to route. I am concerned that they might want to start importing data 5 days from now which is certainly not enough time for a solid discussion. Maybe I misread. > Unlike existing routing systems, they are proposing to enable people > with limited mobility to find a route to their location. As I have said, there have been a number of publicly funded projects that had this laudable aim. Solving the issue by adding ways for every sidewalk is one of many potential solutions; a solution that has advantages and drawbacks which should be discussed widely before an import is done to "kick-start" world-wide adaption of a tagging schema. > Yet their plan is the easiest for a new mapper to follow. I've followed > mapping of sidewalks. Where are these proposals you talk about? I linked some in my post to the tagging list. Some of the failed/single-minded projects in the past didn't even bother documenting their tags on the wiki, insofar this project is superior - and it's totally ok for them to start a discussion. Just not an import one week after mentioning that by-the-way-we-have-a-proposal-here ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Proposing import of sidewalk data Seattle, WA, USA
Meg, sidewalk tagging in OSM is a complex issue. The fact that sidewalks are not tagged as individual geometries is not purely a shortcoming, it is a compromise that keeps OSM data editable. Having individual geometries for every single sidewalk on the planet will not only massively increase the data volume but also require new and better tools for editing, e.g. moving the geometry of a street without having to move three parallel lines manually and so on. There have been several local imports of sidewalk data that were removed again because lack of prior discussion and/or because they were single-purpose imports that did not care about integration with the rest of OSM (for example: what should rendering engines do with sidewalks; how do they integrate with normal footways; how is a sidewalk linked to the road along which it runs so that routing engines can say "follow sidewalk along XY road" instead of "follow unnamed footway"; how can routing and rendering use individual sidewalks and still gracefully fall back to another method where these are not defined, and so on). People are experimenting with different ways of mapping sidewalks. Under no circumstances should you perform an import that creates facts before your proposal for separate mapping of sidewalks has been discussed more widely. Several ideas have been proposed to get around mapping sidewalks as individual geometries, which is in many ways the most primitive way to tackle the problem and the one that puts the most work on the shoulders of our volunteers. Your wiki page states that you had "feedback from the global OSM community"; I'm surprised that these details seem to have escaped you until now. Which sidewalk mapping experiments in OSM have you studied, and what have you learned? Which global OSM community did you talk to and where? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Kansas City addresses from maps.kcmo.org
Hi, On 07/29/2016 11:46 PM, Jonathan Schleuss wrote: > I'm kind of curious about this. Why not import those property lines? I'm > not arguing for them, because it seems like a lot of work. But I note > that in cities such as Fresno, they are in the map > <https://www.openstreetmap.org/#map=17/36.74878/-119.71442> as > landuse=residential. Yes, sadly some imports have been done in the past without consultation and it will take some time to get rid of them. > What if we add all the buildings, all the trees, > every bench? Why not add property boundaries? I'm thinking 2030 here. If there's a fence on the boundary, you can map the fence. Or any other physical marker, if you so desire. Mapping in-visible boundaries is a bad idea because it runs against our desire to have things verifiable on the ground - this is one reason that keeps us safe from a whole class of edit wars where people disagree about something that cannot be proven. We make an exception from that rule for admin boundaries because their usefulness is so high that it overrules the problem (usually) not being visible on the ground. OpenStreetMap is, mostly, a project driven by people who contribute data that they survey. Data imports can occasionally help but they're not the mainstay of OSM. A data set of parcel boundaries can easily be displayed on top of OSM, or integrated into your rendering stack if you need these boundaries, but it doesn't make much sense in OSM because it will usually not be curated by individual mappers. It would just sit there, being replaced by a new import once a year (or not) - OSM would be abused as a data transport for third party data. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Kansas City addresses from maps.kcmo.org
Hi, On 07/29/2016 03:42 AM, Clifford Snow wrote: > Thanks for pointing out my lapse. You are correct. I've used parcel > boundaries for parks a number of time. Nonetheless (in order not to confuse the original poster) let's reiterate that property lines themselves do not belong in OSM; only where they can be used to deduce the bounds of something we *do* want in OSM will they find their way into the database. We will not map individual property lines in e.g. a residential neighbourhood (much less import them). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Go Map!: Mobile mapping on iOS
Hi, On 07/26/2016 01:32 AM, Matthijs Melissen wrote: > I'd recommend every iOS user to give the application at least a try. I can't speak to the qualities of Go Map! but I think your review should also mention the fact that this is proprietary software - it doesn't cost anything but you can't look at the source. In that, it is different from almost every other OSM editor widely used. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] attributive data enrichment using OSM
Hi, On 07/25/2016 09:05 AM, Stefan Jäger wrote: > That, in turn, means, any data put together using also OSM data, that is not > publicly accessible, but only in internal networks, can be produced? In the terms of ODbL, "publicly" means (quote) "to Persons other than You or under Your control by either more than 50% ownership or by the power to direct their activities (such as contracting with an independent consultant)." Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-de] Einladung 2. OSM Sommercamp
Hi, On 07/19/2016 09:08 PM, Frederik Ramm wrote: > Hallo Marc, Ups, das sollte gar nicht an die Liste, sorry. Muss mal mit dem blöden Listenadmin hier reden wegen des reply-to ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einladung 2. OSM Sommercamp
Hallo Marc, sind wir schon ausgebucht oder kann ich mich noch eintragen? Bye Frederik On 07/13/2016 08:57 PM, Marc Gehling wrote: > Hallo, > > freundliche Erinnerung. Am 15.7.2016 müssen die Zimmer im Hotel reserviert > werden. Nach dem 15.7. kann nicht garantiert werden, das gewünschte Zimmer zu > bekommen. > > >> Am 20.06.2016 um 21:34 schrieb Marc Gehling <m.gehl...@gmx.de>: >> >> Der FOSSGIS e.V. lädt zum 2. OSM Sommercamp im Linuxhotel ein. >> >> Das Treffen findet vom 12.-14. August 2016 statt und kann vielfältig genutzt >> werden. >> >> OSM Aktive können das Wochenende als Arbeitswochenende für Projekte nutzen, >> es soll Workshops rund um OSM geben ... >> Communities und Interessierte aus freien GIS und Geodaten-Projekten können >> das Wochenende nutzen, um die jeweiligen Projekte voranzubringen. >> Es stehen etwa 30 Hotelbetten für uns bereit sowie eine Wiese zum Campen. >> >> Bitte tragt Euch und falls vorhanden Euer Projekt oder Eure Idee, die Ihr >> umsetzen wollte, möglichst bald im Wiki ein. Die Anzahl der >> Übernachtungsplätze ist begrenzt. Also schnell eintragen! [1] >> >> Weitere Ideen und Anregungen zur Ausgestaltung sind gerne gesehen und werden >> bestimmt aufgegriffen. >> Die Fossgis Community ist ebenfalls eingeladen, siehe 6. Fossgis Hackweekend >> [2] >> >> Wir freuen uns (mittlerweile zum 2. mal) auf ein gemeinsames SommerCamp im >> Linuxhotel. >> >> [1] http://wiki.openstreetmap.org/wiki/SommerCamp_2016 >> [2] https://www.fossgis.de/wiki/FOSSGIS_Hacking_Event_2015_Nummer_6 >> > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de > -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] What3words
Hi, On 07/13/2016 12:37 PM, Colin Smale wrote: > On 2016-07-13 12:24, Dave F wrote: > >> >> On 13/07/2016 11:10, Frederik Ramm wrote: >>> >>> W3W is a coordinate system... >> >> I fail to see how it can even be described as that as there is no >> coordination. The address of one block has no relation to adjacent ones. >> > Agreed - it's not a coordinate system, it's an addressing system, i.e. a > way of encapsulating a location in a convenient manifestation. I think we might not be understanding each other. Dave says "coordinates need coordination" which makes you conclude "see, if it's not a coordinate system it must be an addressing system". I agree with neither. Really, please don't buy the w3w propaganda in this respect. An addressing system usually is hierarchical - country, then perhaps a state or district or postcode, the a city, then perhaps a neighbourhood, a street, a number, and perhaps an apartment or level number. There are differences but you can usually tell from addresses where they are, approximately, and if you can't pinpoint it right away you can follow the hierarchy (go to the town then ask for the street etc.). You can tell if two addresses are near each other. There may be brokers that tell you where on earth an address is (geocoding systems) but they are not a mandatory part of resolving the address. There are so many things that humans associate with an address, and w3w tries to piggyback on that by calling their coordinate system (or, if you want, their map projection) an addressing system, but it's not, or at least not more than the "addressing system" of lat/lon/ele is. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What3words
Hi, On 07/13/2016 11:35 AM, Colin Smale wrote: > I disagree with this... They are not trying to replace / fix up lat/lon, > they are providing a lingua franca for people to use when communicating. > It's an alternate form of address, not an alternate form of location. No. It is a core element of W3W marketing to call their system an "addressing system", but it has virtually none of the properties that an addressing system has. W3W is a coordinate system, not an addressing system. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Mobile Verkaufsstände
Hi, On 07/13/2016 10:37 AM, Sven Geggus wrote: > Wenn ja, gibt es einen Tag, der signalisiert, dass das Teil da in 95% der > Zeit in der man vorbeikommt überhaupt nicht anzutreffen ist? amenity=fast_food fast_food=intermittent ;) Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Automated edits code of conduct
Hi, On 07/12/2016 03:03 AM, tuxayo wrote: > The questions is how legitimate are they. To know if we can enforce them > strictly. Enforcing anything "strictly" is likely to cause problems. Rules can only be enforced strictly if they are so well written that any idiot can enforce them by simply following the instructions ;) For example, a few years ago we had a user called "worst-fixer" or so who did a couple of large-scale edits removing the "created-by" tag. Now this was a mechanical edit against the rules, and there was a consensus in the community to remove those unwanted tags piecemeal instead of creating a new version for hundreds of thousands of objects, needlessly. Strictly enforcing rules would have meant reverting all these edits but that would have been quite silly (causing another extra version to be created), so they were allowed to stand. The rules we have are guidelines, and they depend on respectful human beings letting themselves be guided by them while trying to reach a common goal, together. The rules are not made for being followed blindly, "by the letter". Having such rules would put us firmly into Wikipedia territory and open us up to "lawyering" on the part of those who commit mischief but found a loophole in a rule that seems to allow it. > That would also allow DWG members to intervene with a greater legitimacy > because it would not come from their status. Having a DWG whose legitimacy comes from rules would allow everyone to start endless discussions about DWG's interpretation of the rules, or finding loopholes in the wording. This is what happens in Wikipedia and it allows troublemakers to waste an awful lot of volunteer time by posing as innocent, rule-abiding people. > I agree that showing them at sign up wouldn't help. However it's to be > expected that first time mass edits are done without knowing the AECoC > as nothing more than the JOSM search and replace tool is needed. Is not > like importing which require more documentation. Perhaps we could make JOSM cleverer in detecting such cases and alerting people to the rules. JOSM already pops up tons of warnings - about moving lots of nodes, about displaced aerial imagery, etc. - it could also say "you're changing a lot of objects over a geographically large area at the same time and you haven't zoomed in on any, are you sure you have read the rules..." > The reporting of AECoC violations could be done in a dedicated open > mailing list so we could have accountability about how these issues are > handled. > *Any thoughts about this? This is a concrete proposal.* DWG is happy about every case that the community manages to handle between themselves, without DWG having to get involved. If such a mailing list would help taking some of the load off DWG's shoulders and DWG would then only deal with those cases that the community can't handle or where things aren't clear enough, sure that would be great. >> I'm all for discussing the rules we have, but I'd like to know what >> exactly the problem is. "There has been no vote on these rules" is not >> the honest reason for this thread > Why? Considering the standards required for tags and automated edits, > not having comparable ones for the content of the AECoC is inconsistent > compared to it's importance. The rules about automated edits stem from their ability to upset many people in the community. Reverting an automated edit will usually only upset one person. It is a logical fallacy to believe that just because automated edits are a problem that needs to be regulated, the reverting of automated edits needs to be regulated as well. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM usage violation
Hans, On 07/11/2016 11:03 PM, Hans De Kryger wrote: > Not satisfied with that answer. The dude didn't get it. Well you could have made it clearer ;) his license text is wrong, mentions CC-BY-SA when the data is clearly ODbL. I'd suggest something like: "Dear X, I am a member of the OpenStreetMap community that creates all the data you're showing on your map. We let you have this data free of charge, but in return we ask for proper attribution that makes it clear to the users of your app that the data comes from us. Other cycle maps on the web present OSM directly on the map page, for example http://cycle.travel/map and http://opencyclemap.org/. We respectfully ask that you acknowledge us as your data source on the main map also, and not hidden in a menu. Also, your acknowledgement still mentions the CC-BY-SA license which we don't use for our data any more, it is the ODbL nowadays." Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Fwd: Automated edits code of conduct
Hi, On 07/11/2016 02:02 AM, Éric Gillet wrote: > If you do a search-and-replace on 20 elements and review manually the > change, it is covered under the AE CoC. No, the document clearly states in the "Scope" section: "use of find-and-replace functionality using a standard editor such as JOSM or finding using services such as Overpass API and changing without reviewing cases individually;" Sadly, we often have people who run search-and-replace operations and *claim* that they have "reviewed cases individually", and then if you look at their edit, they have changed a tag on a POI that sits in the middle of a road or so - which means that they were either lying, or they have only done a very, very cursory "manual review" of their change. An automated, or mechanical, edit is when you do not look at the individual object you're editing. There is no similar policy covering manual edits. But of course if someone *manually* changes 500 landuse=wood to landuse=forest across the planet, it is still possible that they make a mistake and it needs fixing in some way, or if they do it repeatedly and cause problems with it, they might still be blocked. This is not a court system; DWG doesn't need a law on the Wiki to take action against someone who causes trouble. However, causing trouble through manual edits is so much less frequent than causing trouble with mechanical edits that we have written up a policy on the latter. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Automated edits code of conduct
Hi, On 07/11/2016 01:23 AM, Matthijs Melissen wrote: > My main issue with the AEcoc is that it is nearly impossible to comply > with, especially the part that says that community consensus is > necessary (or rather, "said", because this requirement seems to have > been silently removed). Which part has been removed and by whom? The December 2014 version says: "If you plan to make an automated edit, outline it beforehand and discuss it on a suitable mailing list ... We do not require or recommend a formal vote, but if there is significant objection to your plan - and even minorities may be significant! - then change it or drop it altogether." and "OpenStreetMap is very much built on consensus. A majority of voices on a mailing list does not give you the right to do whatever you please to the data created by the minority. ..." The current version says: "If you plan to make any automated edit, you should discuss and document your plans beforehand. Documentation should be placed on the wiki and the proposal should then be discussed them on a suitable Mailing lists: ..." and "OpenStreetMap is built on consensus, rather than a majority voting and you should therefor be sensitive to proceeding with major changes even where the great majority support the change." There might be a potential misunderstanding here; some people seem to believe that the policies outlined in the Wiki are some kind of "law" and that if you comply with it, you are always "right". (Wikipedia tends to run into a "lawyering" problem with this - they have policies, they call somebody out for doing something stupid, and the person then says "but I have followed all the policies, you cannot do anything, ha ha!". This is great fun for those who do stupid things and have a lot of time to conduct procedural discussions, and a great nuisance for everybody else in the project.) In reality, the automated edititing rules are general guidelines set up to minimize problems but you can follow them and *still* cause problems (a fact that is mentioned in the document: "If you have followed this policy then this means your account will not be blocked right away when someone complains, but you might still have to change or stop what you're doing if people dislike your actions and / or their side-effects.") You might say that the whole document is just a more wordy version of "if your edit pisses people off, you'll get into trouble". > Could you point me to a single worldwide mechanical edit that > satisfies the AEcoc guidelines? I can't but then we don't track them at DWG - we don't grant permissions, we only act when we either hear complaints, or see faulty (or otherwise problematic) edits ourselves. Haven't you done something about musical instruments once? IIRC there was a bit of an issue with you asking for a "vote" on the issue, thereby making it sound as if 51% were enough to carry such an edit... but you did run it in the end, didn't you? Personally, I think that world-wide mechanical edits should be the absolute exception since it becomes more and more difficult to engage the world-wide community in a discussion; the danger of causing problems in a far-off corner of OSM with an automated edit is just too big. Having said that, if someone makes a world-wide edit that they discuss on the talk or tagging lists before and that are ok with everyone (or almost everyone) there, they have at least shown diligence and a will to do it right. If they run their edit and then someone from Peru complains, they might still need to revert or fix it, but at least they're not the lone-wolf guy who didn't care what others think and DWG will certainly treat someone who tried to do it right but failed differently from someone who didn't even try! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Automated edits code of conduct
Hi, On 07/10/2016 11:26 PM, Éric Gillet wrote: > However, another distinct set of rules is also being enforced by the DWG > : the Automated edits code of conduct This whole discussion seems to have its origin in this changeset: http://www.openstreetmap.org/changeset/27888534 Where - for the umpteenth time - someone thought it was a good idea to replace landuse=forest with landuse=wood world-wide, without looking at individual cases and motivations. The user was contacted http://www.openstreetmap.org/changeset/27656417 but insisted that his mass edit was generally ok (while acknowledging a small mistake regarding deciduous/broad-leved). His edits were then reverted. Because his edits stretched over several days and changesets, and because the changeset comments contained no hint at whether or not the particular changeset did contain this kind of un-discussed mechanical edits, the DWG member executing the revert - that was me - only did a cursory inspection and in doing so, reverted a few changesets that were *not* mechanical edits. (This was not the first time the user had been called out for ill-conceived mass edits; he first came to DWG's attention because a US mapper complained about http://www.openstreetmap.org/changeset/27644435 which makes world-wide changes to some natural=water objects.) The user was unhappy, but my reaction was the verbal equivalent of a shrug; if you make a mechanical edit, refuse to concede that you made a mistake, and your edit isn't even clearly recognizable then you have to accept a little collateral damage. DWG has only a finite amount of time to deal with problems and while it would be great if we could sort through a problematic changeset or series of changeset and separate the good from the bad, sometimes the presence of enough bad stuff can lead to a wholesale revert. This whole changeset was about a year ago but recently I was contacted by one user, tuxayo, asking me to concede that mistakes were made handling that particular revert, and would I please answer the open questions raised by user Test360. I explained everything I wrote above, but apparently this was not sufficient, as today I received another message, this time by user gileri, asking me to comment, and now this thread. The automated edits code of conduct is there for a reason; had user Test360 complied with it, then his edit would likely not have been faulty (e.g. the deciduous/broad-leved mistake), and would not have had to be reverted. The same is true for user gileri's edit in http://www.openstreetmap.org/changeset/27867757 which, had he discussed it before, would likely either not have been executed, or at least not have been executed in a way that drew complaints. The automated edits code of conduct has been created as a result of DWG work, where we often have to deal with the detrimental effects of badly planned, badly executed lone-wolf edits. This is just one of many rules that have been developed in the community; some are written, some are unwritten. Take, for example. changeset comments: While there are recommendations to use good changeset comments, this is not usually enforced. But if there are complaints about someone's edits, DWG may occasionally tell them that they *must* use good changeset comments or we'll block them. Or even basic rules about respect and politeness; they're not enshrined anywhere or shown to you before you sign up. We also have import guidelines (which, by they way, were the reason for another anti-DWG storm in a French teacup a couple years ago when DWG requested that Cadastre importers use a separate import account). Is it *really* a problem that some rules are not shown to people when they sign up? In my opinion, mass edits are an advanced enough topic that, if you research it enough, you *will* be pointed to these rules, or find them in countless answers on help.openstreetmap.org. I'm all for discussing the rules we have, but I'd like to know what exactly the problem is. "There has been no vote on these rules" is not the honest reason for this thread and I refuse to be drawn into an insincere, endless procedural discussion just because someone has an axe to grind with DWG. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Map spam
Hi, On 07/10/2016 09:45 PM, Mike N wrote: > I have seen a number of these - at first there was some app generating > invalid OSM tags, but excellent geolocation (to OSM standards, center of > main business building). Side note on "we place you on the map" businesses - they often don't have first-hand knowledge about their client's location so will place the node exactly where some geocoding engine says the address should be - which is usually not desirable: Either the geolocation engine is Google etc. in which case data is added to OSM in violation of Google's terms, or the geolocation engine is Nominatim which will, in the US, often rely on imperfect TIGER house numbers or interpolation lines, and when such an imprecise match is converted into a node with addr:* tags we have an illusion of precision that doesn't hold. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Map spam
Hi,
On 07/10/2016 08:28 PM, Jack Burke wrote:
> Is anyone else starting to see map spam popping up in their areas?
DWG here. We see lots, but not to a degree that would concern us.
Occasionally individual IP numbers from Asia were blocked for signups
because they would create account after account just to add one POI. We
still have some low-volume background noise of spammy node additions
(http://overpass-turbo.eu/s/hei for examples) that seem to be
orchestrated in some way, but apparently not through sweat shops in
low-wage countries but rather using software that runs on the Internet
connection of whoever buys the software.
The individual business owner adding their own business in good faith is
of course something we want to encourage, so before you delete something
as spam, try to (as you have) make double sure that it is not just a
bumbling newbie; when in doubt, try to raise them via a changeset
discussion entry ("Hey, welcome to OSM, I see you have tried to add your
business here but it seems you placed it bang in the middle of a
residential neighbourhood, can I help you fix that"). If they don't
reply, delete the data; if continue adding rubbish data without
replying, report them to DWG at d...@osmfoundation.org for a dressing-down.
> Specifically, what I'm finding is a well-formed node for a small
> business, complete with phone number and (on 2 of them) websites.
Web-only businesses (that are run from someone's living room who doesn't
want customers to ring his doorbell) don't have a geographic footprint
and hence don't belong in OSM.
> Because the entry was so well-formed, I'm going to assume that the
> person is familiar with OSM and the account was created specifically to
> make this one entry. Also, because it was a single node in an otherwise
> mostly-complete area, I'm going to assume that the person made a
> reasonable guess that the node wouldn't be noticed.
You're likely over-estimating their thought process.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-de] Wie viel Werbung sollte in die Wochennotiz?
Hi, On 06/30/2016 11:32 AM, Christoph Hormann wrote: > Gehört jetzt nicht mehr direkt zum Thema aber die Lösung ist hier denke > ich nicht ein paar bis ein paar hundert Voll-Stipendien zu schaffen. Ich glaube, die aktuelle Kalkulation ist, dass ca. 20 Vollzahler ein Stipendium schaffen, d.h. wenn das klappt, wären 5% "Stipendiaten" anwesend. Ich finde das aber auch nicht so gut, man erkauft sich auf diese Weise eine unechte "Diversität", denn wie Christoph richtig sagt, müssen die Ausgewählten ja durch lauter Reifen springen und sind eben nicht den normalen Teilnehmern ebenbürtig. Eventuell muss man doch die regionalen Konferenzen stärker stützen, statt weiterhin die eine internationale zu pushen. > Wenn ich bei der diesjährigen SotM einen Eintrittspreis von 75 Euro und > eine einzige empfohlene Unterkunft für fast 100 Euro pro Nacht sehe, > dann kommuniziert das für mich nicht eine Community-Konferenz, sondern > im Grunde, dass ein paar Firmen und professionelle Akteure sich ein > paar ausgewählte Eingeborene aus der Provinz für die passende > Atmosphäre einfliegen lassen. Sorry falls ich da jetzt jemandem mit > auf die Füße trete, ich sehe schon auch, dass sich da auch Leute > selbstlos engagieren. Da kann man sicherlich viel verbessern. Ich vermute, dass man aus Mangel an Manpower die Hotelempfehlung komplett an den vom Stadttourismus finanzierten "Booking Desk" ausgelagert hat; von dem sind dann eher keine Budget-Empfehlungen zu erwarten. Es laufen schon jetzt die ersten Vorbereitungen für die 2017er Konferenz; jeder, der einen Beitrag dazu leisten kann und will, dass 2017 alles besser wird, der sollte sich bei der SOTM-Working Group einklinken und mitmachen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] What should we do for wildfires?
Hi, On 06/30/2016 06:53 AM, Jonathan Schleuss wrote: > We could probably find places inside the U.S. that > are at a high risk and task those areas out. I'm not sure I understand fully; are you planning to do something about regions where a fire has happened and therefore our pre-fire data might now need correcting, or are you talking about areas that are at risk - and what would you "task out" about such areas? Pre-emptively improve their mapping in order to make the data better for emergency response? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] MAPS.ME edits - partly sub-standard
Hi, On 06/21/2016 11:07 AM, Richard Fairhurst wrote: > Perish the thought that people might add their local knowledge to OSM. I > thought it was all imports, armchairing and tagwanking these days. Only Canadians are allowed to enter their own post codes. The other countries haven't had their lawsuits resolved yet. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MAPS.ME edits - partly sub-standard
Hi, On 06/21/2016 08:44 AM, Simon Poole wrote: > The problem is not with people that know what the conceptual trade-offs > are and if they so want could generate a more current map. Well Nicolás said that maps.me do already produce daily maps. Daily updates of course would still lead to more conflicts than a semi-live editor like Vespucci but I guess it would be acceptable. It sounds like all that's missing is for the application to refuse edits to a map that is too old (or at the very least allow that under protest)? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] MAPS.ME edits - partly sub-standard
Hi, On 06/20/2016 11:49 PM, Andrew Harvey wrote: > The down side of course is that the Maps.me data isn't updated very > frequently so I might be duplicating data which has been added after > Maps.me last generated the data extracts, Isn't Maps.me Open Source - could not someone else simply make current extracts available? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Neues vom deutschen OSM-Kartenstil
Hi, On 06/16/2016 12:47 AM, Christoph Hormann wrote: > Mittlerweile ist der internationale Stil teils sehr > restriktiv hinsichtlich der Änderungen, die akzeptiert werden Also ich würde mir schon auch für den deutschen Stil wünschen, dass er recht restriktiv ist, sonst kommen Hinz und Kunz mit unterschiedlichen Strichelungen für verschiedene Wegetypen und in Nullkommanix haben wir osmarender 2.0 ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-legal-talk] seeking understanding of usage of geocoding and POI
he customer inputs address and coordinate on the map > himself by clicking on the map. that would be pure collective DB (we > save nothing from OSM). Unless the map is made from OSM data, of course, in which case you'd again have a derived database. (Rule of thumb: Where would you be without OSM?) > *Q3)* if we were to obscure the starting point for privacy security > reasons and randomly add a few mmm to the coordinate, would we still > need to share the underlying "real point" (might potentially be > answered by Q2 answers if using Nominatim as a start is already a > derivative DB)? You'd always have to share the data that you use publicly. If you add random noise to the data before using it publicly, then the random-noise data is the but you have to share; the fact that there might by myriad purely internal steps that happened before arriving at the data that is used publicly, doesn't matter. > *Q4) *when developing our own tagging, (linked to OSM POI IDs) is > that a _derivative_ because of ODbL 4.4.b (are all tags of POIs a > substantial part of the OSM DB and we look at them prior developing > our own) and 4.6b (any additional content must be shared)? I'm a bit unsure here, suggest you review the "horizontal layers" guideline http://wiki.osmfoundation.org/wiki/License/Community_Guidelines/Horizontal_Map_Layers_-_Guideline Frankly, your further questions sound *so* much like you're looking for a way to share the absolute minimum possible that I'm not comfortable discussing this further. If keeping data proprietary for financial gain is part of your business model, you should really just look into working with proprietary data to start with, rather than trying to create an "OSM++" that you don't have to share - even *if* you find suitable loopholes in the license that make this legal. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [Talk-at] Schulkurse und ähnliche Gelegenheitskurse von Linienbuslinien
Hallo, On 06/09/2016 09:15 AM, Robin Däneke wrote: > Ich werde jetzt beginnen den Linien in Wien pro Kurs opening_hours Tags > zu verpassen. Hab ich ja bei ein paar Linien eh schon gemacht. Somit > wäre es der Konsistenz wegen nur sinnvoll, das bei allen Linien zu > machen . Ich finde das mit den opening_hours keine so gute Idee, aus verschiedenen Gründen: * Es ist eine Zweckentfremdung. Eine Buslinie hat keine Öffnungszeiten, höchstens Betriebszeiten, und welche nimmt man überhaupt dafür? * Es gaukelt eine Präzision vor, die nicht existiert; die opening_hours-Syntax zwingt Dich, Uhrzeiten anzugeben, aber damit kopierst Du bereits Fahrplandaten in OSM und das kannst Du niemals aktuell halten (wer will das bei jedem Fahrplanwechsel prüfen?) * Es ist schwierig auszuwerten. Wenn ich eine Karte zeichne, dann interessiert mich vielleicht die Unterscheidung, ob eine Linie selten, häufig, oder nur nachts befahren wird, aber ich will nicht unbedingt dem Renderer beibringen, wie man opening_hours parst (es *geht* in SQL, aber ...) Wäre es nicht vielleicht eine bessere Idee, analog zum vereinzelt bereits für Nachtbuslinien verwendeten service=night, ein neues Service-Tag einzuführen für solche Gelegenheitskurse? Bei uns gibt es z.B. auch einen Bus, der nur zu Messezeiten fährt und eine Straßenbahn zum Freibad nur im Sommer. Ein Kartenzeichner könnte dann überlegen: Richtet sich seine Karte an Leute, die wissen wollen, wo die ÖPNV-"Verkehrsadern" sind (dann zeichne ich nur die normalen, häufig befahrenen Kurse), oder soll die Karte zeigen, wo grundsätzlich vielleicht irgendwann mal ein Bus vorbeikommt (dann zeichne ich auch die Gelegenheitskurse). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-us] Timezones in USA?
Hi, On 05/26/2016 10:30 PM, Jeffrey Ollie wrote: > In the US, they do put up signs, at least along major roads. In that case it might be a good idea to map the signs themselves, and leave the interpretation (if there's a sign here and a sign there what might this mean for the land in between) to the consumer. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Timezones in USA?
Hi, On 05/26/2016 09:22 PM, L. David Baron wrote: > Perhaps it would make more sense for the timezones to be their own > areas on the map, rather than being represented by tags added to > existing areas? (Most or all of the nodes for such areas should > already exist.) I have deleted a couple of such time zone polygons account of not being verifiable on the ground. I don't know how time zones are defined "at the source" but it is very unlikely that someone puts up signs. I guess there'll be some kind of definition that can be kept *outside* of OSM, and can be translated to polygons with the help of OSM if desired. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Potential data source: New York City watershed recreation lands
Hi, On 05/23/2016 05:35 AM, Kevin Kenny wrote: > One-line summary: I want to import the boundaries of New York City > watershed recreation areas. I've read through your proposal and I would like to know if the boundaries you speak of are observable on the ground. I know there won't be a line or fence on the ground, but will there at least be signs whenever a road or path leads into such an area? If they are not observable then I am strictly against an import. OSM is about mapping things you see (and things others can verify on the ground), not importing data from third sources. We do make exceptions to that rule, especially in cases were an import can provide a building block for future mapper activity - administrative boundaries are such an exception. But that does not mean that any and all boundaries that are somehow "of interest" can or should be imported. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-GB] OSMF looking for a part-time administrative assistant
Hi, the OSMF would like to hire someone for part-time (max 2 days/week) work, helping with administrative tasks. Please see the detailed job posting here on the Wiki: http://wiki.osmfoundation.org/wiki/Administrative_Assistant Since we're an UK organisation, having someone in the UK would probably be useful in many regards although we haven't made that a condition. Needless to say, prior OSM involvement is also a plus. If you are interested, or know someone who is, please apply (or tell them to apply) until June 03, to the address given in the above wiki post. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-de] OSMF sucht bezahlte Kraft für Verwaltungsarbeiten
(Crossposting talk-at und talk-de, bei eventuellen Antworten bitte geeignet anpassen.) Hallo, die OSMF möchte gern eine Person in Teilzeit beschäftigen, die bei allfälligen Verwaltungstätigkeiten und Organisationsaufgaben hilft. Auf Englisch heisst das "admnistrative assistant", im Deutschen denkt man dabei immer gleich an "Sysadmin", das ist aber nicht gemeint - die Person wird mehr mit Menschen zu tun haben als mit Computern. Die Arbeitszeit soll maximal 2 Tage pro Woche betragen; wie genau das Beschäftigungsverhältnis gestaltet wird (Anstellung, freiberuflich, auf Rechnung...) ist dabei durchaus Verhandlungssache. Es würde uns natürlich besonders freuen, wenn wir jemanden fänden, der sowieso schon bei OSM dabei ist oder dem Projekt nahe steht. Also erzählt es weiter ;) Die detaillierte "Job-Beschreibung" ist hier im Wiki: http://wiki.osmfoundation.org/wiki/Administrative_Assistant Bewerbungen werden bis zum 3.6. erbeten. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-at] OSMF sucht bezahlte Kraft für Verwaltungsarbeiten
(Crossposting talk-at und talk-de, bei eventuellen Antworten bitte geeignet anpassen.) Hallo, die OSMF möchte gern eine Person in Teilzeit beschäftigen, die bei allfälligen Verwaltungstätigkeiten und Organisationsaufgaben hilft. Auf Englisch heisst das "admnistrative assistant", im Deutschen denkt man dabei immer gleich an "Sysadmin", das ist aber nicht gemeint - die Person wird mehr mit Menschen zu tun haben als mit Computern. Die Arbeitszeit soll maximal 2 Tage pro Woche betragen; wie genau das Beschäftigungsverhältnis gestaltet wird (Anstellung, freiberuflich, auf Rechnung...) ist dabei durchaus Verhandlungssache. Es würde uns natürlich besonders freuen, wenn wir jemanden fänden, der sowieso schon bei OSM dabei ist oder dem Projekt nahe steht. Also erzählt es weiter ;) Die detaillierte "Job-Beschreibung" ist hier im Wiki: http://wiki.osmfoundation.org/wiki/Administrative_Assistant Bewerbungen werden bis zum 3.6. erbeten. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-us] Missouri: Bulk-importing addresses by county
Hi, On 05/11/2016 09:34 PM, Jacob Hansson wrote: > I started marking street numbers manually a bit today. However, looking > at the edits made to my town (Columbia, MO) every other edit is made by > bots or by people far away participating in various remote mapping > events. This is really sad. Do you think there's maybe a chance to apply your energy to increasing the number of local participants first, before you apply your energy to importing yet another government dataset? With Nominatim already using TIGER data, the added benefit of importing house numbers is small *especially* if there's (as you say) very few people to actually care for stuff once it is imported. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] What3words
Hi, don't know why you warm up this thread after half a year but: On 05/10/2016 07:57 AM, Bryce Nesbitt wrote: > As for the "not open" or "can't depend on it", the company does have a > FAQ topic that's on point: It's not really on point because it only commits them to "maintain the what3words technology" - it still leaves it totally open for them to restrict access, for example to paying customers or people willing to watch an ad or people from a particular IP range or so. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Craigslist
Hi, On 05/08/2016 02:03 AM, Mike Thompson wrote: > Does anyone have a contact at Craigslist [1]? I don't but Dennis Watson @fuzzymeat of Craigslist did a talk at SOTM US 2013 about their map. Unsure if he's still with them though. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] beschränkte Verfügbarkeit OSM-Server voraussichtlich am 9.5.
Hi, auf der talk-Liste wurde gerade angekündigt, dass voraussichtlich am 9.5. der Haupt-Datenbank-Server readonly sein wird. Details hier https://blog.openstreetmap.org/2016/05/02/server-wartungsarbeiten-am-9-mai-geplant/?lang=de Bye Frederik PS Sind hier gestern und heute wirklich keine Postings gekommen, oder ist die Liste nun doch von den Forengnomen sabotiert ;) -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Erstellen eines neuen OSM Stils
Hallo, On 05/01/2016 01:52 PM, nebulon42 wrote: > Bei mir ist der Planet-Import bisher immer fehlgeschlagen > (Linux x64, 12GB RAM, 1TB SSD). Für den Import eines aktuellen Planetfiles braucht man inzwischen mehr als 32 GB RAM, um den Node-Cache im RAM zu halten. Weniger *geht* zwar, ist aber unangehm langsam. Dem OP würde ich empfehlen, mal einen Blick auf den sehr simplen "OSM Bright"-Style zu werfen, der ist für einen Einsteiger leichter zu verstehen als der "große" OSM-Carto. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" signature.asc Description: OpenPGP digital signature ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] osm maps on wikipedia - discussion
Hi, On 04/30/2016 10:41 AM, Martin Koppenhoefer wrote: > Simone, I just wanted to point out that as of 27.1.2016, when you and > Martijn van Exel signed the official agreement, Wikimedia Italy is the > official local chapter of OSMF for Italy. OSMF Italy is a subgroup of > wikimedia Italy. No FUD. The fact that there is an association in Italy promoting both Wikipedia and OSM does not make the statement "We are 100% independent" false. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm maps on wikipedia - discussion
Hi, On 04/28/2016 11:22 PM, Yves wrote: > Concerning borders, Wikipedia could have a different way of dealing with > disputed territories, and OSM way of handling things may or may not be > appropriate. True. A potential "con" for OSM could be that Wikipedia has different standards of how to establish boundaries than OSM, and that Wikipedia users could turn to OSM to "fix" things according to Wikipedia standards. For example, OSM often gets emails saying "the UN have approved this therefore it must be in your data" (or "the UN have not approved this therefore it must not"), but whether or not the UN have approved something is not what governs our mapping. We'd have to explain to Wikipedia users that what they see on our maps might not be what they expect, and that we do *not* want them to fix it... Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Crowdfunding for OpenStreetMap in Bénin : 275km² high resolution satellite imagery for Cotonou by 1-May 2016!
Hi, On 04/28/16 08:55, Greg Morgan wrote: > The problem I have with both Christoph and Frederick statements from > Germany are that the comments have a feeling of not invented here and > more imperialism. The main problem I have with armchair mapping is not "people map an area without going out", it's "people map an area without EVER HAVING BEEN THERE". I'm less concerned about you mapping your extended home region from aerial imagery (assuming for a moment that you live in Montana). If you find something on an image that makes you wonder, you can always make a small detour on your next trip to the supermarket and check it out in person, plus you'll know what kind of builidngs are common in the area and so on. What I think is bad for data quality is people from thousands of miles away "helping" by tracing from aerial imagery without local knowledge. This might work for the most basic of features but it has been shown that even something as seemingly straigforward as the tracing of buildings can go quite wrong if you don't know anything about the culture and the area, and *this* has been branded (accidental) imperialism by some - "what looks like a German barn on the aerial image certainly must be a barn in Ghana too". > Germany is about the size > of Montana USA. Germany has a population of about 89 million people. > Montana has a population of around one million people. The city of Coutonou alone - to come back to the subject - has 800k inhabitants, so a lower bound for the population density in the area being discussed here is 3000 people per square kilometre; about 1000 times as much as Montana and about 10 times as much as Germany. I do realize that People in Coutonou might have other priorities in live than the spoilt kids in Germany but I don't think it serves your argument to invoke population density. > Arm chair > mapping is perfectly good solution in this and many other cases. I dont't think that arm chair mapping is "perfectly good" in many cases, I think the risk of said accidental imperialism is too high. Would you want Montana mapped by people who've never even been to the US and perhaps don't even speak English? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Crowdfunding for OpenStreetMap in Bénin : 275km² high resolution satellite imagery for Cotonou by 1-May 2016!
Hi, On 04/25/2016 07:02 PM, Frederik Ramm wrote: > see for example http://wiki.openstreetmap.org and Gah, broke the link - http://wiki.openstreetmap.org/wiki/WikiProject_Gaza#Commercial_aerial_photography Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Crowdfunding for OpenStreetMap in Bénin : 275km² high resolution satellite imagery for Cotonou by 1-May 2016!
Christoph, On 04/25/2016 06:46 PM, Christoph Hormann wrote: > You are not seriously suggesting that paying a proprietary data vendor > for a likely restrictive license to use some imagery for mapping in OSM > is in support of the idea of open data? I, too, am wary of this initiative because of the underlying idea that working without aerial imagery is a waste of time. IMHO the non-availability of aerial imagery primarily means that there will be less armchair mapping which I consider a good thing (but I know that my position on that is a minority position among humanitarian mappers). Having said that, paying for propietary imagery isn't without precedent in OSM, see for example http://wiki.openstreetmap.org and https://meta.wikimedia.org/wiki/WissensWert/40_-_Luftbilder_f%C3%BCr_OpenStreetMap Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Wahlbezirksgrenzen als boundary/administrative
Hi, On 04/14/2016 12:51 PM, Florian Lohoff wrote: > Irgendwie finde ich das mit dem boundary=administrative ziemlich > unglücklich. Auf der einen Seite ist das natürlich richtig das das > "Administrative" Grenzen sind - aber ich vermute das OSMAnd > jetzt nicht der einzige ist der sich da verwirren lässt. Wenn's nach mir geht, raus mit dem Mist. Verwaltungsgrenzen und PLZ-Gebiete kann ich noch einsehen. Aber Wahlkreise, Grundschuleinzugsgebiete, Kirchengemeindegrenzen, das Sendegebiet vom NDR und das Liefergebiet vom Pizzadienst sind Grenzen, die in OSM nichts zu suchen haben. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgis osm2pgsql issue
Hallo, On 04/06/2016 11:29 PM, Walter Nordmann wrote: > Auch aud dem Download-Server? Von da bekomme ich noch die identischen > Daten. Ja, das sollte sich über Nacht mit der neuen Berechnung dann einrenken. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgis osm2pgsql issue
Hi, On 04/06/2016 10:24 PM, Walter Nordmann wrote: > meines Erachtens ist das Poly falsch: Hm, diese Bayernpolygone, die ich da verwende, sind in der Tat sehr detailliert und haben diverse Änderungen der letzten Jahre verschlafen. Hab sie mal aktualisiert. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] query in postgis osmosis
Hi, On 04/05/2016 08:22 PM, Tobias wrote: > für eine andere Bäckerei: > http://www.openstreetmap.org/way/369696958 > welche Direkt in Landshut liegt bekomme ich mit dem Query: > > SELECT DISTINCT area.osm_id, area.name, area.postal_code > FROM planet_osm_polygon AS area JOIN planet_osm_polygon AS element ON > ST_CONTAINS(area.way, element.way) > WHERE element.osm_id = '369696958' AND (area.postal_code is not null OR > area.boundary = 'administrative') > > folgendes Ergebnis: > -62657;"Landkreis Landshut";"" > -3149176;"";"84030" > -62484;"Landshut";"" > > Die Relationen sollen imo ok sein. Irgendwas ist da doch faul. Die Bäckerei 369696958 liegt in der kreisfreien Stadt Landshut. Der Landkreis Landshut sollte also *nicht* in dieser Liste oben stehen! Die Bäckerei 142034442 aus Deiner anfänglichen Frage hingegen *liegt* im Landkreis Landshut; dort hätte das -62657 also auftauchen müssen. Teste mal dies: osm=# select st_contains(a.way,b.way) from planet_osm_polygon a, planet_osm_polygon b where a.osm_id=-62657 and b.osm_id=369696958; st_contains - f (1 row) osm=# select st_contains(a.way,b.way) from planet_osm_polygon a, planet_osm_polygon b where a.osm_id=-62657 and b.osm_id=142034442; st_contains - t (1 row) So wäre es richtig. Wenn ich auf meiner Datenbank Deine Abfrage für die 369696958 mache, erhalte ich osm_id | name | ?column? --+--+-- -62484 | Landshut | -2145268 | Bayern | -17593 | Niederbayern | -3149176 | | 84030 -51477 | Deutschland | (5 rows) und für die 142034442: osm_id |name| ?column? --++-- -1113363 || 84032 -190875 | Altdorf| -2145268 | Bayern | -62657 | Landkreis Landshut | -17593 | Niederbayern | -51477 | Deutschland| (6 rows) Wenn das bei Dir anders ist, würde ich mir vllt. mal die Polygone mit QGis anschauen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] query in postgis osmosis
Hi, On 04/05/2016 07:53 PM, Tobias wrote: > Das eine ist der Ort das andere das PLZ gebeit soweit so gut. > Die Bäckerei liegt aber auch im Landkreis Landshut: > http://www.openstreetmap.org/relation/62657 > und auch der Landkreis erfüllt die bedinung border=administrative Ist der denn überhaupt drin in Deiner Datenbank? select osm_id from planet_osm_polygon where osm_id=-62657 Falls nein: Vielleicht fehlen Teile der Grenze im Niederbayern-File, und osm2psql hat ihn daher nicht mit importiert... Falls ja: ist denn das Polygon gültig? select st_isvalid(way) from planet_osm_polygon where osm_id=-62657 Mit einem ungültigen Polygon funktionieren u.U. die st_contains-Sachen nicht. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] bicycle=dismount von Routern ignoriert?
Hi, On 04/04/2016 12:02 AM, Florian Lohoff wrote: > IMHO gelte ich wenn ich ein Rad schiebe als Fußgänger. Glaub ich auch - aber wie würden wir dann die physische Unmöglichkeit eines Fahrradtransports mappen, z.B. wenn in einem Zaun so eine komische Klappe ist ---< so dass man als Fussgänger durchpasst, aber als Fahrradfahrer sein Rad knicken müsste? bicycle=carry_overhead vielleicht ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] [OSM-talk] Slack
Hi, On 03/29/2016 07:33 PM, Luis Villa wrote: > +1 to this. OSM should be seeking to broaden the base of potential > mappers, and that means making sure that gateways to the community are > user-friendly - which these days includes good UX/onboarding experience > and mobile apps. Slack is a clear winner there. As a side note, this is also something commonly debated by the OSMF board and the OSMF members - wheter or not, and in how far, non-free tools are valid to use for a project like OSM and a foundation like the OSMF. Example of a recent discussion: https://lists.openstreetmap.org/pipermail/osmf-talk/2015-December/003639.html The spectrum of available services for a specific task usually ranges from "Non-free software offered as a service" (with and without silo, with and without payment) over "free software offered as a serivce" to "free software you run yourselves". The paid-for solutions will usually mean less work for the few admins at OSMF (who have enough work with keeping the essentials running), plus they're usually shinier. The self-hosted stuff is often less shiny but more in keeping with the free-and-open spirit. Personally I'm often on the fence as well. I'd love there to be an "internal IT services working group" whom we could task with setting up email, bug trackers, wikis, mumble servers, and voting platforms as needed but there's no such group and not enough capacity in OWG to shoulder that too. I think that OSM owes its success partly to all those who were happy to use it when it was still much less usable than it is today; had everyone gone to Google because the had the slickest interface, then OSM wouldn't be where it is today. On the other hand, working groups or the board tend to have a mission and while some detours for using free-and-open are acceptable, there's a limit to just how much productivity loss you can accept for going with the less shiny. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] [Talk-us] Slack
Hi, On 03/29/2016 07:33 PM, Luis Villa wrote: > +1 to this. OSM should be seeking to broaden the base of potential > mappers, and that means making sure that gateways to the community are > user-friendly - which these days includes good UX/onboarding experience > and mobile apps. Slack is a clear winner there. As a side note, this is also something commonly debated by the OSMF board and the OSMF members - wheter or not, and in how far, non-free tools are valid to use for a project like OSM and a foundation like the OSMF. Example of a recent discussion: https://lists.openstreetmap.org/pipermail/osmf-talk/2015-December/003639.html The spectrum of available services for a specific task usually ranges from "Non-free software offered as a service" (with and without silo, with and without payment) over "free software offered as a serivce" to "free software you run yourselves". The paid-for solutions will usually mean less work for the few admins at OSMF (who have enough work with keeping the essentials running), plus they're usually shinier. The self-hosted stuff is often less shiny but more in keeping with the free-and-open spirit. Personally I'm often on the fence as well. I'd love there to be an "internal IT services working group" whom we could task with setting up email, bug trackers, wikis, mumble servers, and voting platforms as needed but there's no such group and not enough capacity in OWG to shoulder that too. I think that OSM owes its success partly to all those who were happy to use it when it was still much less usable than it is today; had everyone gone to Google because the had the slickest interface, then OSM wouldn't be where it is today. On the other hand, working groups or the board tend to have a mission and while some detours for using free-and-open are acceptable, there's a limit to just how much productivity loss you can accept for going with the less shiny. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Slack
Hi, On 03/27/2016 12:26 AM, Dave F wrote: > Yeay! Another communication forum. Just what OSM needs. Have we even completed our implementation of UserVoice yet, before we start with other big new stuff. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Caliparks re-tagging paths?
Hi, On 03/25/2016 11:36 PM, Greg Troxel wrote: > There seems to be some wiki-agitation going on about a "proposed tag" of > social path. Perhaps everyone who is opposed might want to look and > register opposition, unless they are more opposed to wikifiddling than > to this tag :-) I wouldn't call it wiki-agitiation; anyone is welcome to propose something on the wiki - if this were done at the outset then we could have avoided all this brouhaha. Personally I don't quite understand the concept of a "social path". A path is a path is a path; if two paths look the same then we'll tag them both as e.g. highway=track or highway=footway or whatever is appropriate. If one of them is official and the other not, or if one of them is allowed to use and the other not, that can be shown through extra tags like access=* or operator=* or whatnot. I'm not sure what the legal status of a "social path" is, either. What does "this path is considered unauthorized" mean? Does it mean "we'll have police escort you elsewhere if we see you here", or does it just mean "you can't sue us if you trip and break your leg here"? In England there are situations where a public right of way goes through someone's garden. I'm sure the owner of the garden would love to somehow hide the way from the map... but do we? IMHO the contents of the highway tag would normally be something that can be determined from aerial imagery, without consulting the managing authority. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Caliparks re-tagging paths?
Hi, On 03/24/2016 11:26 AM, Marc Gemis wrote: > They tagged them as "social_path", according to their blog entry [1] Thank you for the link. This is what I feared. highway=social_path is certainly unacceptable - a self-made tag that essentially deletes the data for all other consumers. There would have been numerous other options that would have allowed them to single out the tracks they want - for example, tagging the official ones with an "operator" tag, or putting them into suitable relations or so. Had any of the players involved taken the time to ask on this list, I'm sure these options would have been pointed out to them. As it stands, removing a proper, established highway tag and replacing it with something that nobody knows is just a little bit better than removing the way altogether. To make matters worse, it seems that the issue has been pointed out almost half a year ago, and has not led to the issue being fixed: http://www.openstreetmap.org/changeset/34599982 It is obvious to me that all occurrences of highway=social_path need to be replaced with whatever they were before. I'd normally say let's give them some time to come up with a better idea but seeing that the problem has been highlighted to them pretty much at the time they made the edits 5 months ago, and they haven't come up with a better idea, I'd say the time is up now. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Caliparks re-tagging paths?
Hi, I find this article a bit worrying: http://www.citylab.com/cityfixer/2016/03/caliparks-app-safer-hiking-trails-california/475047/ It is about an app that displays tracks in California public parks based on OSM. When officials were unhappy about unoffical paths being displayed, "Park managers have tried to delete these trails from OpenStreetMap, but they often pop back up", (I sure hope they pop back up, and if I catch any park managers deleting existing paths I'd have a word with them), and then "developers at Stamen, GreenInfo Network, and Trailhead Labs essentially “muted” the data that identifies the errant trails by tagging them with a code from differentiates them from authorized paths." I would be interested to find out how this "muting" happened and if it has any adverse effects on other data consumers. There's certainly good and bad ways to do it, but I don't remember anything having been discussed with the community. Could someone from one of the groups participating in this commercial editing enlighten us about what exactly is being done, which tags are changed/used, etc? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] Redaction or revertion?
Hi, On 03/23/2016 08:19 AM, maning sambale wrote: > I'm aware that redaction is only for DWG dedicated accounts. What's > the best practice/criteria for redaction? Edits that are *reverted* will stop showing on everything that is based on the current version of our data (map, search, routing, editors etc) and they will also not be findable with search engines. But they can still be retrieved through (a) requesting the object history from the API, (b) downloading a (current) full history planet file, (c) downloading an older planet snapshot or planet history file, (d) requesting the history from downstream services that store it (I believe Overpass is such a service). Edits that are *redacted* (note: only non-current versions of an object can be redacted) will be suppressed by the API and hence vanish from the methods (a) and (b) mentioned above; they will still be accessible by the methods (c) and (d) because we don't retroactively change old planet files that might have contained a problematic edit. We will usually consider redaction if someone has uploaded content that should remain secret (eg the location of a shelter for victims of domestic abuse), is grossly offensive, or constitutes a large and obvious violation of someone else's copyright. On minor copyright violations (user uploads 10 houses with source=Google, we tell him that's not allowed, he says sorry and deletes the houses again) we usually don't bother with a redaction, although if the copyright holder were to complain we would have to execute one. (If a copyright holder were to really really complain we'd even have to remove old planet files and old history planets that contain the problematic data from our servers but this hasn't happened yet.[*]) Redactions are more of a last resort and not a routine tool; they make working with the data more difficult hence we try to avoid them when not necessary. Bye Frederik [*] There was one incident long, long ago where several old planet files were re-written to leave out a large amount of data for a Baltic country that had been illegaly imported. -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM plugin to import GeoJSON?
Hi, On 03/20/2016 10:56 PM, Stefan Keller wrote: > But Shapefile remains an oldtimer with more drawbacks than limited > field names; see [1]. > GeoJSON (ascii) and GeoPackages (binary) are formats which are more > suited for the job. > I still have hope that JOSM will be able to read those vector formats too. Frankly, whenever I venture into the brave new world of Spatialite, I come back to good old shape files after a while for performance reasons. I'm not sure if Geopackage has significant performance improvements over simple Spatialite but if it hasn't then my recommendation for simple GIS processing is certainly to stick with shape files for the time being - despite all their shortcomings. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] [UK Chapter] Definition of OSM.
Hi, On 03/20/2016 06:36 PM, Gregory wrote: > Included in the meeting on Thursday[1] was discussion on the definition > of "OpenStreetMap" in the AoA. It might be interesting to consider - unless you've done that already - that the OSMF itself is *not* limited to supporting OpenStreetMap; in fact OpenStreetMap (as a project) appears nowhere in the OSMF AoA. Instead, the OSMF is established for (1) encouraging the growth, development and distribution of free geospatial data; and (2) providing geospatial data for anybody to use and share. Likewise, the boilerplate local chapter agreement only binds the parties to (seek to) "mutually support the activities of the other". So theoretically, if the OSMF should decide that the newly founded LibreStreetMap project is worthier of support than OSM is, the OSMF *could* support LibreStreetMap instead of (or in addition to) OSM, and the local chapter would be expected to "mutually support" this activity. This is all very hypothetical terrain of course but if you wanted to keep the LC in sync with OSMF lingo then you'd have to speak of general "free geospatial data" too, and not not specifically of OSM. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-de] Wochennotiz Nr. 294 1.3.2016–7.3.2016
Hi, On 03/10/2016 10:32 PM, Wochennotizteam wrote: > die Wochennotiz Nr. 294 mit vielen wichtigen Neuigkeiten aus der > OpenStreetMap Welt ist da: Habt ihr als Folge der Diskussion auf talk-at jetzt aufgehört, uns hier auf talk-de immer zu informieren, oder war das nur ein Lapsus, dass ihr http://blog.openstreetmap.de/blog/2016/03/wochennotiz-nr-295/ nicht angekündigt habt? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] mapRe: (Second attempt) Potential data source: Adirondack Park Freshwater Wetlands
Kevin,
On 03/15/2016 03:46 AM, Kevin Kenny wrote:
> Since I received only a total of three comments about this idea, one
> strongly negative (from Frederik Ramm)
My comment was intended to open your eyes to the fact that there's more
to a good import than simply putting precise data into OSM and getting
the tags right.
Frankly I felt that you had already laid out the negative bits in your
original message and you didn't need me to write a negative comments,
you just needed me to draw the logical conclusion from what you yourself
wrote ;)
I have zero knowledge about the Adirondack; I just echoed your own
words: You said that there are "difficulties inherent in getting changes
made by local mappers working independently", and I said if that's the
case then the import is not likely to be useful for a long time as it
will just "echo" third party data.
Brian May in his encouraging message talks about laying "the groundwork
for others to build on" and says "You will also no doubt spark interest
from more active contributors who will notice that there's major quality
improvements in your area and pitch in to help - potentially a lot."
While Brian seems to disagree with my "one strong negative comment", he
also seems to disagree with your very own judgement that it is very
unlikely that the data is going to be edited and improved; he seems to
believe that the import can be a viable foundation for original
surveying by volunteers in the Adirondack. I don't know if that's just
wishful thinking or if he has first-hand experience of the area that
goes against yours.
Like me, Brian sees an import not as a replacement for mapper activity
("nobody's going to go there anyway so let's take someone else's data")
but as a foundation ("let's import this data so others can build upon it").
I can't judge how likely it is that others will build upon it but I'd
say that if, five years down the line, nobody has built upon it while
official data has been improved time and again, then it's probably a
waste of time. We would only know with hindsight. (For the TIGER import,
which covers ground much more accessible than the Adirondack, the "five
years down the line and nobody has done anything while official data has
improved" is, sadly, true in many areas.)
If it is any consolation, I have rarely seen a so well reflected and
carefully laid out import proposal as yours. But as I said, I believe
that your proposal essentially answered the question "should this import
go ahead" all by itself.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-de] Datenerfassung für stadtverträgliches LKW-Routing im Rheinland
Hi,
On 03/13/2016 01:11 PM, uwe_sennew...@hotmail.com wrote:
>>> Wenn man sich beim Verkehrsverbund Rhein-Sieg Gedanken über
>>> LKW-Navigation macht und dies hier veröffentlicht gibt es einen
>>> Aufschrei, wenn ein Mapper im OSM-Forum um Mithilfe beim Erfassen von
>>> Durchfahrtshöhen von Brücken für sein LKW-Navigationsprojekt bittet
>>> schwärmen Deutschland weit Mapper wie die fleißigen Bienchen aus.
>> Das ist kein Widerspruch, und wenn Du hier einen siehst, dann scheint
>> mir, dass Du etwas sehr wichtiges nicht verstanden hast.
> Was soll ich nicht verstanden haben ?
Das es etwas Grundverschiedenes ist, ob Dinge beobachtbar sind (und
daher auch Mapper ausschwärmen können, um das zu kartieren), oder ob
etwas nur als Wunschvorstellung auf dem Papier existiert ("bitte keine
LKW am Haus des Bürgermeisters vorbeischicken, wir können das zwar nicht
verbieten, aber irgendwie vermeiden wollen wir's schon") und von einem
Amtsmitarbeiter in OSM eingepflegt wird.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenerfassung für stadtverträgliches LKW-Routing im Rheinland
Hi, On 03/11/2016 01:24 PM, uwe_sennew...@hotmail.com wrote: > Wenn man sich beim Verkehrsverbund Rhein-Sieg Gedanken über > LKW-Navigation macht und dies hier veröffentlicht gibt es einen > Aufschrei, wenn ein Mapper im OSM-Forum um Mithilfe beim Erfassen von > Durchfahrtshöhen von Brücken für sein LKW-Navigationsprojekt bittet > schwärmen Deutschland weit Mapper wie die fleißigen Bienchen aus. Das ist kein Widerspruch, und wenn Du hier einen siehst, dann scheint mir, dass Du etwas sehr wichtiges nicht verstanden hast. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenerfassung für stadtverträgliches LKW-Routing im Rheinland
Hallo, On 03/10/2016 03:23 PM, Michael Paulmann wrote: > Sorry aber welche rein kommunalen Daten haben wir in OSM die nicht in der > Wirklichkeit prüfbar sind? Es gab da mal eine lange Diskussion über nicht-beschilderte, aber "offizielle" Radrouten in den USA, und ich meine, die sind am Ende drin geblieben. Hier bei uns haben wir natürlich PLZ- und Verwaltungsgrenzen in der Datenbank, die ebenfalls nicht vor Ort verifizierbar sind, aber das ist eine große Ausnahme, die wir vorallem deswegen machen, weil die Daten für uns selbst in unserer Arbeit hilfreich sind (so kann man z.B. Auswertungen für das Gebiet einer Gemeinde machen und so weiter). Ich glaube nicht, dass wir Dinge wie Schulbezirke oder Liefergebiete von Pizzadiensten mappen würden. Auch der Verlauf von ÖPNV-Bus-Routen ist nur schwer beobachtbar und unter Umständen nicht mal fix - besonders bei den Fernbussen gehe ich davon aus, dass bei denen eigentlich nur die Stationen und nicht die Routen feststehen. Dennoch werden die zuweilen eingetragen. Aber, wie immer in OSM gilt: Nur, weil irgendwas anderes schlecht gemacht wird, ist das noch keine Ausrede, weitere Dinge auch schlecht zu machen ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenerfassung für stadtverträgliches LKW-Routing im Rheinland
Hallo, On 03/10/2016 12:18 PM, Michael Paulmann wrote: >> · Wenn möglich sollten Daten, wie die LKW-Vorrangrouten, >> die nur von den Kommunen bestimmt werden können, möglichst nicht >> von Jedem geändert werden können. Ich weiß, dass das dem Naturell >> der OSM wiederspricht, aber es wäre für eine zuverlässige >> LKW-Navigation wichtig, dass das Vorrangroutennetz dauerhaft >> verfügbar ist. > Das geht in OSM nicht und wird auch nie gehen. Ich würde vorschlagen > das Projekt auf einem seperaten Server zu fahren und osm als > Hintergrund zu verwenden. Stimmt, und zwar aus zweierlei Gründen: 1. In OSM kommt rein, was vor Ort verifizierbar ist. Wenn die Kommunen Schilder aufstellt, die die LKW-Vorrangrouten kennzeichnen, dann können die in OSM gemappt werden, sonst nicht. (Es gibt ein paar Ausnahmesachen, die wir mappen, obwohl sie nicht beobachtbar sind, aber das sind sehr wenige). 2. Was in OSM drin ist, darf von jedem geändert werden. - Natürlich könnte eine Kommune beobachten, ob etwas an ihren Daten geändert wird (da existieren sogar gewerbliche Dienstleistungen), und geeignet reagieren, aber selbst dann würde man erwarten, dass Änderungen Dritter nicht blind revertiert werden. Die Lösung heisst hier ganz klar: Vorrangrouten in eigenem GIS abspeichern und dann, im Rahmen der Graphen-Aufbereitung für das Routing, in den Routinggraphen mit einfliessen lassen. Dann wird OSM nicht mit unverifizierbaren Daten belastet, und niemand kann "dazwischenfunken". Das "eigene GIS", in dem die Vorrangrouten gespeichert werden, könnte durchaus mit OSM-Technik aufgebaut werden, wenn man das wünscht, aber natürlich geht auch sowas wie QGIS oder ähnliches. Es gibt auch Alternativen wie das "Separate Data Store"-Plugin für JOSM, bei dem man an OSM-Objekte direkt im OSM-Editor Zusatzattribute anhängen kann, die dann aber nicht bei OSM, sondern in einer separaten Datenbank abgespeichert werden. Dieses Vorgehen hat aber den Nachteil, dass bei einer Änderung der IDs auf OSM-Seite (z.B. Aufteilung oder Zusammenführung von Wegen) Informationen verloren gehen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Mapathon In Sweden, Göteborg
Hi, On 03/09/2016 11:46 AM, Daiva Marija Brazauskaitė wrote: > my name is Daiva Brazauskaite, and I am working with student association > called SKIP at University of Gothenburg (Göteborgs Universitet) in > Sweden. Letting you know that we are planning to make a Mapathon on 29th > of March. We are inviting students and people interested in learning > mapping and using OpenStreetMap platform. A very important pillar of OpenStreetMap is encouraging people to add their first-hand knowledge to the world-wide pool. Some of the people attending may come from remote places in the world where OSM lacks detail, and they will be able to add interesting detail from memory, perhaps aided by aerial imagery. But even those local to Göteborg could contribute to OSM much closer to home - it seems to me that while central Göteborg is well mapped, many smaller towns and villages around it could benefit from someone adding detail like house numbers or POIs. I know that many find the thought that they could help someone by tracing data from aerial imagery appealing, even if they have no personal relation to the area they see before them. But sometimes grabbing a notepad and going somewhere - even if it's only a tram ride away - to actually survey can also be a very fulfilling activity. > We are going to choose one of > the projects from HOT Tasking Manager lists and use OSM iD editor. If you do limit your mapping to that, it would be great if you could mention to attendees that what you're teaching them is just one of many way to contribute to OSM, and especially that tracing from aerial imagery in foreign countries is the exception, not the norm, in OSM. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-us] Relations and boundaries
Hi, On 03/03/2016 08:02 PM, Steve Friedl wrote: > Ive been updating all the cities in Orange County California to have fully > segmented relationalized boundaries, such that cities sharing a common > border share a single way in each of their relations; this eliminates > overlapping ways. Its been very tedious but it's really getting cleaned > up. \o/ > First: The individual relations city, county, national forest, etc. all > have full information tags about the entity, but how should the way members > themselves be tagged? It is not necessary but may add clarity for people editing the data. Generally it is recommended to tag boundary=administrative, admin_level=, and no names (no county:left, county:right stuff etc either). > Within Westminster is a "donut hole" , and the Westminster relation has it > as a role=inner. > > Question: should that same donut hole be tagged role=outer in the Orange > County relation? Yes, that's what I would suggest. It would be nice if our tools allowed you to simply make the Westminster *relation* an "inner" of Orange county and thereby automatically do the donut justice but that's not supported by anything really. > It just doesn't feel right to have a role=outer fully within another > role=outer, but that's the only way I can think of to handle this. Rest assured, when you hear Mathematicians talking about geometry, they will happily accept that an outer ring can be surrounded by an inner ring. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [OSM-talk] OsmAnd financially rewarding mappers
Hi, On 03/03/2016 06:11 PM, joost schouppe wrote: > I am surprised to see so few negative reactions. Nothing against the > idea, but it should be better thought out to avoid perverse incentives. I have no problem with this. If this leads mappers to do stupid edits, DWG will have to revert them all... with an account registered for rewards of course ;) Bye Frederik PS pls to be activatink irony detektor -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSRM-talk] osrm-extract taking hours to complete
Hi, On 03/02/2016 09:03 PM, Bjorn Madsen wrote: > I added a high speed SSD and pointed the .stxxl towards that to deal > with the swap slowdown. That bought me a drop in processing time from 12 > hrs -> 3-4 hrs. > > osrm@mat4:~/osrm-backend$ cat .stxxl > *disk=/mnt/tmp/stxxl,40,syscall* Since we're discussing this, I always wondered why I got STXXL messages even when running on a 256 GB RAM machine (could it not simply do everything in RAM there). Then tried to have the STXXL file on a ramdisk but failed because the Linux "tmpfs" doesn't support some IOCTL operation or so that STXXL wants to use. I ended up creating a sparse 200 GB file on the ram disk and loopback-mounting that to put an ext4 file system on it, just to enable STXXL to put its swap file there. Surely better approaches exist? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ OSRM-talk mailing list OSRM-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/osrm-talk
Re: [Talk-us] [Imports-us] Virginia Beach, Virginia Imports
Hi,
On 03/02/2016 02:55 AM, Jonah Adkins wrote:
> I'd like to propose an import of city-sourced GIS data for the City of
> Virginia Beach, Va. The City GIS Office has given the data / license for this
> purpose.
> Conflation will be done carefully by hand, and attributes copied where needed.
You live an hour away from Virginia Beach, is that correct? Are you
familiar enough with the city to verify the data quality, or will you
enlist the help of local mappers who are?
To quote stevea from teh recent Adirondack thread,
> Likewise. We (OSM volunteers) don't often talk about the importance
> of KEEPING UP the map after an import, but doing so is a seriously
> crucial component.
Is there a community that can be counted on to make sure the data
doesn't rot in OSM once imported - or will you commit to that?
On http://paidmappers.github.io/home/, you advertise your services as
mapper-for-hire ("Open Data is growing at an alarming rate and we shall
put all that data in OpenStreetMap. ... we scour open data portals and
sites for authorative data like buildings, public amenities, and
addresses.") - Is this import proposal linked to this endeavour in any way?
(I haven't looked at the data and license yet.)
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-de] Lizenz für Programme und Code
Hi, On 03/01/2016 10:59 AM, Markus wrote: > Gefunden habe ich: > GPL-2: JOSM, OSM-Website, Mkgmap, Mediawiki > GPL-3: Membrane Viele haben auch "GPL v2 or higher", d.h. eine Upgrademöglichkeit. Ein Beispiel für die Nr 1 "ganz frei" ist noch die mir sehr sympathische WTFPL. > AGPL: OSRM war mal AGPL, doch als es dann von Mapbox gesponsort wurde, gab es eine Rundfrage an alle, die bisher mit entwickelt hatten, ob ein Umstieg auf BSD akzeptabel ist, und dann wurde das geändert. Heute ist z.B. noch der Router "routino" unter AGPL. > LGPL: > MIT: Lua, Debian > 2-BSD: OpenLayers > 3-BSD: Osmium verwendet die "Boost Software License", die der MIT- und BSD-Lizenz sehr ähnlich ist. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-us] (Second attempt) Potential data source: Adirondack Park Freshwater Wetlands
Kenny, On 02/27/2016 06:10 AM, Kevin Kenny wrote: > Given the > difficulties inherent in getting changes made by local mappers working > independently (the data are a bit difficult to verify in the field), > it's arguable that we should always use third-party sources to make > our maps and have it be Someone Else's Problem. That said, we > unquestionably do have hydrography in OSM, and it doesn't in fact > require a lot of updating - these natural features are quite stable, > particularly in a remote area such as I'm considering here. Is there not the danger though of the data rotting away in OSM, precisely for the reasons you outline - difficult to map in the first place, Adirondack being huge, and all this being a too big project for one or even a handful persons? IMHO you'd be scratching an itch for now and making it easier for people to make maps with OSM, but a few years down the line, people will again have to turn to the (regularly updated, presumably?) government data and say, just like you said, that OSM is "among the poorest of what I have available"? An import is great if it enables a community to go further, or forms the basis of solid work in the future. An import is great if it is one ingredient that makes OSM the best map of the region. But it sounds to me as if your proposed import is hardly more than a small time saver for people who want to make maps of the Adirondack - they *could* go to the original source at any time, and the likelihood of OSM hydrography being *better* than the official data is very low. In my view, a good import is a catalyst for future OSM data improvement. But you seem to say quite clearly that such is unlikely to happen with the data you are planning to import. Your main point is that it'll look better on the map, which for me isn't good enough. Can you point to areas where your import would encourage mappers, including yourself, to add more knowledge and surveyed data to OSM? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-at] OSM-Sonntag auf der FOSSGIS-Konferenz in Salzburg
Hallo,
ich schreibe hier an talk-at und talk-de gleichzeitig, wer nur auf
einer der Listen ist und antworten möchte, möge die To:-Zeile
entsrechend anpassen.
Wie ihr aus den zahlreichen Aufrufen zur Vortragseinreichung wisst, ist
die FOSSGIS dieses Jahr unmittelbar vor der AGIT, in den gleichen
Räumen, in Salzburg. Offiziell geht die FOSSGIS von Montag (4.7.) bis
Mittwoch (6.7.).
Was allerdings noch nicht an die große Glocke gehängt wurde, ist, dass
wir für den Sonntag davor (3.7.) ebenfalls Räume reserviert haben.
Inoffiziell wird es also bereits am Samstag abend losgehen mit einem
Essen oder Kneipenbesuch für die OSMler. Für den Sonntag sind noch keine
konkreten Pläne gemacht, ausser, dass es ein "OSM-Sonntag" sein soll,
der sich weniger an Außenstehende richtet sondern mehr an die
OSM-Community selbst. Vielleicht ein bisschen sowas wie der
Workshop-Sonntag, der nach der SOTM-EU in Karlsruhe stattgefunden hat
(der war sehr entwickler-lastig), oder auch etwas mehr über das Mapping,
Importe, Qualitätskontrolle, was weiss ich.
Am kommenden FOSSGIS-Wochenende in Essen
(https://www.fossgis.de/wiki/FOSSGIS_Hacking_Event_2016_Nummer_5) ist
vielleicht Gelegenheit, über die Planung dieses OSM-Sonntags zu
sprechen. Ich würde gern jede/n, der interessiert ist, einladen
* in Essen dabeizusein oder
* Ideen vorher auf dieser Liste zu diskutieren (oder mir zu mailen)
* seine/ihre Salzburg-Pläne so zu gestalten, dass er/sie bereits am
Sonntag dabei sein kann.
Auch für Leute, die unter der Woche wegen der Arbeit keine Zeit haben,
wird sich der Sonntag in Salzburg bestimmt lohnen, wenn dem jetzt nicht
gerade eine zehnstündige Anreise entgegensteht ;)
Bye
Frederik ("nur" 6 Stunden Anreise - immerhin schneller als Dessau)
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at
[Talk-de] OSM-Sonntag auf der FOSSGIS-Konferenz in Salzburg
Hallo,
ich schreibe hier an talk-at und talk-de gleichzeitig, wer nur auf
einer der Listen ist und antworten möchte, möge die To:-Zeile
entsrechend anpassen.
Wie ihr aus den zahlreichen Aufrufen zur Vortragseinreichung wisst, ist
die FOSSGIS dieses Jahr unmittelbar vor der AGIT, in den gleichen
Räumen, in Salzburg. Offiziell geht die FOSSGIS von Montag (4.7.) bis
Mittwoch (6.7.).
Was allerdings noch nicht an die große Glocke gehängt wurde, ist, dass
wir für den Sonntag davor (3.7.) ebenfalls Räume reserviert haben.
Inoffiziell wird es also bereits am Samstag abend losgehen mit einem
Essen oder Kneipenbesuch für die OSMler. Für den Sonntag sind noch keine
konkreten Pläne gemacht, ausser, dass es ein "OSM-Sonntag" sein soll,
der sich weniger an Außenstehende richtet sondern mehr an die
OSM-Community selbst. Vielleicht ein bisschen sowas wie der
Workshop-Sonntag, der nach der SOTM-EU in Karlsruhe stattgefunden hat
(der war sehr entwickler-lastig), oder auch etwas mehr über das Mapping,
Importe, Qualitätskontrolle, was weiss ich.
Am kommenden FOSSGIS-Wochenende in Essen
(https://www.fossgis.de/wiki/FOSSGIS_Hacking_Event_2016_Nummer_5) ist
vielleicht Gelegenheit, über die Planung dieses OSM-Sonntags zu
sprechen. Ich würde gern jede/n, der interessiert ist, einladen
* in Essen dabeizusein oder
* Ideen vorher auf dieser Liste zu diskutieren (oder mir zu mailen)
* seine/ihre Salzburg-Pläne so zu gestalten, dass er/sie bereits am
Sonntag dabei sein kann.
Auch für Leute, die unter der Woche wegen der Arbeit keine Zeit haben,
wird sich der Sonntag in Salzburg bestimmt lohnen, wenn dem jetzt nicht
gerade eine zehnstündige Anreise entgegensteht ;)
Bye
Frederik ("nur" 6 Stunden Anreise - immerhin schneller als Dessau)
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Leerungszeiten von Briefkästen auf deutschepost.de
Hi, On 02/20/2016 03:14 PM, mmd wrote: > Mit dieser Frage hatte ich mich vor einem Jahr am Rande beschäftigt, > u.a. weil die minutely diffs nichts von einer Redaction mitbekommen und > bestimmte Daten weiterhin in der Overpass API auftauchen. Allerdings gilt das nur für mirrors, die historische Daten halten; tatsächlich wird eine redaction nicht im Diff publiziert. Mirrors, die aktuelle Daten halten, haben kein Problem, da die aktuelle Version eines Objekts nie "redacted" werden kann. > Damals gab es jedenfalls noch keinen Service, der das "Schwärzen" der > Daten nach außen nachvollziehbar macht. Gibt es heute auch nicht. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Leerungszeiten von Briefkästen auf deutschepost.de
Hi, On 02/20/2016 01:56 PM, Martin Koppenhoefer wrote: > ok, wundert mich halt nur ein bisschen, weil wir bisher immer die > weisser als weiss Haltung kommuniziert haben in Sachen Copyright und > Lizenzen, und jetzt aber den Aufwand bzw. die damit verbundenen > Unannehmlichkeiten scheuen, durch Copyright bzw. Datenbankrecht > geschützte Daten wieder endgültig aus der db zu entfernen, obwohl wir > sie entdeckt haben? Unsere aktuellen Daten sind "weisser als weiss". Wer in der History herumstöbert, kann da unter Umständen auch mal auf etwas treffen, was problematisch ist. Aber fast alle Anwendungen der OSM-History sind interner Natur, "Debug-Zwecke" sozusagen. > Wie unterscheiden sich "minder schwere" Copyrightverletzungen von > schweren, ist das eine quantitative Frage oder geht es mehr darum, > unter welcher Lizenz die Daten stehen? Oder wie hoch das Risiko/der > Schaden für die OSMF ist, wenn jemand klagt? Äh, das wird im Einzelfall entschieden ;) Ich würde sagen, wenn Rechteinhaber zu uns sagt: Macht das bitte raus, auch aus der History, dann tun wir das auch. Wenn es uns aber eher unwahrscheinlich scheint, dass sich überhaupt irgendjemand darüber aufregt, dass problematische Daten noch in der History sind, dann lassen wir es vielleicht eher mal drauf ankommen (der Rechteinhaber kann sich ja immer noch beschweren und dann machen wir eine "redaction"). Die "Wahrscheinlichkeit, dass sich der Rechteinhaber beschwert" korreliert vermutlich mit allem, was Du oben schreibst: Wenn es besonders viele oder besonders wertvolle Daten sind, ist die Wahrscheinlichkeit höher; wenn der Rechteinhaber die Daten selbst unter CC-BY-SA gestellt hat, ist die Wahrscheinlichkeit geringer als wenn sie "alle Rechte vorbehalten" sind, und so weiter. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
