Re: [OSM-talk] replace some obviously mistaken surface values by their clear intended meaning
On 11.02.23 18:41 Mateusz Konieczny wrote: I propose to replace following surface tags by doing an automated edit I wholeheartedly support this proposal, thank you for your work! ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)
On 29.11.22 16:38 Dave F wrote: If it's a licence change by OSM then how can a maintainer of a database possibly account for a future, unspecified change who's implementation was out of their control? Yes, it's about a license change by OSM. I don't think it's outlandish to assume that at least some data donors are comfortable with such terms. After all, this is something that we expect of individual contributors: The Contributor Terms which every person with an OSM account has signed grants us (meaning the OSMF board and a 2/3 majority of active contributors) the right to switch to any unspecified open license in the future. Could you expand on what you mean by 'legal text'. Is it a legally binding contract? Answering by way of example: I would expect a similar implementation to the standard waiver we ask for before we import CC-BY data: https://drive.google.com/file/d/0B3PN5zfbzThqeTdWR1l3SzJVcTg/view?resourcekey=0-PzVtHArfxvbYidpW2-AVTg ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)
On 29.11.22 08:14 Simon Poole wrote: The main question is what "expect it to survive a hypothetical license change" implies. My expectation is that because of practical considerations any future licence would require downstream attribution of OSM so that the OSMF can continue to offer third party sources indirect attribution. You have a point that it seems practical to look just at the more narrow scenario of another license that requires attribution of OSM. After all, a license change is not a high-probability event in the first place, and a change to a license that doesn't require some form of attribution seems even more unlikely. So it would be useful to be able to record something like "as long as attribution is ensured" for an import's license change compatibility. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)
On 29.11.22 03:57 Minh Nguyen wrote: Could you clarify the "perhaps" here? If something has been explicitly dedicated to the public domain via CC0, a similar statement, or a relevant law, should it not survive any relicensing attempt? Or is this just about the editorial decision of whether to leave the table cell blank if relicensing is irrelevant for a given import? This is about dealing with some issues of importing share-alike datasets. There is no intention to change the way we interact with public domain datasets which already leave us ample flexibility for importing and redistributing them. The "perhaps" was indeed just alluding to an editorial decision regarding the wiki table. Sorry for the confusion. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)
On 28.11.22 at Simon Poole wrote: What is "OSM Contributor Terms compatibility" supposed to be? Ok, this is clearly imprecise wording.¹ The context is that we would like to offer data donors a standard legal text that they can use to make their data available to OSM in such a way that we would expect it to survive a hypothetical license change. And yes, this would perhaps look similar to a CC0 waiver, except that it could potentially be a bit more limited (in a similar way the CT limits the set of licenses under which the OSMF can choose to publish the database). So the column would be mostly about whether this legal text or something equivalent has been signed or not (+ perhaps public domain/CC0 data that has the ability to survive a license change by default could also check the box). Tobias ¹ The wording is my fault and, iirc, was inspired by the column name at https://wiki.osm.org/Import/ODbL_Compatibility ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] RFC: Two new extensions for the wiki: Log in via openstreetmap.org and vote via a GUI
On 13.10.22 11:47 Martin Fischer wrote: I wrote two small MediaWiki extensions for wiki.openstreetmap.org: one to let you log in via your OSM account and one to provide an easy to use in-wiki GUI for proposal voting. Awesome work, I like both of these and hope they make it onto the OSM wiki! :) Of course, this gets me thinking again about unifying OSM and wiki accounts and how we could get closer to that goal by disabling "regular" account creation on the wiki after your extension is installed. But I like that installing it immediately offers tangible benefits regardless of any such extra steps. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] Kandidatur für den OSMF-Vorstand
Hallo zusammen, morgen beginnen die diesjährigen Vorstandswahlen¹ der OSM Foundation, und wie einige von euch schon wissen, habe mich entschieden, noch einmal anzutreten. Ich bin ja jetzt seit zwei Jahren Vorstandsmitglied. Nicht alle Ideen, die ich bei meiner letzten Wahl hatte, waren im Vorstand mehrheitsfähig, aber einiges konnte ich doch umsetzen – etwa die Mehrheit der Punkte, die ich in meinem damaligen Wahlprogramm² aufgeführt hatte. Nichtsdestotrotz ist das eigentlich eine Daueraufgabe. Manche Probleme sind wir angegangen, dafür kommen neue Herausforderungen auf uns zu, z.B.: * Die zunehmende Firmenpräsenz in den Working Groups der OSMF. * Die Risiken, wenn Arbeit in der Foundation zunehmend durch bezahlte Kräfte erledigt wird. * Der wachsende Anteil bezahlten und organisierten Mappings an den Beiträgen zu OSM, und die Nutzung von Werkzeugen wie RapiD. * Die immer noch unzureichende Durchsetzung unserer Standards für Namensnennung, gerade bei prominenten Datennutzern wie Facebook. Dafür zu sorgen, dass die Interessen der freiwilligen Mapper bei den Veränderungen in OSM nicht unter die Räder kommen, wird also weiter ein Schwerpunkt für mich sein. Allerdings will ich mich nicht darauf beschränken. Mir liegt auch am Herzen, den Innovationsstau bei der zentralen Infrastruktur von OSM zu lösen: Dass etwa die API seit über einem Jahrzehnt keine großen Updates mehr erlebt hat, die OSM-Hauptseite nur einen Bruchteil der Möglichkeiten von OSM zeigt, die Leute von Forum und Mailingliste in proprietäre soziale Netzwerke abwandern oder dass wir lange gewünschten Website-Features in den letzten Jahren kaum einen Schritt näher gekommen sind. Da die OSMF diese Dienste betreibt, sollten wir auch dafür sorgen, dass sie mit dem Rest des OSM-Universums Schritt halten. Die offizielle Sammlung³ der Antworten und Positionen aller Kandidaten wurde inzwischen veröffentlicht, meine findet ihr hier: https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos/Tobias_Knerr Dort äußere ich mich sehr viel ausführlicher (auf Englisch, aber es überlebt eine automatische Übersetzung einigermaßen heil :)). Ich stehe euch aber auch hier auf der Liste gern Rede und Antwort! Viele Grüße, Tobias PS: Ich möchte euch bei dieser Gelegenheit die zusammen mit den Wahlen stattfindenden Abstimmungen über eine Ausweitung der Beitragsbefreiung für aktive Mapper auf die normale Mitgliedschaft sowie die beiden Vorschläge zum Schutz vor Übernahmeversuchen (Mindestvoraussetzungen für die Mitgliedschaft, Verbot von durch den Arbeitgeber gesteuerter Stimmabgabe) ans Herz legen. Die letzten beiden sind zwar noch keine konkreten Änderungen, sondern nur eine Aufforderung an den Vorstand, entsprechende Vorschläge zu erarbeiten, aber ein klares Ergebnis würde dennoch ein wichtiges Signal senden. ¹ https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board ² https://wiki.openstreetmap.org/wiki/User:De:Tordanik/2018_OSMF_board_elections_manifesto ³ https://wiki.openstreetmap.org/wiki/Foundation/AGM20/Election_to_Board/Answers_and_manifestos ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] reddit AMA with some OSMF Board members. 15:00Z 9 Nov
On 30.10.20 10:04, Martin Koppenhoefer wrote: > Rory, I am absolutely sure there was no bad intent in the choice of > format and platform, but given where this discussion went so fast, I > believe the setting should be reconsidered, evaluating the possibility > of choosing an open platform. When I asked him, Spanholz said he would be happy to see the questions and answers mirrored onto an open platform. All it takes is one volunteer (or several) to step forward and do the manual work of copying content back and forth. Which open platform? Up to whoever volunteers. :) And of course, the offer to submit questions by direct message still stands: On 29.10.20 22:58, Tobias Knerr wrote: > * Spanholz, the user who has been most active in organizing this AMA, > has already offered to post questions on behalf of other people. So > you can send in your questions without needing to sign up to reddit. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] reddit AMA with some OSMF Board members. 15:00Z 9 Nov
I've been considering the downsides of using a proprietary channel when I was invited to participate. My thinking is: * The questions and answers are publicly visible. (Yes, Reddit may nag you sign up or install their app – close that noise.) * Spanholz, the user who has been most active in organizing this AMA, has already offered to post questions on behalf of other people. So you can send in your questions without needing to sign up to reddit. For something that's not an official event (just something individual board members participate in), these options seem good enough. Is it ideal? No, and I would be more than happy to participate in an event hosted on our open platforms. But it's an initiative that I want to encourage, as I hope it could get more OSM community members interested in foundation matters, and the foundation could use more active participation. It would be even better if community members took the initiative to run more fun events on our self-hosted platforms – that would probably do more to make them more lively and active than the board could ever hope to achieve with its decrees. (And of course you can ask questions on OSM channels around the year, no need to wait for an "AMA". I know I don't need to tell that to you in particular, but I wish the bulk of the community was less shy about speaking up on OSMF issues.) On 29.10.20 21:30, Christoph Hormann wrote: > So i suppose you will circumnavigate any subject related to OSMF governance > or the election and that you will not refer to what is going to be said there > in any future discussion of OSMF matters (because then it would need to be > considered as part of a consultation by the board). Not every communication between a member of the board and one or more community member(s) constitutes a "consultation". It's good to be wary about slippery slopes, but this just doesn't make the cut. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] M$ Flightsimulator
On 31.08.20 15:48, Martin Koppenhoefer wrote: > https://www.rockpapershotgun.com/2020/08/28/players-are-fixing-microsoft-flight-simulators-missing-monuments-with-google-maps/ > > is there a way to import this data back to OpenStreetMap? Given that they're using Google Maps, I doubt it. But I do feel there is some potential for a free collection of crowdsourced 3D models for use with OSM (beyond what's possible with Simple 3D Buildings). This is the gap I hoped the 3D Model Repository (https://3dmr.eu/) would fill, but so far it hasn't taken off. If someone is interested in helping with that, there's a lot to do. Creating models, helping with coding (gltf support would be nice, for example), and there's even data we're permitted to import into 3DMR that hasn't been uploaded simply due to lack of time for converting/cleaning up the models. Yours, Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing all signposts from relations
On 25.07.20 18:14, pangoSE wrote: > Recently it was discussed whether to have signposts in route relations. > I suggest we delete them from all relations by running a script. > I se no loss of information It loses the information whether or not a route is signed at a particular signpost. Because, no, it is not the case that every signpost will always contain directions for every route running closer than x meters past it. You may not personally care about that information, but that's a very different argument. These are verifiable facts that someone found useful enough to spend time mapping, and I don't think there's anything inherently wrong with having them in OSM. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Q site update from Ops
Also thanks from my side Mike. As of today the help site seems to be working again but only a few days back it had been seeing the same problem again for several weeks. Who knows what is causing these periodic failures. So I'm looking forward to your monitoring and any possible short-term solution. But even if this immediate JS/usability problem can be fixed there are still so many smaller annoyances that before long we should still look into migrating the site to a newer software. cheers, Tobias Am 05.07.2020 um 10:16 schrieb Mateusz Konieczny via talk: Thanks to entire Ops group for work on this and other things! 4 Jul 2020, 07:35 by m...@teczno.com: Hi Everyone, Since Tobias Wrede started this thread in May, the Ops group has discussed the Help site during our regular meetings. We understand the importance of the Q site and acknowledge that the software running it is old and under-maintained. In addition to the possibility of moving the site to a new platform like the ones mentioned in this thread, we’ve also verified that all past Q content can be archived [1] regardless of future platform and talked about potential underlying causes of the frontend script problems some users have experienced [2]. Currently, the Ops group has two initial conclusions: 1) We aren’t able to confirm the extent of the Javascript problems described in this thread because we lack a front-end monitoring that would provide this information. Our existing monitoring extensively covers the underlying server, shenron [3], alongside superficial uptime measurements [4]. 2) The Q server is shared by Trac and SVN services which are being deprecated over the next month [5]. Deprecating Trac and SVN will allow us to better isolate and observe problems that Q is experiencing, and perhaps solve them by removing these competing services on one of OSM’s older pieces of hardware. Over the next two months, I’ll be watching the thread [2] for reports of new failures. If these continue past August when SVN and Trac have been deprecated, we’ll add monitoring to better understand their cause and determine what work may be needed to fix or migrate OSM’s Q site. -mike. Links: 1. https://ops.pads.ccc.de/meeting-202006-A (archiving report starts at line 173) 2. https://help.openstreetmap.org/questions/74831/why-does-the-add-a-new-comment-button-sometimes-not-work? 3. https://munin.openstreetmap.org/openstreetmap.org/shenron.openstreetmap.org/index.html 4. https://uptime.openstreetmap.org 5. https://lists.openstreetmap.org/pipermail/dev/2020-July/030958.html Ops Meeting Minutes: - https://ops.pads.ccc.de/meeting-202005-B (July 1) - https://ops.pads.ccc.de/meeting-202006-A (June 4) - https://ops.pads.ccc.de/meeting-202007-A (May 22) On May 20, 2020, at 12:28 AM, Tobias Wrede wrote: Hi, we have several channels in OSM to facilitate discussions and support. First touch point for new users is often help.openstreetmap.org. Questions relating to mapping in general, tagging, editors, development, OSM based applications are asked there and get answered in most cases. The site is based on OSQA, a software which has not been maintained in some time. Some application errors have surface in the past but had to be ignored since no fixes are coming from OSQA any more. Until now we could live with that. They were annoying but not critical. There are open tickets on OSM github to move the help site to some other framework (https://github.com/openstreetmap/operations/issues/149, https://github.com/openstreetmap/operations/issues/377) but there isn't exactly an abundance of volunteers to take care of that. Usability of help.openstreetmap.org has now seriously worsened over the past few days with some js error popping up for longer and longer times (https://help.openstreetmap.org/questions/74831/why-does-the-add-a-new-comment-button-sometimes-not-work). Buttons to support formatting questions and answers are gone, comments cannot be added and moderation functions (reporting, converting questions to comments etc.) are not working anymore. If this continuous we can shut down the site soon. Even if this problem got resolved somehow it's only a matter of time until a new problem arises. The site provides a low entry hurdles place to ask questions that can be solved by simple answers. I'd hate so see it gone. I'm neither a programmer who could help out on the technical side nor am I involved in OSM organization and politics to have an idea on how this could be sorted out. Question around: Can we find someone
Re: [OSM-talk] Could/should editors detect/disallow huge changeset bboxes?
On 12.06.20 13:00, Frederik Ramm wrote: > I wonder if it would be feasible or desirable for editors to warn users > if they are at risk of creating country/world-spanning changesets. It would certainly be a improvement for day-to-day work. The root of the issue, though, is that bounding boxes are a poor basis to determine whether a changeset is of interest to a mapper watching a particular region. If a changeset contains a change in France and one in Poland, then a mapper observing Germany should really just not be alerted to that changeset in the first place, and it should be possible for a mapper in Poland to view only the subset of the changes that affect their own country. IMO, an ideal changeset represents one logical unit of work. It shouldn't contain multiple unrelated changes, but at the same time, related changes should not be split across different changesets. Right now we're intentionally doing the latter to work around the limitations in our tools, and I understand and support that, but I hope this view of "large bbox = bad" doesn't get too firmly entrenched. Let's keep in mind that it's essentially a workaround for missing software features, that the proper fix is to improve the software, and that we should drop this rule once the reasons for it no longer exist. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Massenweise Entfernung von oneway=no
On 22.05.20 15:15, Volker Schmidt wrote: > Ich persoenlich setze routinemaessig oneway=no um anzuzeigen, dass ich > geprueft habe, dass die Strasse keine Einbahnstrasse ist. In Verbindung mit > dem Aenderungsdatum ist das nuetzlich in Gegenden, wo Strassenrichtungen > haeufig von den Behoerden geaendert werden. Meiner Meinung nach geht die Idee, Default-Werte explizit zu setzen, zu Lasten der Übersichtlichkeit. Die logische Konsequenz wären ja maxweight=none, maxheight=none, bridge=no, tunnel=no, covered=no access=yes vehicle=yes motor_vehicle=yes etc. an fast jeder Straße. Und wie mappe ich z.B., dass zwischen zwei Straßen keine Abbiegebeschränkung besteht – lege ich dann jeweils eine Relation mit restriction=allowed an? Wie mappe ich, dass an einer Stelle kein Gebäude steht, in einem Gebäude kein weiterer Laden mehr ist, auf dem Gehsteig kein weiterer Abfalleimer steht, ...? Vielleicht etwas übertrieben, aber worauf ich hinaus will: Die Abwesenheit von einem Objekt oder Attribut sollte normalerweise nicht erfasst werden – nur in Ausnahmefällen dort, wo sie überraschend ist (weil es kürzlich anders war, die Luftbilder veraltet sind, es bei den Straßen drumherum anders ist, ...) . Wenn in deiner Gegend bestimmte Arten von Straßen oft "umgedreht" werden, kann das durchaus so ein Fall sein. Aber auch dann wäre evtl. etwas nach Art von last_check:oneway= besser, denn das funktioniert öfter als nur bei der ersten Überprüfung und es beeinträchtigt als klar erkennbares Qualitätssicherungs-Tag die Übersicht weniger. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] our Q site help.openstreetmap.org is dying
Am 20.05.2020 um 21:32 schrieb Frederik Ramm: We've taken great care to write our replies in a generic fashion where possible, with the aim of collecting knowledge that others can profit from (instead of asking the same question over and over again). Not copying past answers, at least the last two years or so, would mean we'd have to write all these answers again because the questions will inevitably be asked. I think it would be rather disrespectful to those who have invested a lot of time into building a good body of knowledge in the old system to say "let's throw away this content, main thing is we get a shiny new system". And the alternative of having to keep the old system around in a read-only fashion is not super attractive either. Hi Frederik, I'm myself among the more frequent contributors on the site. I'm not saying to throw everything away and would appreciate if one could still refer to the the old answers. But considering how long this issue has been hanging in the air without resolution I would favor a practical way over one that will let us wait another few years before something happens. In my view it should be possible to leave the old site in a read only state and start a new site from zero. We could still link to answers on the archived site. Of course I'd welcomed if there was a reasonably fast way of moving and migrating all the old Q Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] our Q site help.openstreetmap.org is dying
Am 20.05.2020 um 16:04 schrieb Lester Caine: ... offers a hope that there is potential to pump existing material across? I wouldn't worry too much about migrating past material to the new site. Of course that would be a plus but not doing so shouldn't stop us from migrating to something new and lasting soon. Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] our Q site help.openstreetmap.org is dying
Hi, we have several channels in OSM to facilitate discussions and support. First touch point for new users is often help.openstreetmap.org. Questions relating to mapping in general, tagging, editors, development, OSM based applications are asked there and get answered in most cases. The site is based on OSQA, a software which has not been maintained in some time. Some application errors have surface in the past but had to be ignored since no fixes are coming from OSQA any more. Until now we could live with that. They were annoying but not critical. There are open tickets on OSM github to move the help site to some other framework (https://github.com/openstreetmap/operations/issues/149, https://github.com/openstreetmap/operations/issues/377) but there isn't exactly an abundance of volunteers to take care of that. Usability of help.openstreetmap.org has now seriously worsened over the past few days with some js error popping up for longer and longer times (https://help.openstreetmap.org/questions/74831/why-does-the-add-a-new-comment-button-sometimes-not-work). Buttons to support formatting questions and answers are gone, comments cannot be added and moderation functions (reporting, converting questions to comments etc.) are not working anymore. If this continuous we can shut down the site soon. Even if this problem got resolved somehow it's only a matter of time until a new problem arises. The site provides a low entry hurdles place to ask questions that can be solved by simple answers. I'd hate so see it gone. I'm neither a programmer who could help out on the technical side nor am I involved in OSM organization and politics to have an idea on how this could be sorted out. Question around: Can we find someone to take care of the technical side? Can we involve any of the OSM organizations to find, maybe pay, someone? Does the community even find it worthwhile keeping the site? cheers, Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bridge area construction
On 05.05.20 22:24, Jack Armstrong wrote: > man_made=construction > construction=bridge > layer=1 The =construction + construction= tagging is only really common for highway, building and railway tags (where it sticks around for historic reasons, in my impression). Other tags are more likely to use to use lifecycle prefixes: https://wiki.openstreetmap.org/wiki/Lifecycle_prefix For your example, that would be: construction:man_made = bridge layer = 1 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Let's talk Attribution
Hi Alexandre, it's true that too many projects using OSM do not provide the required attribution. However, I'm surprised that you got reactions of "this is fine" for some of the more egregious examples you mention in your email. While individual mappers will of course hold a wide range of opinions, that is not the position of the OSM Foundation. On 27.04.20 19:49, Alexandre Oliveira wrote: > On the mobile > version of the Facebook page, there's no attribution at all, simply a > map. And worse, it redirects to Google Maps when you click on it. I assume this is the same issue as the one described here: https://github.com/grischard/osm-lacking-attribution/issues/8 Facebook was contacted about this specific problem 2.5 months ago. They have acknowledged it as an issue, but have unfortunately failed to correct it so far. For now, we still have hope that they will just finally fix it. At some point, we may have to take further steps, but we haven't really come to an agreement on what those would be. For OSMF action on issues which are less clear-cut (i.e. attribution is present, but insufficient), the main roadblock is that we have not yet approved the attribution guidelines which will make it clearer what style of attribution we expect. Of course, data users are already obligated to follow our license today, but hopefully the guidelines will help to eliminate any ambiguity about whether certain controversial practices are acceptable. The most recent version of the guidelines drafted by the LWG is almost there, but has drawn community criticism about being too generous especially w.r.t. initially hidden attribution. We are working on them, and once they are approved, we will point to them when we contact data users about low-quality attribution. I admit that the OSMF has been frustratingly slow to make progress on attribution, and I hope we will get better about this. But there's a lot that can be achieved by the community in a distributed manner as well. You've already mentioned the #AttributionIsNotOptional initiative as an example. It's not rare to hear success stories about mappers simply sending a friendly reminder to some companies, especially small-scale users who made a honest mistake and forgot about the attribution. It also helps to report lacking attribution to Guillaume's previously mentioned issue tracker¹ – the board is keeping an eye on that and prioritizing issues based on whether the site or app has already been contacted, how bad the attribution is, and on how visible the site is. In any case, I'd like to emphasize that a slow response to missing attribution should not be mistaken for being ok with it. Nor does it mean that we will not act more decisively in the future. Visible attribution is a key requirement of our license, and not optional. Tobias ¹ https://github.com/grischard/osm-lacking-attribution ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] Dienste für virtuelle OSM-Stammtische
Viele OSM-Stammtische finden derzeit wegen der Corona-Pandemie nicht statt. Es gibt aber Alternativen! Einige Gruppen haben schon erste virtuelle Treffen erfolgreich durchgeführt. Wer noch auf der Suche nach geeigneten Diensten dafür ist, findet hier ein paar von uns getestete Vorschläge: * BigBlueButton: Der OSMF-Vorstand benutzt seit April eine gemietete Instanz der freien Videochat-Software BigBlueButton für Vorstandstreffen. Diese steht auch der OSM-Community zur Verfügung. Um sie zu nutzen, muss einer der Teilnehmer des Treffens sich unter https://osmvideo.cloud68.co/user/signup registrieren. Nach der Anmeldung findet man dann einen Link zu seinem eigenen "Home Room", den man mit anderen Nutzern teilen kann. http://imagico.de/files/bbb1.png * Jitsi: Die derzeit wohl bekannteste freie Lösung für Videochats. Es gibt eine ganze Reihe frei nutzbarer Jitsi-Server im Netz, eine Liste findet sich unter https://pads.ccc.de/ep/pad/view/jitsiliste/latest. Um ein Jitsi-Treffen zu starten, wählt man dafür einen eindeutigen Namen und teilt diesen mit allen Teilnehmern. http://imagico.de/files/jitsi1.png * Mumble: Wer auf das Video-Bild verzichten kann oder möchte findet mit Mumble eine deutlich schmalbandigere Lösung, die aber im Gegensatz zu den übrigen Möglichkeiten die Installation einer eigenen Software erfordert. Wer schon mal bei einem FOSSGIS- oder OSMF-Vorstandstreffen zugehört hat, kennt dies bereits. Eine Anleitung findet sich unter http://podcast.openstreetmap.de/mitmachen/. Der FOSSGIS-Mumble-Server kann von allen in der OSM-Community verwendet werden, daneben gibt es als Ausweich-Möglichkeit auch noch einen Mumble-Server von HOT: https://wiki.osm.org/Mumble Egal für welche technische Lösung ihr euch entscheidet - am Anfang mag dies erst einmal ungewohnt erscheinen. Aber ausprobieren lohnt sich! Viele, die jetzt in Zeiten der Corona-Pandemie zum ersten Mal virtuelle Treffen ausprobiert haben sind positiv überrascht, wie kommunikativ so was sein kann. Also: keine Scheu beim ausprobieren und teilt Eure Erfahrungen in der OSM-Community. (Danke an Christoph für die Hilfe beim Testen und Texten!) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] remove the suggestion to credit "contributors"
On 17.04.20 15:33, Mario Frasca wrote: > On 17/04/2020 04:20, Martin Koppenhoefer wrote: >> What about removing [the trailing "contributors" from the © >> attribution], so that the required credit becomes "© OpenStreetMap" >> (it could also be © OpenStreetMapFoundation, but maybe "© >> OpenStreetMap" would be sufficient, given that OpenStreetMap is a >> brand owned by the OpenStreetMapFoundation)? > > I find the explanatory text in parentheses confusing. Agreed, the text in parentheses is problematic. From a moral perspective, explicitly crediting the foundation would very much feel like an unjust appropriation of the mappers' work, regardless of the legal technicality that the OSMF is publishing the database. > I'm fine with associating OSM with its contributors, so if you say that > "© OpenStreetMap" is the same as "© OpenStreetMap contributors", I'm fine. +1. To me, the foundation is not OpenStreetMap. It's an entity that exists to *support* OpenStreetMap. (It's good that the OSMF makes this mental distinction visible by using separate domain, osmfoundation.org.) When I think of OpenStreetMap, I think of the many people who help build our map, not a formal incorporated entity. I hope that other mappers also see themselves as part of OpenStreetMap. So as I said before, I like the core of the suggestion – but it could have been presented better by leaving the foundation bit out of it. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-legal-talk] [OSM-talk] remove the suggestion to credit "contributors"
On 17.04.20 11:20, Martin Koppenhoefer wrote: > What about removing this, so that the required credit becomes "© > OpenStreetMap" Yes, crediting © OpenStreetMap with the appropriate link would be a good solution. Aside from being more concise, it's a lot less awkward in a non-English or multilingual context. Note that our Legal FAQ¹ already allow this in some circumstances: > Because OpenStreetMap *is* its contributors, you may omit the word > "contributors" if space is limited. So using the snappier attribution in all contexts would also simplify things compared to the status quo of having two different attribution wordings depending on the available space. You're in luck, by the way: The latest draft attribution guideline already proposes this very change. And while there are some problematic aspects of that draft which need to be changed before it can be accepted, your suggestion was popular in past discussions (e.g. in August²), so there's a good chance it will become reality. Tobias ¹ https://wiki.osm.org/Legal_FAQ#3a._I_would_like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F ² https://lists.openstreetmap.org/pipermail/talk/2019-August/083078.html ___ legal-talk mailing list legal-talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] remove the suggestion to credit "contributors"
On 17.04.20 11:20, Martin Koppenhoefer wrote: > What about removing this, so that the required credit becomes "© > OpenStreetMap" Yes, crediting © OpenStreetMap with the appropriate link would be a good solution. Aside from being more concise, it's a lot less awkward in a non-English or multilingual context. Note that our Legal FAQ¹ already allow this in some circumstances: > Because OpenStreetMap *is* its contributors, you may omit the word > "contributors" if space is limited. So using the snappier attribution in all contexts would also simplify things compared to the status quo of having two different attribution wordings depending on the available space. You're in luck, by the way: The latest draft attribution guideline already proposes this very change. And while there are some problematic aspects of that draft which need to be changed before it can be accepted, your suggestion was popular in past discussions (e.g. in August²), so there's a good chance it will become reality. Tobias ¹ https://wiki.osm.org/Legal_FAQ#3a._I_would_like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F ² https://lists.openstreetmap.org/pipermail/talk/2019-August/083078.html ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SotM 2020 - Move to virtual conference
On 26.03.20 14:45, Christine Karch wrote: > the deadline ended a month ago. At the moment it is not planned to call > for additional submissions. SotM usually offers numerous slots for Lightning Talks. Will that be the case with this virtual conference as well? Spontaneous LT submissions might be an opportunity for people who originally didn't submit because of the barrier of physical travel. Also, thanks to everyone in the SotM team for their work under these unusual circumstances! ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM is not the place for dissemination of authoritative data sets
On 19.03.20 17:54, Jóhannes Birgir Jensson wrote: > So - why are authoritative data sets an unwelcome addition? At its core, OSM is a platform for collaboratively editing geodata. So the following would be strong reasons not to import a dataset: - other mappers should not edit it (because the dataset is the official source and changing it would just make it wrong) - other mappers cannot meaningfully edit it (because we cannot see the object in the real world and don't have access to useful sources). The way you describe it, collaborative editing doesn't seem to be a net benefit to your scenario, and in fact makes it harder to sync updates with the authoritative source. So as a thought experiment: Why not just convert your dataset to the OSM format to make it compatible with the OSM ecosystem, but skip the import into the main OSM database? In practice, I guess part of the answer for that is discoverability: Who wants to hunt down datasets scattered across various servers and portals? So it's tempting to put it all into a single big database. And I guess that's ok as long as it doesn't get in the way of the main purpose of that database too much – which is collaborative editing, not data distribution. But surely, with a decent implementation of compatible data layers tracked in some central repository, authoritative data could be used *with* OSM without being *in* OSM. Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] 3D OSM with terrain
Hi Nick, On 06.03.20 18:13, Nick Whitelegg wrote: > Anyway, I was wondering if there was any active development on > open-source 3D OSM renderers with terrain? among the open source options, at least the Blender plugin blender-osm² and the OSM2World renderer have terrain support. As maintainer of the latter, I feel I should point out the current limitations, though: While OSM2World has support for terrain based on SRTM, that feature is still very experimental. In particular, there is no level of detail mechanism for terrain (which makes it not scale well to wide open terrain in the countryside) and the workflow in the desktop software is inconvenient (need to download SRTM data manually and update a config file with the path pointing to the dataset). Due to these quality and performance issues, the first version of our still-not-finished WebGL client¹ will most likely not include 3D terrain. But the goal is to eventually get there, so if you see potential synergies, please reach out! Tobias ¹ https://wiki.osm.org/OSM2World/WebGL_client ² https://wiki.osm.org/Blender#blender-osm:_OpenStreetMap_and_Terrain_for_Blender ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Microgrants call for committee
Hi all, reminder that the call for microgrants committee members is about to close soon. We would still welcome additional applications! On 16.02.20 12:06, Joost Schouppe wrote: > Send your application to join the Microgrants Committee to > microgra...@osmfoundation.org by March 8th. If you need a quick refresher, the blog post is a good starting point: https://blog.osm.org/2020/02/17/call-for-microgrants-committee/ Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Datenqualität open data NRW und OSM
On 06.03.20 12:42, Florian Lohoff wrote: > On Fri, Mar 06, 2020 at 11:30:53AM +0100, Otto Dassau wrote: >> * Könnten/Dürften die Daten NRW genutzt werden, um die OSM Daten >> flächendeckend z.B. für NRW zu optimieren? > > Am Ende nein. Gucken darfst du, aber übernehmen nicht. Vor ein paar Tagen wurde im Forum die Neuigkeit verbreitet, dass die "Geobasisdaten NRW" jetzt unter der Datenlizenz Deutschland Zero stehen, die meines Wissens mit OSM kompatibel ist: https://forum.openstreetmap.org/viewtopic.php?pid=779174#p779174 Ich bin mir jetzt nicht sicher, ob da die hier diskutierten Daten auch darunter fallen? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Regarding GSoC 2020
On 26.01.20 14:02, Gollavilli Srikanth wrote: > [...] I would love to contribute to OpenStreetMap > in Google Summer of Code 2020. Thanks for your interest! At the moment, the OSM community is still preparing for GSoC by collecting project ideas and potential mentors. So for now, you can keep an eye on our list of project ideas¹ as more will be added over time. Instructions on how to apply will later be posted on our wiki as well². Of course, if any of the the existing project ideas appeal to you, you can already get started by reaching out to the people listed as points of contact for that idea. Note that Google hasn't decided on a list of mentoring organizations yet, so it's not guaranteed that OSM will be involved in GSoC this year. (But we hope so, of course!) Yours, Tobias ¹ https://wiki.osm.org/Google_Summer_of_Code/2019/Project_Ideas ² https://wiki.osm.org/Google_Summer_of_Code/2019 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Vorstellung deutsche Umap-Instanz
Hallo Lars bin erst jetzt auf diese Nachricht gestoßen. Interessant. Gibt es Unterschiede zur Instanz auf umap.openstreetmap.fr? Ich habe gesehen, es stehen weniger Hintergründe zur Verfügung. Sonst noch was? Kann man Projekt von der französischen Instanz problemlos auf die deutsche portieren? Ist von den Betreibern auch irgendjemand bei der Entwicklung involviert? Ich nutze uMap gerne, aber ein großes Problem ist, dass vom Entwicklerteam so gut wie gar nicht auf Probleme reagiert wird. Die Issue-Liste in Github wird länger und länger ohne irgendeinen Fortschritt zu sehen. Anfragen zu uMap-Problemen landen häufig auf help.openstreetmap.org, aber da ist auch keiner von den Entwicklern oder Betreibern aus .fr zu finden. Antworten sind nur rudiementär möglich. Immer häufiger schlagen da Anfragen auf, dass Nutzer unangemeldet eine Karte erstellt haben und jetzt den geheimen Link zum Editieren nicht mehr finden. Für diese Nutzer ist es unmöglich, jemanden zu erreichen, der ihnen weiterhelfen kann. Gibt es in der neuen deutschen Instanz einen Ansprechpartner für solche Fälle? Auf der Seite wird, so weit ich das sehe, auch nur auf die gleiche Seite im Wiki verwiesen wie von der französichen Instanz. beste Grüße Tobias Am 15.06.2019 um 11:46 schrieb lars lingner: Hallo zusammen, hiermit möchte ich auf die deutsche uMap-Instanz unter der URL https://umap.openstreetmap.de aufmerksam machen. Mit uMap können interaktive Karten auf einfache Art und Weise erstellt werden. Die Software wird hauptsächlich in Frankreich [1] entwickelt und ist Open Source. Im OSM-Wiki [2] gibt es eine Anleitung, z.b. auch wie Daten direkt von der Overpass-Api eingebunden werden können. Die Kosten für das Hosting werden vom FOSSGIS e.V. [3] übernommen. Probiert es aus und sagt es weiter. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entfernen des "WikiProject"-Präfixes
On 18.08.19 18:44, dcapillae wrote: > I would like to change the name of the wiki pages related to the Germany > mapping project to remove the "Wikiproject" prefix according to the > pages name conventions [1]. Sure, I'd be happy to see the pages renamed. Thanks for all the time you spend on wiki maintenance! Für die deutschsprachigen Mitleser: Daniel möchte gern die Seite "WikiProject Germany" nach "Germany" verschieben, wie er es schon bei diversen anderen Ländern gemacht hat. Aus meiner Sicht ist das sinnvoll, da Wikiseiten zu Städten, Bundesländern etc. schon heute nur den jeweiligen Namen als Seitentitel haben und die Begrifflichkeit "WikiProject" ein Relikt aus Urzeiten ist, die heute den durchschnittlichen Leser eher verwirren dürfte. Bestehende Links werden weiterhin funktionieren, da Weiterleitungen eingerichtet werden. Daniel verspricht, darauf zu achten, dass alles weiterhin korrekt funktioniert. > I could make the necessary changes, and also add the "Country" template > [9] to the Germany project page, although this change is optional. I probably wouldn't add the "Country" template. It promises more than the current page can keep. The page is quite stale at this point, so a visitor isn't going to find "national events, ongoing projects" or things like that, unfortunately. Hier geht es darum, ob die Vorlage https://wiki.osm.org/Template:Country auf der Wikiseite eingebaut werden soll. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Attribution guideline status update
On 09.08.19 16:35, Frederik Ramm wrote: > I wonder if we could perhaps get rid of the "Contributors" mention > altogether. This idea makes a lot of sense. Especially as both the guideline draft and the current FAQ already allow this "if space is limited": > Because OpenStreetMap is its contributors, you may omit the word > "contributors" if space is limited So aside from making it much less awkward to attribute OSM in non-English or multilingual contexts, this change would also simplify the rules a bit and remove one source of ambiguity. I like it! Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Attribution guideline status update
Thank you for your work! I believe that clearly documenting our expectations is a very important step towards solving the current problems surrounding attribution. It will help well-intentioned data users to avoid accidentally messing up OSM attribution, and it leaves fewer excuses for the less well-intentioned ones – making it easier for us to put pressure on them to improve their practices. I do have a couple of questions/comments about the current draft: * Can you confirm that the current attribution practices on Wikipedia and many similar projects would be covered by the "small images" case? * I believe video games/simulations should be given similar treatment as fictional movie productions by permitting attribution in the credits as an alternative to the current options. Not allowing this seems to contradict the larger "in a location where customarily attribution would be expected" principle, as rolling credits are customary for many gaming genres. (I'm mostly thinking of traditional PC or console games here, not so much of mobile apps.) * What's the guidance on scenarios where software does not ship with OSM data, and does not display online maps, but e.g. allows downloading map data for offline use? Would it be acceptable to make the license information part of the download process, or is it still required that attribution is visible on-screen during use? Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Survey on global and local communities in OpenStreetMap
Hi Marc, On 07.08.19 16:53, marc marc wrote: > where are the results of the previous survey and the resulting actions > available? there were two surveys run by the OSMF in the past months. One was the survey in advance of the board's face to face meeting in Brussels. We summarized these survey results as part of this blog post: https://blog.openstreetmap.org/2019/06/13/surveying-openstreetmap/ Unfortunately, we cannot share the raw dataset as we failed to ask the participants for their permission to publish their responses. However, if you have specific questions about the results, we'll try to answer if possible! The most commonly mentioned concerns were discussed immediately at the boards face-to-face meeting in Brussels, and board members are currently tasked to work on several of them. There were also some ideas which we felt were not part of the board's responsibilities, so we decided to forward these to the appropriate parties. A second, more recent survey was directed to working groups. This effort is still ongoing – not all groups have responded so far, and I believe we haven't evaluated the responses in detail yet. Yours, Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Removing "Wikiproject" prefix from place pages
I'm in favour of dropping the "WikiProject" prefix from page titles. It's been mildly bothering me for a while, but the amount of manual effort involved has stopped me from doing anything about it so far. Thanks to Daniel for being willing to tackle this! The Talk:Wiki page and the Wiki subforum might also be good places to potentially recruit volunteers for the task. On 18.07.19 11:04, Harry Wood wrote: > The idea of getting rid of the "WikiProject" page title prefix. There's > a bit of discussion of that here > https://wiki.openstreetmap.org/wiki/Talk:Wiki_organisation#Page_Name_conventions.2Fguidelines Interesting background, thanks! This kind of history isn't always easy to find if you're not aware of it. Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Reordering and rewriting Good Practice wiki page
On 04.07.19 05:53, Joseph Eisenberg wrote: > 2 Verifiability (+Map what's on the ground, Don't map: historic > events, temporary features, local legislation etc) In my opinion, the practices that you've turned into subheadings of the verifiability section are not merely special cases of verifiability. For example, temporary features are perfectly verifiable (until they cease to exist, of course). The reasons why it's not usually considered good practice to map them include the unsustainable maintenance effort and the impact on offline use of our data. So I feel these items are really their own separate practices, not part of verifiability. If you want to avoid having too many top-level headings, you might still be able to group the three "Don't map..." rules into a common section. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wikibase items instead of usual templates for wiki pages?
On 09.06.19 13:59, Joseph Eisenberg wrote: > Has this wikibase feature been discussed and approved by the community > in some forum? Perhaps it happened before I was involved with OSM? I > don't quite understand how it works. The way it works is that every tag has a "data item". This is the one for natural=isthmus, for example: https://wiki.openstreetmap.org/wiki/Item:Q19327 Of course, you're not expected to find this numeric URL yourself. You can get there from the wiki page for that tag by clicking on a "pencil" icon next to the description in the infobox, or by using an "OpenStreetMap Wiki data item" link that appears in the left-hand menu on every page that has a data item associated with it. The idea behind data items is actually quite similar to how templates on the wiki work: There is a number of possible properties that you can fill in with information. The properties which are currently available are mostly identical to the ones used by the templates: Whether the tag can be used on nodes/ways/..., links to related/required/implied tags, an image, and descriptions in various languages. If some information is omitted from a wiki page, the infobox will pull it in from the tag's data item. Otherwise, the information written directly on the page will take precedence. A potential benefit of data items is that language-independent information does not need to be manually copied to each translation. And while software like Taginfo has been able to extract information from the wiki for a long time, the hope is that this kind of extraction will eventually become easier thanks to data items. I do not believe there has been a community decision to stop adding information directly on wiki pages. So the other wiki contributor's edit was probably premature. Of course, though, the current situation with content duplicated between data items and wiki pages isn't really ideal. But there's probably still some work left until data items can fully replace the existing systems (updating data consumers, plus working on usability and documentation). Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-ja] Housenumber plates in Japan
Dear fellow mappers in Japan I would like to adapt recording housenumbers in the Android app StreetComplete to the situation in Japan, if necessary. Can you help me? I would like to know how a housenumber plate in Japan looks like. Does it only show the house number, or more? Do you have some photos? See this GitHub issue here for more information: https://github.com/westnordost/StreetComplete/issues/1407 Cheers Tobias ___ Talk-ja mailing list Talk-ja@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-talk] An Archive namespace for the OSM wiki?
On 21.04.19 07:44, Yves wrote: > Is there a way to decrease the rank of some pages in the search results > in MediaWiki? The possibility of increasing/decreasing the priority of certain search results based on templates is being discussed at the moment as part of this topic: http://wiki.osm.org/Talk:Wiki#Proposal:_new_namespace_for_tagging_proposals ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] An Archive namespace for the OSM wiki?
On 20.04.19 09:24, Jochen Topf wrote: > So as always you have to look at each case. If a page contains content > that is still useful for our current world, keep it. But if something is > merely interesting for historical reasons then it can be deleted. And > yes, there is a gray area there, but humans can be trusted with these > decisions and the world will not end if occasionally somebody makes the > "wrong" decision. But stalling any progress in the wiki by requiring > discussions about any change is certainly not the right way. I'm in full agreement with the overall sentiment, and this paragraph sums up a lot of my objections to the proposed deletion policy. However, I believe that a lot of the social conflicts surrounding this topic are caused by how MediaWiki implements "deleting" things: Only admins can restore a deleted page or even view its history. In contrast, everyone can undo a regular deletion in the OSM database (at least in theory), and the history remains publicly visible. So after a similar discussion several years ago, we created this template for archiving proposals: https://wiki.osm.org/Template:Archived_proposal It basically amounts to removing a page's _contents_ (but not the page itself or its history) and replacing it with a link to a previous version of the same page that still had the original content. There's also typically some basic information left on the page so that users arriving from an external link know what they are looking at. This is what a proposal "archived" in this style looks like: https://wiki.osm.org/Proposed_features/barriers It mostly achieves the same goal as deletion, especially reducing the likelihood of getting in the way of searches (because there's little content left to be indexed). Actually, it may do so a bit too well – I've always been a bit concerned that it makes it hard to find old proposals even when you're explicitly looking for them – but because there are other approaches for finding proposals in particular (the RFC mails, and the infobox links on key/tag pages back to the proposal), they can still be found reliably. The main benefit, though, is the ability for others to easily revert this kind of change. It's easier to be bold in cleaning up the wiki when you know that that others can quickly undo any edits they dislike. Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bank of India (and other) Wikidata tags
Am 17.04.2019 um 22:03 schrieb Mateusz Konieczny: Among other popular wikipedia links "wikipedia='de:Stolpersteine'", "wikipedia='nl:Toeristisch Overstappunt'", are also clearly invalid, though here brand:wikipedia would be wrong and complete removal is probably necessary. Martin already commented on de:Stolpersteine. The adding of nl:Toeristisch Overstappunt has been questioned on the tagging list (starting with messages and ) but with no apparent outcome. I agree with you, in my opinion they are still dead wrong. Tobias ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Fehlender Lizenzvermerk bei Stern.de und Polizei Frankfurt
Hallo Thomas, Am 12.04.2019 um 07:24 schrieb Thomas Zimmermann: Da die Presseverlage so große Urheberrechtsverfechter sind und die Polizei als Vorbild dienen sollte, sollte man die beiden meiner Meinung nach auf diesen Urheberrechtsverstoß hinweisen. Immer zu. Da brauchst du hier nicht groß nachfragen, schick ihnen einfach eine E-Mail mit dem Sachverhalt. Habe ich schon öfters gemacht und jedes Mal Erfolg gehabt (bei der Europäischen Kommission hat es ein paar Monate gedauert zu den richtigen Verantwortlichen vozudringen, aber auch dort wurden auf der Webseite die Karten letztlich richtig ausgezeichnet). Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Besorgt über den iD-Editor
On 29.03.19 15:32, Frederik Ramm wrote: > Zugleich > äussern sich die Entwickler gern auch mal geringschätzend über das Wiki > oder Tagging-Diskussionen und nehmen sich eben das Privileg heraus, neue > Features einfach einzubauen, die sie gut finden Das scheint die herrschende Einstellung zu sein, ja. Zitat Bryan Housel frisch von letzter Woche: "I basically just disregard everything on the tagging mailing list and the OSM wiki." https://github.com/openstreetmap/iD/issues/5835#issuecomment-477696136 Das ist natürlich nicht die erste entsprechende Äußerung und der Link wirft auch sonst kein schönes Licht auf die iD-Entwicklung: Bryan äußert sich negativ über die Community, vertritt kontroverse Taggingansichten, die er via iD durchsetzen will, und sperrt beim Aufkommen von Kritik die Github-Diskussion für Nichtentwickler. Letztlich geht es auch hier wieder nur um eine Kleinigkeit, aber das Gesamtbild aus diversen solchen Vorfällen macht auch mir inzwischen Sorgen. Dass das alles mittelfristig ein Problem fürs Projekt werden kann, ist aus meiner Sicht ziemlich offensichtlich. Bei der Frage nach Lösungen würde ich mich im Großen und Ganzen Michael anschließen. Die wesentliche Hürde für eine (über die Kritik an Einzelentscheidungen und eventuelle Eskalation via Abstimmungen und DWG hinausgehende) Reaktion ist m.E. das Fehlen plausibler Alternativen. Wenn sich jemand fände, der eine auf Community-Konsens zurechtgestutzte Version der Tagging-Vorlagen von iD pflegt, sähe das schon ganz anders aus. Viele Grüße, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Questionnaire
On 23.03.19 12:05, John Whelan wrote: > You posted the same message in the HOT mailing list. The same message was also sent to personal mail addresses of OSM contributors yesterday, presumably scraped from mailing list archives. Additionally, it was posted to several other lists on the lists.osm.org server – including ones where it is quite off-topic, like the mostly dead "party" list¹. Overall, this is the 5th time I'm receiving a copy of this questionnaire link. I can't help but feel we need to encourage a better approach for polling the OSM community. Preferably one that also involves some feedback from people with OSM experience before the survey is sent out. Tobias ¹ https://lists.openstreetmap.org/listinfo/party ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed mechanical edit - elimination of osmarender:nameDirection - blatant tagging for the renderer
On 15.03.19 21:13, Simon Poole wrote: > Why would we want to create new versions of objects just to remove a tag > that is not hurting anybody in any way? Mostly for the reason which Mateusz has mentioned in his response: Keeping obsolete tagging around for years or decades adds to the burden of concepts that new community members need to learn to fully understand our data. But additionally, I would argue that removing them all at once actually results in a cleaner history than automatic removal by editors. It seems to me that performing these edits in one clearly labelled changeset fits our best practices – grouping related edits into a changeset and using meaningful changeset comments – much better than mixing them into completely unrelated changes would. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Fwd: Adressmapping auf Building-Relationen oder Outline
On 10.03.19 19:20, Tom Pfeifer wrote: > Eigenschaften, die das ganze Gebäude betreffen, sollten daher auf dem > Gebäudeumring liegen, der auch ohne 3D-Mapping da wäre. Also auch die > Adresse. Ja, solche Relationen werten normalerweise nur 3D-Renderer aus. Die Informationen, die auch andere Anwendungen brauchen, sind daher am Umriss besser aufgehoben. Als "belastbare Doku" würde ich "Simple 3D Buildings" heranziehen, den Taggingstandard fürs 3D-Mapping: "Building attributes (e.g., address, name, overall height, operator, etc.) must be tagged on the building outline."¹ In diesem Beispiel ist die Relation übrigens auch für 3D eigentlich nicht notwendig: Sämtliche Gebäudeteile liegen innerhalb des Umrisses und es gibt keine Überlappungen/Mehrdeutigkeiten mit anderen Gebäuden. Tobias ¹ https://wiki.osm.org/Simple_3D_buildings#Building_outlines ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] We need to have a conversation about attribution
On 28.02.19 23:35, Richard Fairhurst wrote: > The policy, introduced with the changeover to the ODbL, says: > > "We require that you use the credit “© OpenStreetMap contributors”... > For a browsable electronic map, the credit should appear in the corner > of the map." As you seem to remember what was going on at the time, maybe this is an opportunity to get an answer to a question that I've raised back in 2012, but (iirc) never got a response to: Who made the decision to add this requirement to the copyright page? https://lists.osm.org/pipermail/legal-talk/2012-October/007306.html I don't perceive off-map attribution as a recent trend: This style of OSM attribution was reasonably popular even back then, especially in mobile apps. And I don't remember any widespread calls for restrictions on the practice. In fact, the only mailing list discussion I recall is the one linked above, which had barely any participants: Three people questioning the then-recent change¹, and no one showing up to explain or defend it. So while I would agree that it's important for data users to respect the community's policies, it's not yet clear to me that these highly specific requirements on attribution placement did originate with the community in the first place. > a) we are happy for attribution to be behind a credits screen and we > will update our requirements to say so This is my personal preference, but I would still require equal prominence with other brands. Showing "Mapbox"² on-map, but moving OSM elsewhere, does not feel fair. Especially in situations where a data user does make other efforts to put OSM in the spotlight – e.g. by telling the user about OSM during map downloads or through a long-lived, or interactive, splash screen – I believe we should not insist on the corner placement. Tobias ¹ the rest of the thread is split off due to happening in a different month: https://lists.osm.org/pipermail/legal-talk/2012-December/007363.html ² My intention isn't to single out Mapbox here, that's simply the example that's already been used in this thread. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] "Küss- und Tschüsszonen" / Elternhaltestellen
Hallo, ich kenn das an Bahnhöfen als Kiss & Ride. Kurze Suche auf OSM zeigt, dass das sehr oft einfach als name=kiss and ride an Straßen, parking aisles, localities etc getaggt ist. K: Kraut und Rüben könnte man sagen. Tobi ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Bot edits on the OSM wiki
On 24.02.19 20:18, Christoph Hormann wrote: > I mainly wanted to make everyone who is not active on the wiki aware of > this. For the benefit of people who don't know the background, it's worth mentioning that these bot edits did not distort the actual meaning of the wiki pages, but were purely performing a trivial technical maintenance task. Here's an example: https://wiki.osm.org/w/index.php?title=Tag:waterway%3Driverbank=1805725=1650789==2015 To explain what's going on: The infoboxes on tag documentation pages are available in different languages. In the past, users editing the wiki had to manually set the desired language for the infobox with parameters such as "lang=en". That's no longer necessary because the infobox now automatically recognizes that it's part of an English page, and that it should probably display "Description" rather than "Descripción" or "Beschreibung". So as there is no longer a point in having "lang=en" parameters, they were recently removed by a bot. These edits are marked as bot edits, which not only makes it transparent that the edit was performed by a bot, but also solves the practical issue of watchlist spam (because such edits can be easily filtered out from the watchlist). Note that this wasn't some AI making decisions on its own, either, but simply a human editor deciding to remove a particular line of text from more than one wiki page at the same time. The bot API is just a tool that makes this process less tedious. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Experimentelles Öffnungszeiten-Webtool
Hallo Stefan, Am 19.02.2019 um 09:24 schrieb Stefan Keller: Feedback willkommen - hier oder als Issue im Repository! Läuft weitgehend gut. Hier ein paar Fälle, die das Tool nicht erkannt hat: 11:30 bis 22 Uhr, sonntags bis 21 Uhr Tool 1: 11:30-22:00 Tool 2: 11:30-22:00,Su- Beim diesem zugegebenermaßen nicht eindeutigen Fall kommt seltsames raus: 11 bis 1 Uhr | Küche 11:30 bis 22 Uhr, sonntags bis 21 Uhr Tool 1: nichts Tool 2: 11-01:00,11:30-22:00,Su- (zusätzlich zu oben fehlen bei der 11 vorne die Minuten) Tool 2 macht es richtig, Tool 1 vergisst den Donnerstag: geöffnet täglich von 10:00 bis 01:00 Uhr Donnerstags Ruhetag Tool 1: Mo-Su 10:00-01:00 Tool 2: Mo-Su 10:00-01:00; Th off Und damit kommen beide Tools komplett durcheinander: Montag Ruhetag Dienstag - Samstag 17:00 - Open End Sonn. und Feiertags 12:00 - 14:30 Uhr & 17:00 - Open End beste Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles Öffnungszeiten-Webtool
On 19.02.19 09:24, Stefan Keller wrote: > Fernziel ist u.a., den Tag "opening_hours:url" zu verwenden, um den > dort verlinkten Webinhalt in opening_hours zu wandeln. Finde ich eine spannende Vision, denn so könnten Änderungen bei den Öffnungszeiten viel schneller entdeckt werden. Für OSM ist zumindest in Europa die größte Herausforderung ja zunehmend das Aktualisieren (statt Ersterfassen) von Daten. > Feedback willkommen - hier oder als Issue im Repository! Meine einfachen bis mittelschwierigen Tests haben beide Implementierungen anstandslos geschluckt! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mitbetreuer für die Chemnitzer Linux-Tage gesucht
Man kann sicher eine menge von den fragen anderer lernen Originalnachricht Von: Pierre Goldenbogen Gesendet: Donnerstag, 3. Januar 2019 17:41 An: talk-de@openstreetmap.org Antwort an: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Mitbetreuer für die Chemnitzer Linux-Tage gesucht Da der Anmeldeschluss in zwei Tagen ist, benötige ich auch eine kurzfriste Zusage. https://wiki.openstreetmap.org/wiki/Chemnitzer_Linux-Tage_2019 Macht es Sinn, als totaler Anfänger mit zu machen? Ich mappe aktiv jetzt seit drei Wochen... - Pierre ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenbeschränkungen und ihre (fehlende) Darstellung
Hi, Auch wenn es wohl umsonst ist - mein kostenloser Tipp für dich im Umgang mit open source Projekten/communities: achte an mehr auf den Umgangston :-) eine ML oder ein forum ist sicherlich auch kein Raum in dem jeder ohne konsequenzen alles sagen kann was er will . Gruß Originalnachricht Von: sepp1...@posteo.de Gesendet: Donnerstag, 27. Dezember 2018 08:47 An: talk-de@openstreetmap.org Antwort an: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Höhenbeschränkungen und ihre (fehlende) Darstellung Moin, es tut mir aufrichtig leid, zwei positive Antworten als solche mit meinem Dank versehen als Beispiele zum Denkanstoß für einen Mitstreiter "mißbraucht" zu haben, dessen Antworten einen sachlichen Themenbezug vermissen lassen. Wird definitiv nicht wieder vorkommen! Zu den Themen selbst, beschleicht mich mittlerweile die Vermutung, dass auf breiter Linie fast nur geblockt und gemauert wird, als das sich sinnvolle Ideen umsetzen lassen würden. Jeder will pünktlich seine Pakete, jeder will volle Regale, jeder möchte möglichst ungehindete Fahrt auf "seinen" Wegen, aber die Bereitschaft od. Erkenntnis bereits vorhandene Informationen einfach nur sichtbar zu machen, tendiert gegen Null. Statt dessen wird auf Spezialkarten verwiesen, deren Existenz damit überflüssig gemacht wird und die tatsächlich nur schwer gefunden werden können. (ich habe die Suchmaschinen VOR meiner Anfrage mehrfach gequält, denn mir war die pure Existenz dieser Spezialkarten durchaus bekannt). Sowohl die Aussage, dass keine Verkehrszeichen gemappt werden, als auch die, das der Kartenstil "überfrachtet" wird, sind schlicht und ergreifend falsch. Ampeln SIND Verkehrszeichen und das Tor im Gartenzaun oder die Feuerstelle im Wald haben die gleiche Berechtigung wie ein ganz reales Nadelöhr aufgrund von Beschränkungen in den Abmessungen und/oder Gewichten, zumal es hierzu einen wesentlich größeren Interessenten- und Betroffenenkreis gibt, nämlich jedesmal dann, wenn ein Fahrzeug vor solch einer Höhenbeschränkung wenden darf und alle anderen deshalb im Stau stehen. Gruß Sepp PS: Ich habe oder fahre weder ein Wohnmobil oder Hochdachtransporter, noch einen Lkw und die am meisten präsente Nutzung von OSM bleibt auch auf lange Sicht trotz aller weiterführenden Versuche, die Darstellung der frei zugänglichen Weltkarte zum Routing. Am 26.12.2018 21:37 schrieb mmd: Kurzer Hinweis in eigener Sache: ich bin nicht damit einverstanden, dass meine Beiträge hier dazu benutzt werden, anderen Beitragenden eine bestimmte Form der Kommunikation nahezulegen oder in diesem Zusammenhang als Vorbild genannt werden. Bitte in Zukunft davon Abstand nehmen. Danke. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhenbeschränkungen und ihre (fehlende) Darstellung
+1 Originalnachricht Von: mmd Gesendet: Mittwoch, 26. Dezember 2018 21:37 An: talk-de@openstreetmap.org Antwort an: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Höhenbeschränkungen und ihre (fehlende) Darstellung Am 25.12.18 um 16:55 schrieb sepp1...@posteo.de: Dank Andreas und mmd habe ich Karten gefunden, die das darstellen - unkompliziert und ohne Theater - das wären m.M.n. brauchbare Vorbilder für zukünftige Antworten von Dir?! Kurzer Hinweis in eigener Sache: ich bin nicht damit einverstanden, dass meine Beiträge hier dazu benutzt werden, anderen Beitragenden eine bestimmte Form der Kommunikation nahezulegen oder in diesem Zusammenhang als Vorbild genannt werden. Bitte in Zukunft davon Abstand nehmen. Danke. -- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kandidatur für den OSMF-Vorstand
Hallo zusammen, ich habe dieses Wochenende erfahren, dass Peda (Peter Barth) aus dem Vorstand der OSMF ausscheiden und nicht erneut kandidieren wird. Peda hat aus meiner Sicht einiges erreicht, was das reibungslose Funktionieren unseres Projekts, die Transparenz der Arbeit des Boards (z.B. durch öffentliche Vorstandssitzungen und die Veröffentlichung von Abstimmungsergebnissen), das Bekenntnis zu freier Software und offenen Kommunikationsplattformen und nicht zuletzt die Vertretung der Interessen von ehrenamtlichen Mappern angeht. Ich glaube, dass Peda auch deshalb wertvoll für die Community war, weil er derzeit als einziges Boardmitglied keiner Firma oder humanitären Organisation mit geschäftlichen Interessen an OSM angehört. Für seine gute Arbeit möchte ich ihm hiermit herzlich danken! Da es mir wichtig ist, dass diese gute Arbeit auch in den kommenden Jahren fortgeführt werden kann, werde ich mich für den Vorstand der OSMF zur Wahl stellen. Ich bin in der OSMF seit 2009 Mitglied und auch in einigen OSMF-Arbeitsgruppen gelegentlich aktiv. Vor allem aber bin ich seit langem als Mapper und inzwischen auch als Hobby-Entwickler in der OSM-Community zu Gange. Auch aus dem Forum oder Wiki dürften mich einige von euch schon kennen. Ausführlichere Infos liefere ich später noch nach, auch über die offiziellen Kanäle: Es soll auch dieses Mal wieder Wahlprogramme sowie die Möglichkeit zum Einreichen von Fragen an die Kandidaten geben. Da die Vorstandswahl im deutschen Forum dank der fleißigen Mitgliederwerbung von Nakaner aber bereits Gesprächsthema ist, wollte ich den sprichwörtlichen Hut schon einmal in den Ring werfen. Und natürlich dürft ihr mich auch jetzt schon mit Vorschlägen, Kritik und Fragen löchern! Viele Grüße, Tobias ( Crossposting von https://forum.osm.org/viewtopic.php?id=64360 ) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie
Das kann man alles so stehen lassen
Generell würde ich mir wünschen dass wir die Möglichkeit beizutragen
nich unotig komplizieren... Ein paar verklebte Flächen können wir
sicher hinnehmen wenn wir dadurch einen neuen mapper gewinnen
können.
Originalnachricht
Von: Volker
Gesendet: Sonntag, 21. Oktober 2018 01:36
An: talk-de@openstreetmap.org
Antwort an: Openstreetmap allgemeines in Deutsch
Betreff: Re: [Talk-de] Androhung von Benutzersperren für Verklebe-Ideologie
+1
+ drei Ergänzungen
1. Auch wenn die Antworten auf Changesetkommentare teilweise
ziemlich patzig sind, sollte generell der Ton in
Changesetkommentaren, der tendenziell immer rauher wird, seitdem es
die Changesetkommentare gibt, wieder in Richtung Sachargumente und
Nettikette gehen.
2. Der Spass am "Rule lawering" sollte denjenigen, die es massiv
parktizieren, gründlichst vergellt werden.
3. Ich bin keine Freund davon irgendjemanden wegen Kleinigkeiten bei
der DWG zu verpetzen.
Am 20.10.2018 um 16:02 schrieb Frederik Ramm:
Hi,
On 10/19/2018 09:32 PM, Martin Koppenhoefer wrote:
kannst Du das spezifizieren? Wenn es ums Verkleben geht, soll man
neue Mapper freundlich begrüßen und höchstens in einem Nebensatz
das Verkleben ansprechen? Oder ist jeder Hinweis darauf verboten,
wenn es um Neulinge geht?
Also, ich würde mal sagen, man soll es generell unterlassen, in einer
Changeset-Diskussion Zeugs zu diskutieren, das mit der konkreten
Änderung nichts zu tun hat.
Ansonsten würde ich sagen, das *absichtliche* Verkleben von Flächen und
Wegen, die man selbst nicht neu gemappt hat, sollte nach wie vor
kritisiert werden dürfen.
Aber wenn jemand neue Daten beiträgt und dabei ein bisschen "klebt", ist
das noch kein Grund für eine freundliche und erst recht nicht für eine
unfreundliche Ermahnung. Und wenn jemand dann trotzdem solche
Changeset-Kommentare schreibt, und ein Dritter das merkt, dann soll der
sich bitte an die DWG wenden statt auch noch in die Diskussion
einzusteigen und den Verteidiger der Entrechteten zu spielen.
Und wer in dieser Aussage eine Lücke findet und meint, er könnte immer
noch seine verklebe-politischen Ideen pushen, indem er z.B. die Mapper
per persönlicher Nachricht anschreibt oder ihnen gefaltete Zettelchen
unter die Windschutzscheibe klebt ("Du hast ja nur von
Changeset-Diskussionen gesprochen"), der kriegt dafür auch nicht den
Innovations-Award - einigen der Spezialisten in der aktuellen Diskussion
scheint das sog. "rule lawyering" ausgesprochenen Spass zu bereiten.
Mittelfristig wäre es gut, wenn wir in dieser Sache zu einem Konsens im
Projekt oder zumindest mal in Deutschland kommen könnten. So schwer kann
das doch nicht sein?
Bye
Frederik
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Smoothness nur für Wege oder auch für Straßen
Am 12.10.2018 um 07:39 schrieb Volker Schmidt: Die Were des "smoothness" tag sind auf Autos bezogen, nicht auf Fahrräder, wenn du im wiki nachschaust. Sind dann aber von der user community auch für Radfahrer verwendet worden. In welchem Wiki schaust du denn? Im OSM-Wiki (und auch schon im Proposal) beziehen sich die wenigsten Beispiele auf Autos. In den beiden höchsten Klassen sind Autos noch nicht mal erwähnt. Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche C-Routine für Berechnung einer Peilung
Hoert sich intersant an was arbeitest du da? Originalnachricht Von: Andre Hinrichs Gesendet: Mittwoch, 10. Oktober 2018 21:38 An: talk-de@openstreetmap.org Antwort an: Openstreetmap allgemeines in Deutsch Betreff: [Talk-de] Suche C-Routine für Berechnung einer Peilung Hallo OSM-DE-Liste, ich suche für eine eigene Applikation eine Routine, die basierend auf einer Koordinate, einem Winkel und einer Entfernung sphärisch die Ziel-Koordinate berechnet. Dabei muss dies auch über größere Entfernungen funktionieren. Leider finde ich per Internet-Suche nur Tools, die dies feritg anbieten, oder Formeln, die nur eingeschränkt gültig sind, oder, oder... Da sich hier aber ja bestimmt auch Programmierer tummeln, habe ich die Hoffnung, dass mir jemand weiterhelfen kann. Eingangswerte sollen sein: Koordinaten-Paar, Winkel, Entfernung (in Metern) Ausgangs-Werte sollen sein: Koordinaten-Paar Obwohl meine Applikation in C geschrieben werden soll, kann ich auch Beispiele anderer Programmier-Sprachen gebrauchen... Danke schonmal für eure Hilfe Andre ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki-Eintrag falsch?
Am 05.10.2018 um 12:43 schrieb sepp1...@posteo.de: In D werden Brückenhöhen i.d.R. durch Zeichen 265 ab einer Durchfahrtshöhe von 4,20m gekennzeichnet, im Einzelfall auch ab einer höheren möglichen Durchfahrtshöhe, je nach (regelmäßiger) Straßennutzung durch Sondertransporte. Auch auf Autobahnen werden Brücken oft mit schräg zum darunter verlaufenden Straßennieveau sogar für einzelne Fahrspuren mit unterschiedlichen Höhenangaben unterhalb der 4,50m-Grenze kenntlich gemacht. Das müßte geändert werden, oder habe ich da etwas falsch interpretiert? Da müsste auf jeden Fall etwas geändert werden. Ist das mit Google Translate übersetzt? Ich habe die Feldinhalte drei mal gelesen und dann in die englische Version geschaut, um überhaupt zu verstehen, was die Tabelle eigentlich sagen will. Falls es ein 4,20m Default in DE gibt, kann man das gerne auch korrigieren, dann aber klar mit dieser DE-Einschränkung. Die Seite gilt ja prinzipiell global. Tobi ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abknickende Vorfahrt
Am 02.10.2018 um 16:09 schrieb Florian Lohoff: On Tue, Oct 02, 2018 at 12:29:51PM +0200, Tobias Wrede wrote: D.h. evtl. Geschwindigkeitsbeschränkungen müssen nach der Kurve neu gesetzt werden? Dieser Punkt ist unter Juristen tatsächlich umstritten, genauer die Frage, ob Strecken-Beschränkungen weiter gelten, ist umstritten. IIRC ist das Gerichtlich sauber geklärt. Eine Geschwindigkeitsbegrenzung gilt bis sie aufgehoben ist. [...] https://www.burhoff.de/rspr/texte/ab_00028.htm [...] "Es ist einhellige Meinung in Literatur und Rechtsprechung, dass eine durch Zeichen 274 angeordnete Geschwindigkeitsbeschränkung als sog. Streckenverbot erst an einen gemäß § 41 Abs. 2 Nr. 7 StVO aufgestellten Zeichen 278 endet (vgl. Hentschel, Straßenverkehrsrecht, 36. Aufl., § 3 StVO Rdnr. 46 m.w.Nachw.; Beschluss des Senats vom 8. Juli 1996, abgedr. in NZV 1996, 247). Zwar verlangt der Sichtbarkeitsgrundsatz die Wiederholung aller Streckenvorschriftszeichen hinter jeder Kreuzung oder Einmündung auf der Straßenseite, für die das Gebot oder Verbot besteht; dies gilt jedoch nur für den Einbiegeverkehr." Das ist unstrittig. Strittig ist, was die "Strecke" ist. Bei einer Kreuzung ohne abknickende Vorfahrt ist klar, dass die Strecke geradeaus weiterführt. Bei einer abknickenden Vorfahrt scheiden sich die Geister. Manche sagen, die Strecke endet dort (wie z. B. bei Einmündung auf eine T-Kreuzung), manche sagen, die Strecke führt geradeaus weiter und manche sagen schließlich, die Strecke folgt der Vorfahrtstraße. Dazu gib es so weit ich weiß keine Rechtssprechung. Tobi ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abknickende Vorfahrt
Am 02.10.2018 um 12:52 schrieb Martin Koppenhoefer: sent from a phone On 2. Oct 2018, at 12:29, Tobias Wrede wrote: Dieser Punkt ist unter Juristen tatsächlich umstritten, genauer die Frage, ob Strecken-Beschränkungen weiter gelten, ist umstritten. unumstritten ist eigentlich nur, dass man blinken muss, oder? Vor allem muss man auch querende Fußgänger durchlassen. Ein Aspekt, der vielen Autofahrern leider nicht bewusst ist. Gruß Tobi ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abknickende Vorfahrt
Hi Martin, Am 02.10.2018 um 12:11 schrieb Martin Koppenhoefer: Und auch für den rechtlichen Vorgang ist es - in Deutschland - immer noch ein Abbiegen. Mit all den Konsequenzen, die ein Abbiegen hat ein wenig sollte ich meine Aussage vielleicht relativieren. Die Regeln dazu sind nämlich nicht ganz eindeutig und es kommen teilweise auch unterschiedliche §§ in der StVO zur Anwendung, die das gleiche fordern. D.h. evtl. Geschwindigkeitsbeschränkungen müssen nach der Kurve neu gesetzt werden? Dieser Punkt ist unter Juristen tatsächlich umstritten, genauer die Frage, ob Strecken-Beschränkungen weiter gelten, ist umstritten. Gruß, Tobi ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abknickende Vorfahrt
Hallo in die Runde, Am 01.10.2018 um 15:49 schrieb Florian Lohoff: Hi Andreas, On Fri, Sep 28, 2018 at 09:06:07PM +0200, Andreas Schmidt wrote: Wenn man abbiegt, biegt man ab. Ob die Vorfahrtsstraße mit abbiegt oder geradeaus geht, ist für die Frage des Abbiegens irrelevant. Für den physischen Vorgang des abbiegens und Deutschland gebe ich dir recht. Und auch für den rechtlichen Vorgang ist es - in Deutschland - immer noch ein Abbiegen. Mit all den Konsequenzen, die ein Abbiegen hat, mit der Ausnahme, dass entgegenkommender Fahrzeugverkehr ggf. warten muss. Auf Fußgänger trifft das nicht zu. Festeinbau Mercedes - Keine Ansage - Erwartung das der abknickenden Vorfahrt gefolgt wird. Mercedes hat eh eingebaute Vorfahrt, oder wie war das? ;-) Hoffe, die Fahrer verlassen sich nicht leichtsinnig auf die Ansagen. Tobi ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-GB] Access restrictions for lorries above a certain GVM
Again, the max weight is not the same as the max allowable weight. Using maxweight in this context is wrong. See the Key:hgv wiki page where I added an explanation and examples. Am 27. September 2018 11:25:11 MESZ schrieb Ed Loach : >Tobias asked: > >> In United Kingdom, how do you tag roads signed with this sign? >> >> https://en.wikipedia.org/wiki/File:UK_traffic_sign_622.1A.svg > >Based on >https://wiki.openstreetmap.org/wiki/Conditional_restrictions > >I'd go with something like >access:hgv:conditional=no@(weight>7.5) >with added :forward or :backward if only signed at one end of a given >road. > >Ed ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Access restrictions for lorries above a certain GVM
Thank you for the answers given. Perhaps there are some misunderstandings, so I want to clarify two points: 1. A HGV is defined as a vehicle with a max allowable mass of above 3.5t, even in the UK. Tagging "hgv=no" when seeing this sign is plain incorrect, except if we specifically redefine only for OSM what constitutes a HGV contrary to what can be found in the actual legislation. I don't think it is wise to do that. 2. How HGV are defined (>3.5t) and what can be seen on signs like these (7.5t) is NOT THE WEIGHT but the maximum allowed weight. This is very important. The maximum allowed weight, also known as the gross vehicle mass or GVM or GVWR is the maximum permitted weight of the vehicle at full load, as specified by the manufacturer. (See https://en.wikipedia.org/wiki/Gross_vehicle_weight_rating) Just to be clear, an example. Let's say there is a lorry with the following properties on the road: - Without any load it weighs 2 tons -> this is the unladen/empty weight - It carries 4 tons of gravel -> this is the tara/load - It currently weighs 6.5 tons -> this is the current/actual weight. Used for maxweight=* - It could load up to 7 tons -> this is the maximum capacity - It is permitted to weigh in total up to 9 tons -> this is the maximum permitted/allowed weight/mass, aka gross vehicle mass, aka GVM - in other words, GVM = unladen weight + maximum capacity Thus, using maxweight=7.5 is incorrect already because the maxweight tag is about the maximum CURRENT weight. A HGV whose permitted maximum weight is above 7.5 tons but which currently weighs below 7.5 tons is not allowed on roads signed with the linked sign. So, these are the points I wanted to clarify. Also, turns out that someone else already noticed the exact problem and created a proposal for this, which seems kind of abondoned, as usual: https://wiki.openstreetmap.org/wiki/Proposed_features/gross_weight How can we get this proposal started again? Because, the only correct way to tag the sign initially posted here would be with maxweightrating:hgv=7.5 (if the proposal is unchanged) Greetings Tobias On 26/09/2018 13:35, Tobias Zwick wrote: > Hey there > > I can't believe this didn't come up before - or maybe it did but was not > documented in the wiki. > > In United Kingdom, how do you tag roads signed with this sign? > > https://en.wikipedia.org/wiki/File:UK_traffic_sign_622.1A.svg > > Note that the GVM for which the sign applies is given explicitly on the > sign, which is apparently always the case for any HGV-access-restriction > sign in the UK. > > In other words, you will never find a sign like this in the UK: > > https://commons.wikimedia.org/wiki/File:Nederlands_verkeersbord_C7.svg > > Greetings > Tobias > > P.S: GVM is gross vehicle mass > https://en.wikipedia.org/wiki/Gross_vehicle_weight_rating > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Access restrictions for lorries above a certain GVM
Hey there I can't believe this didn't come up before - or maybe it did but was not documented in the wiki. In United Kingdom, how do you tag roads signed with this sign? https://en.wikipedia.org/wiki/File:UK_traffic_sign_622.1A.svg Note that the GVM for which the sign applies is given explicitly on the sign, which is apparently always the case for any HGV-access-restriction sign in the UK. In other words, you will never find a sign like this in the UK: https://commons.wikimedia.org/wiki/File:Nederlands_verkeersbord_C7.svg Greetings Tobias P.S: GVM is gross vehicle mass https://en.wikipedia.org/wiki/Gross_vehicle_weight_rating ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-se] Vänern syns inte..
Vänern i Mapfactor Navigator syns inte. Fel på sjön eller appen? ___ Talk-se mailing list Talk-se@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-se
Re: [OSM-talk] OSM Wikibase is now live
On 23.09.2018 17:07, Christoph Hormann wrote: > If you'd now impose > technical constraints preventing mappers from documenting things that > do not match a certain ideal of structure would you would effectively > make the wiki unsuitable for its primary application and mappers would > need to set up a new place to document their tags. The content stored in Wikibase is editable by wiki users using a regular wiki account, same as with other wiki pages. Ultimately, this is simply a different implementation of the infoboxes that already exist on the wiki's key and tag pages. An implementation that will be easier to maintain and easier to parse for projects like Taginfo (which already parses today's infoboxes, but has to jump through a lot of hoops to do so). But it isn't any more restrictive than filling in the parameters of today's infobox. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM Wikibase is now live
On 23.09.2018 14:05, Michael Reichert wrote: > Currently, the search of the wiki is not really useful any more. Indeed, the search field is pretty much broken at the moment. However, this has been brought up on the wiki talk page, and Yuri said he was looking for a fix. So I think it's safe to say that this is not intended behavior, at least. > I suspect that the attempts for more structured metadata won't be really > accepted by the community (the editors of the wiki). As one of the more active editors of the wiki, I'm very hopeful for this project. The current "solution" for this kind of data is to manually copy templates across several pages. This is a massive pain point and leads to pages unintentionally getting out of sync all the time. Of course, it's still too early to say whether the idea will work out. But I'm willing to help it succeed. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Relation für Gebäude
Am 18.09.2018, 16:21, schrieb Benedikt Bastin: > Gibt es abseits des Zugehörigkeitsproblems noch weitere Sachen, die gegen > eine solche Relation sprechen? Im Allgemeinen tendiert der Konsens in der Community dahin, Relationen nur dort zu verwenden, wo sie notwendig sind. Aus diesem Grund ist auch in Simple Indoor Tagging anders als bei dem von dir verlinkten älteren Indoor-Proposal vorgesehen, dass der Gebäudeumriss + level-Tags an den enthaltenen Elementen für die Zuordnung zum Gebäude ausreichen soll. Einen sehr ähnlich gelagerten Fall gibt es übrigens bei 3D-Gebäudemapping: Auch dort ist die Nutzung von Relationen zur Zuordnung von Gebäudeteilen zum Gesamtgebäude in den allermeisten Fällen optional¹ und unüblich – die weit überwiegende Mehrheit der 3D-Gebäude verzichtet darauf. Wenn du dennoch eine Relation verwenden willst, dann ist die building-Relation die gängigste Wahl. Ich würde aber wie gesagt eher davon abraten. Auch eine geringere Fehleranfälligkeit von Relationen halte ich in der Praxis nämlich nicht für gegeben: Es ist einfach zu schnell passiert, dass ein Mapper z.B. ein neues Objekt ergänzt, es aber nicht zur Relation hinzufügt. ¹ Ausnahme ist die Klärung von Zuordnungsproblemen bei überlappenden Gebäudeumrissen ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Need some help regarding GSOC
Hello Vasu, thank you for your interest in participating in Google Summer of Code at OpenStreetMap! On 13.09.2018 20:30, vasu dev Singh wrote: > I want > to do a project with OpenStreetMap but I don’t know how to start. One trait we're looking for in GSoC students is familiarity with the OSM community. So at this point, it might not be a bad idea to do some mapping in your local area, to explore the ecosystem of OSM-based software, and so on. In 2019 (assuming OSM will be selected as a mentoring organization), we will publish a list of project ideas, much as we did this year. At that point, you will be able to get in contact with the mentor(s) of the specific ideas you are interested in, who may be able to suggest some preparations more closely related to the development project in question. Of course, you can also get in contact with developers directly if you already know that you're interested in a particular open source project under the OSM umbrella. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Wie nennt man diese geo-statistische Funktion
On August 27, 2018 12:39:40 PM GMT+02:00, Tom Pfeifer wrote: >Markus, meinst du Isochronen? Das ist die Visualisierung, welche Orte >mit einem bestimmten >Reisemodus in gleicher Zeit erreichbar sind. >https://wiki.openstreetmap.org/wiki/Isochrone Das klingt wohl nach dem, wonach Markus gefragt hat. >Tobias, ist das eine Implementierung von Skoda selbst oder von dir >selbst? Das ist ein Bordmittel von Skoda; "GreenScore" ist da IIRC das Stichwort. -towo -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie nennt man diese geo-statistische Funktion
On August 27, 2018 8:47:05 AM GMT+02:00, Markus wrote: >Wie heisst die entsprechende Funktion? >(sowas wie "Dominanz" bei Gebirgen) In der Graphentheorie nennen wir das einfach nur "kürzester Pfad/Weg"-Probleme, aber das ist in der Umgangssprache etwas misverständlich, da das "kürzeste" sich nicht eindeutig auf Strecke oder Zeit bezieht, sondern welche Metrik man auch immer gerade anwenden will. Navis implementieren das dann üblicherweise mit einer Gewichtung nach Entfernung oder nach Fahrzeit. (Mein Skoda versucht ein Mapping nach ökologischer Auswirkung auf Basis einer selbstentwickelten Kostenfunktion.) -towo -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Barrier=block areas
On 15.08.2018 20:49, Tomasz Wójcik wrote: > Currently, barrier=block is not allowed to be mapped as an area. As > blocks can be big enough to map them as areas, I think it should be > allowed, the same as in barrier=wall or barrier=hedge. For routing purposes, barriers are usually connected to the highway=* way somehow. When barriers are mapped as nodes, this is achieved by tagging one of the way's nodes with the barrier tags. How would we do this for barrier=block mapped as areas? Note that the block(s) will not always be exactly on the centerline of the highway, so we may not be able to even share a node between the area outline and the highway way if we want to accurately represent the area covered by the block. Due to this, I see no easy solution to map blocks as areas while still making them topologically part of the routing network. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=* + area=yes vs area:highway=*
On 08.08.2018 12:49, Tomasz Wójcik wrote: > Due to our rules, that we shouldn't have 2 active tagging > schemes for the same feature These tagging schemes are for 2 different real-world features: * roads/paths (i.e. linear features with a direction) * plazas/squares (i.e. open areas where people will walk across in all directions) Linear roads/paths are mapped as highway=* ways, optionally with an additional area:highway=* polygon. Plazas/squares are mapped as highway=* + area=yes polygons. So the area:highway key is never an alternative to highway polygons with area=yes! In any given situation, only one or the other will be correct. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[Talk-de] building:levels, Altbau/Neubau
On 22.07.2018 17:00, Frederik Ramm wrote:> wenn man building:levels erfasst - das ist ja doch ein bisschen > einfacher als eine echte Höhenmessung - macht es ja einen ziemlichen > Unterschied, ob man es mit einem Altbau-Stadthaus mit 3,50m hohen > Stockwerken zu tun hat oder mit einem Neubau mit nur 2,40. Sollte man > das irgendwie mit erfassen? Ich stimme zu, dass es einen Unterschied macht. Schöne Tagging-Lösungen kenne ich allerdings nicht. Wenn man das erfassen will, bleibt einem derzeit nur, das Ergebnis der Überschlagsrechnung als height-Tag am Gebäude zu hinterlegen. Im Prinzip könnte ein Renderer natürlich abhängig von building:architecture, start_date oder ähnlichen Schlüsseln unterschiedliche Default-Stockwerkhöhen annehmen. Allerdings weiß ich bisher von keinem 3D-Renderer, der das tut. > Ausserdem haben Gebäude in der Stadt oft so ein "Hochpaterre" (?), wo > das Erdgeschoss nicht auf Straßenniveau ist, sondern einen halben Meter > drüber. building:levels=3.5? Das ist ein häufiger genanntes Problem, für das es meines Wissens ebenfalls noch keine Lösung gibt – Interesse hätte ich und würde das z.B. auch in OSM2World gerne einbauen. Nicht ganzzahlige building:levels-Werte sind leider nicht gut auszuwerten, weil man nicht weiß, _wo_ am Gebäude das halbe Stockwerk ist. Das ist für die reine Höhenschätzung kein Problem, wohl aber wenn man z.B. Fensterreihen einzeichnen oder Indoor-Mapping ins Gebäudemodell einpassen will. Theoretisch gäbe es sogar eine Lösung unter Verwendung von bestehenden Tags, nämlich Simple Indoor Tagging: Man kann eine Fläche fürs Erdgeschoss einzeichnen (indoor=level + level=0) und mit min_height=0.5 taggen. Aber eigentlich sollte ein so häufiger Fall einfacher abzubilden sein, vor allem ohne den Pflegeaufwand von zusätzlicher Geometrie... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Should StreetComplete stop adding addresses in Italy?
Hey Alright, so from the responses I got here, I detected a tendency to say that the quest type should be disabled in Italy, so I will do this for the next version of StreetComplete. As far as I understood, the other thread (Nomi delle strade e numeri civici) was rather about the address on POIs of amenities/shops etc. Cheers Tobias On 12/07/2018 20:33, Tobias Zwick wrote: > Hey there > > Since early 2017 till now, users of my app StreetComplete have been > adding house numbers to buildings. > Should I disable this functionality for Italy? > > For buildings of certain types, such as "apartments" or "house"s etc. > (but not "yes"), which do neither have an address tagged, nor have any > node on or in their outline with an address tagged, nor are in any area > that has an address tagged, the app shows a pin on the map, like this: > > https://raw.githubusercontent.com/westnordost/StreetComplete/master/fastlane/metadata/android/en/images/phoneScreenshots/screenshot8.png > > This pin is shown to every user of the app, until it is solved. To solve > it, the user taps on the pin and can input the housenumber for the > building in the form that pops up then. The user can also answer that > the building has no housenumber, in which case the app tags noaddress=yes. > > Cheers > Tobias > > - > > Addresses in Italy are described here in the wiki: > https://wiki.openstreetmap.org/wiki/IT:Addresses#Regole_specifiche_per_l.27Italia > > A related discussion on talk-it is archived here: > https://lists.openstreetmap.org/pipermail/talk-it/2018-January/061775.html > > ___ > Talk-it mailing list > Talk-it@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-it > ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Should StreetComplete stop adding addresses in Italy?
Hmm, I was hoping for a more definite answer than what I got from this thread so far. I will give you some more input. Regarding the ideas expressed so far: Adding a node within the building with the housenumber is not possible, because StreetComplete can only change the tags of an element, neither add, delete or change the geometry of elements - but it doesn't matter really if there is a node with an address within the building with a fixme-tag or the address is just on the building: It requires cleanup to conform to the Italian address guidelines in either case. Also, a detection whether a housenumber is "nearby" specifically for Italy is also something I will not do, because such a detection would be too fuzzy to be reliable. But it needs to be reliable. Finally, regarding the idea to let StreetComplete ask for the addresses on gates and entrances instead of buildings in Italy, that would create lots of false-positives (not every gate or entrance has an address). I think if the building is already mapped in such a detail that the entrances are also mapped, someone must have been there to survey it and then he will have also specified the housenumber (if that entrance has one). To summarize, I see no chance how StreetComplete, or for that matter, any automatic algorithm, would be able to automatically determine where and which housenumbers are missing on the map, when housenumbers are mapped on plot boundaries instead of always on, in or at the entrances of buildings. --- Certainly, StreetComplete can be very useful in filling the white spots regarding addresses in Italy, and it is true that as OSM is a collaborative project, other mappers can later separate the address from the building outline and put it on the entrance(s) to make it conform to the guidelines. Also, most (inner-)town buildings will have their address on the entrances and many buildings just have one entrance, so there is no problem. However, you also have to consider that StreetComplete will definitely be a disruption in areas where the address is commonly (mapped) at the gates leading to the properties (=outside the building outline). In these areas, the buildings may be spammed with either duplicate housenumbers or noaddress=yes tags. Worse still, if you clean up the duplicated nodes after a StreetComplete user added them, they may appear again later, when another user adds them again, and so on. So, you have to weigh the these up against each other and decide. Anyway, thank you for the praise :-) Tobias On 13/07/2018 10:55, mbranco wrote: > I think that it should be fine if your app could put a node inside the > building (at the center?) with the housenumber, and maybe with a fixme "move > me at at the access of this building". > Being OSM a collaborative project which works with subsequent refinements, > someone later could set the exact position. > > But I'm afraid that it's not easy to detect if the housenumber is already > set (is already there a node "near or inside" the building with the > housenumber?) > > P.S. However, thank you Tobias for your great app, I think it's a valuable > tool to bring newbies to OSM. > > > > -- > Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html > > ___ > Talk-it mailing list > Talk-it@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-it > ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Should StreetComplete stop adding addresses in Italy?
Hey there Since early 2017 till now, users of my app StreetComplete have been adding house numbers to buildings. Should I disable this functionality for Italy? For buildings of certain types, such as "apartments" or "house"s etc. (but not "yes"), which do neither have an address tagged, nor have any node on or in their outline with an address tagged, nor are in any area that has an address tagged, the app shows a pin on the map, like this: https://raw.githubusercontent.com/westnordost/StreetComplete/master/fastlane/metadata/android/en/images/phoneScreenshots/screenshot8.png This pin is shown to every user of the app, until it is solved. To solve it, the user taps on the pin and can input the housenumber for the building in the form that pops up then. The user can also answer that the building has no housenumber, in which case the app tags noaddress=yes. Cheers Tobias - Addresses in Italy are described here in the wiki: https://wiki.openstreetmap.org/wiki/IT:Addresses#Regole_specifiche_per_l.27Italia A related discussion on talk-it is archived here: https://lists.openstreetmap.org/pipermail/talk-it/2018-January/061775.html ___ Talk-it mailing list Talk-it@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-it
Re: [OSM-talk] proposed mechanical edit - moving FIXME=* to fixme=*
On 03.07.2018 10:28, Frederik Ramm wrote: > Don't forget that new FIXMEs will continue to appear all the time. They will, but at a lower rate. Mappers often look at existing tagging to find out how things should be tagged. This is further reinforced by tools such as JOSM's autocompletion. Thus, I believe the current dataset should always be as.clean as possible in order to set a good example. Mostly eliminating the FIXME spelling now (instead of waiting for it to disappear naturally over the next decade) will also allow us to simplify the wiki documentation a little bit, get rid of special cases in tools and so on. That may only be a small benefit, but it's the sum of all these small exceptions, duplications and special cases that make learning the OSM data model unnecessarily hard for mappers and data consumers alike. > Software should be able to deal with both. In my opinion, software should not _need_ to deal with both. Working around easily fixed database quality issues is a waste of time. Especially when there's even a volunteer eager to fix these quality issues! ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Zerstörtes Gebäude (demolished) einzeichen (Schild verweist auf Standort)
Hallo, ganz korrekt ist der Eintrag in meinen Augen nicht. Generell würde ich tendieren ihn bestehenzulassen. Allerdings passen die Tags in meinen Augen nicht zusammen. razed:man_made=watermill -> Eine Wassermühle, die "razed" ist. historic=watermill -> undokumentiertes Tag, das aber das gleiche aussagt wie man_made=watermill, diesmal aber ohne lifecycle prefix. demolished=yes -> auch kein dokumentiertes Tag, oder? Sollte wie oben razed: als Prefix demolished: genutzt werden. Steht jetzt im Widerspruch zu razed:. Aus den drei Tags sollte meiner Meinung nach genau eins werden: razed:man_made=watermill (oder demolished:man_made=watermill, der Unterschied ist nicht wirklich scharf und nachvollziehbar) Mann könnte sogar auch noch ein razed:building=yes ergänzen, wenn es sich hier nicht um eine offene Mühle gehandelt hat. Wenn man den Standpunkt vertritt, ein nicht mehr vorhandenes und inzwischen überbautes Objekt sollte gar nicht in der Karte auftauchen, kann man das ganze sicherlich auch in place=locality ändern. Tobias Am 17.06.2018 um 17:19 schrieb Manuel Reimer: Hallo, da bei uns recht ordentlich erfasst ist, habe ich direkt am Wohnort schon einige Zeit keine Änderungen mehr an der Karte gemacht. Vor wenigen Tagen habe ich aber mal geschaut was für Kartenfehler gemeldet sind. Dabei bin ich auf folgenden gestoßen: https://www.openstreetmap.org/note/1197712#map=17/49.97016/9.64038=N Erfasst hatte ich den mit/für den lokalen Heimat- und Geschichtsverein. Die Mühle ist in zahlreichen Flyern erwähnt und im "lokalen Sprachgebrauch" durchaus noch üblich. https://www.openstreetmap.org/node/1028449854#map=17/49.9705928/9.6378074layers=N Ich war bisher der Meinung das alles korrekt eingetragen zu haben. Das Abrissdatum ist drin, es ist explizit darauf hingewiesen, dass das Gebäude abgerissen wurde. Im Gegensatz zu so manchem erfassten "abgerissenen" Gebäude ist in gewissem Maß sogar das Gebot "nur mappen was vor Ort nachvollzogen werden kann" gewahrt. Eine Tafel vom Spessartbund (hier verläuft ein Kulturweg, der auch mehrfach auf die Mühlen hinweist) verweist auf den Standort. Kann also für jeden nachvollzogen werden auch ohne "Ortskundige" zu fragen. Hintergrund für das Anlegen des Knotens war, dass ich gerne einen Eintrag dafür hier haben wollte: http://gk.historic.place/historische_objekte/translate/en/index-en.html?zoom=17=49.96999=9.63967=HaHbHcSaHe Steht da auch korrekt als "former watermill location". Weiterhin nutze ich den Knoten auf der Karte des Heimat- und Geschichtsvereins um Infos zum (ehemaligen) Gebäude auf die Karte zu packen: http://karte.hgv-steinfeld.de/ Wie ist die Meinung hier dazu. Wenn es komplett falsch ist, sowas zu mappen, dann kann ich das mit meiner Karte auch anders lösen. Ich selber tendiere aktuell dazu den Fehler mit einem Hinweis auf die Tafel, die auf den Standort des ursprünglichen Gebäudes hinweist, zu schließen. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] proposed mechanical edit - moving building=building to building=yes
On 08.06.2018 19:19, Mateusz Konieczny wrote: > building=building is an unexpected way to mark building without > specifying its type and therefore retagging this duplicate to > building=yes would improve tagging without any information loss. I'm in favour of proceeding with the proposed mechanical edit. The tag change in question is doubtlessly an improvement, and the plans are thoroughly documented. :) ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - Feedback and ideas wanted
Hi Tim, On 16.05.2018 10:16, Tim Frey wrote: > I like the Wikipedia and in special the Wikivoyage direction also. Does > somebody know the best touchpoints to get in contact with the community > there? I'm not familiar enough with their communities to give a recommendation. However, Commons does "partnerships" with owners/maintainers of media collections: https://commons.wikimedia.org/wiki/Commons:Partnerships You could give the contact listed there a try. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - Feedback and ideas wanted
Hi Tim, On 11.05.2018 17:19, Tim Frey wrote: > Out of this, we consider, heavily, to “open source” the licensing of the > user created STAPPZ content for the OSM community. In addition, we also > consider to open source the backend of STAPPZ and the IOS and Android > app to make a community project out of it. I'm going to split this reply into two parts: About the content, and about the software itself. As for the content, a lot depends on if you can publish the images under the terms of an open license.¹ That's a legal question, but probably also a bit of a social one (i.e. would this be in line with what the creators expected when they shared their images on your app, or would they be unpleasantly surprised/unhappy about this). Assuming the answer is that yes, you can publish them, the next question is what to do with the images. OSM does not currently have an image hosting platform, so if we're only talking about contributing the images, they would need to be donated to a separate platform. The obvious recipient for such an image donation would be Wikimedia Commons, as they're the most popular repository for open-licensed media. Images on Commons can be linked with OpenStreetMap POIs² and are used as such by some OSM-based maps. Of course, they're also used by Wikipedia and its sister projects – notably Wikitravel, which is a crowdsourced travel guide (although much closer to the traditional book format than your project). A caveat is that such a donation would likely require some manual effort to filter out lower-quality pictures or duplicates, and to add meaningful descriptions. Still, assuming the legalities work out, it seems feasible to donate the images and would be a generous contribution to the open content ecosystem. Ok, so let's talk about the app and backend a bit. I'm not sure how familiar you are with OSM's organizational model, but as a rule we're very decentralized – even core components of OSM are being developed as mostly independent Open Source projects. For you, this means that even if there's community interest, any re-use of your project would probably still start out with _you_ spearheading its development, re-imagining it as something you believe fits a need of the OSM community, and trying to gain mindshare in the OSM contributor and developer community. Of course, this may be at odds with your goal to focus on other projects. If this does not discourage you, though, let's consider what needs the software could serve. I don't have any amazing ideas to offer, but I could see two basic roles in the OSM ecosystem an image platform might potentially be able to fill. Broadly speaking: * Images could be used internally by OSM contributors as a data source for mapping in addition to sources as aerial imagery and GPS tracks. * Images could be displayed by user-facing sites and apps alongside OSM data. (I believe this is what you were getting at with your Google Maps comparison.) The former use case is already partially covered by Mapillary/OpenStreetCam, so the question is if there's enough of a niche left for another app. The latter seems more ambitious. As I mentioned before, mappers are currently using tags like image=* with links to external platforms to add images to OSM POI. Those links can technically point anywhere, although Wikimedia Commons currently appears to be the most popular platform to host the images. Inviting users (including non-mappers) to easily contribute images to a dedicated, OSM-affiliated platform might be a worthwhile cause. Not sure how well this fits your platform's existing social features, though. Tobias ¹ Typically one of the open CC licenses: CC0, CC-BY or CC-BY-SA. ² Using http://wiki.osm.org/Key:image or http://wiki.osm.org/Key:wikimedia_commons ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?
Hey Phil The quest pin is still in your application's cache. The app downloaded the quest more than 8 months ago. In any case, no need to worry. In case you solve a quest that turns out to be outdated (=there is a conflict with actual data), it will discard that answer and invalidate the cache of the area. You can manually invalidate the cache in the settings. For more information, see here: https://wiki.openstreetmap.org/wiki/StreetComplete/FAQ#How_does_the_app_handle_uploads.3F Cheers Tobias On 02/05/2018 13:58, Philip Barnes wrote: > Tobias > A quick question on speedlimit quests in Street Complete. I have > attached a screenshot of an area showing some missing speed limits. > > The problem is they are mapped, for example Bynner Street > https://www.openstreetmap.org/way/48394860 > > Cheers Phil (trigpoint) > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?
Also, 6. Did you come up with the term "restricted" or is the term actually used within the same context as single / dual carriageway in the UK legislation? Because, that term is usually used for quite another thing in OSM context (restricted access roads). But, as long as the nsl_* taggings in themselves are consistent (in that they use the terms from the UK legislation), that's fine, I guess. Otherwise, we should perhaps look for a more fitting name before I cast it into code. Tobias On 01/05/2018 20:19, Jason Cunningham wrote: > I had a bit of an interest in tagging speed limits a few years back. > It's way more complicated than it should be in the UK. Researching led > me down a bit of a rabbit hole of legislation & case law. > > I made the following personal notes about UK limits and how to recognise > them, which I think is mostly correct. > https://wiki.openstreetmap.org/wiki/User:Jamicu/UK_Speed_Limits > > I personally tagged restricted roads as maxspeed:type=UK:nsl_restricted > > All a bit of a mess though. > > Jason > > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?
So then, in case the user answers in the app that there is no sign, the app could ask the user whether the street is lit. Only if it is not lit, it tags the street as nsl_single/nsl_dual. Would that solution be correct? On 01/05/2018 19:22, Philip Barnes wrote: > On Tue, 2018-05-01 at 18:42 +0200, Tobias Zwick wrote: >> Does the "there are no repeater signs" rule only apply for the >> default >> 30 mph limit (and the 20 mph zones)? Or in other words, if there is >> an >> explicit different limit posted, let's say 40 mph, does it have to be >> repeated at each intersection and feed roads? >> > It applies for 30 mph limits where there is street lighting, I have > never come across an unlit 20 mph zone. > > If there is no street lighting the National Speed Limit applies, unless > there are repeater signs. Hence you will find 30 mph repeater signs in > unlit 30 mph limits. > > Repeaters are spaced at an regular intervals (up to about 400m), there > is no connection with junctions. > > If a NSL road is lit, then that will need repeaters (not motorways). > > All 40/50mph roads need repeaters, unless the limit is very short. > > An example of a 30 mph repeater. > https://www.mapillary.com/map/im/cQ-aZU75WoEDEr72_gj4xA > > Phil (trigpoint) > > > > > > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?
Does the "there are no repeater signs" rule only apply for the default 30 mph limit (and the 20 mph zones)? Or in other words, if there is an explicit different limit posted, let's say 40 mph, does it have to be repeated at each intersection and feed roads? Tobias On 01/05/2018 16:35, Philip Barnes wrote: > > > On 1 May 2018 10:41:28 BST, Tobias Zwick <o...@westnordost.de> wrote: > >> This is where I need your help. How should the dialog be changed (in >> GB) >> to not create any misunderstandings here? >> > Difficult without having seen the speed limit signs as you have entered the > zone. > > My usual approach is to survey the change points, split the ways at those > points. Often the limit change is painted on the road so can be seen on > imagery. > > 20 limits are likely to exist in the centre and close to schools, so those > areas need survey to check. If in doubt leave the limit unmapped. > > The radial roads are the usual start point for mapping speed limits, these > are where the transitions usually occur and are where the 40 zones are found. > In cities it is rare to find a direct 30 to NSL change. > > If a road is has no speed limit sign it will inherit the speed limit from its > feed road, which if that has been mapped makes it easy. > > In the case of short limits where a road passes through a small village you > need to be able to split the way at the zone transitions otherwise you will > end up tagging the entire way. > > Phil (trigpoint) > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?
Did you read my last paragraph? Could you respond also to that? On 01/05/2018 13:23, David Woolley wrote: > Two or three years ago, we had problem of lots of bogus "wrong speed > limit" notes being added by one particular app. The general result ws > that no-one took any notice of the notes from that app. More recently, > we have had problems from maps.me, although possibly not for speed limits. > > I think it can be quite dangerous to give people apps that fix or note > particular problems to people who don't know how to map using the more > general tools. > > I don't know about your tool, but it is essential that every user has an > explicit personal account with OSM, and that they are set up to receive > emails if people add changeset comments, or post messages to their OSM > account. maps.me has a high incidence of people who seem not to notice > changeset comments. > > On 01/05/18 10:41, Tobias Zwick wrote: >> I am quite sure that this problem can lead to wrong tagging, >> specifically that normal urban roads, even residential ones, are tagged >> with "maxspeed:type=nsl_single" when they should not. > > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?
This tag is not invented, it exists in other countries where slow zones exist as well. Also, there *is* something special about it, otherwise the sign would not be different from a normal maxspeed sign, wouldn't it? (And the wikipedia article wouldn't exist) The special thing about it, is that the posted maxspeed is valid for the whole zone, in other words, until the maxspeed zone is explicitly posted to be over. No repeater signs on crossroads and not even for adjacent streets. Yes, there is a certain similarity with the "normal" 30 mph limit in the UK, that is why I mentioned "maxspeed:type=GB:zone30" in my original post. Remember that OSM is a worldwide project, as long as something is not the same in the whole world, it is not "normal". Tobias On 01/05/2018 11:16, Philip Barnes wrote: > I wouldn't invent a type tag, it's maxspeed = 20 mph because that's what > the sign says. There is nothing special about these areas. > > Phil (trigpoint) > > > On 1 May 2018 09:58:23 BST, Tobias Zwick <o...@westnordost.de> wrote: > > Regarding the 20mph zones > (see https://en.wikipedia.org/wiki/30_km/h_zone), analogous to other > countries where they exist, they would be tagged as > maxspeed:type=GB:zone20. > > On 30/04/2018 20:57, Philip Barnes wrote: > > Whilst in theory there is an implicit 30mph when street lights are > present and there are no repeater signs indicating a higher > limit then > the speed limit is 30 mph. It has nothing to do with urban, the same > rule will apply on lit rural roads. These days it is complicated by > 20mph limits which also have no repeaters. > > That is the theory, however in over 40 years of driving and even > longer > cycling I have never come across an unsigned 30mph limit. It is > always > signed as you enter the zone. Whilst it's useful for > confirmation whilst > driving, it is not really useful for mapping, you need to survey the > start points so that it can be split at the appropriate points. > > Phil (trigpoint) > > > On 30 April 2018 18:41:26 BST, Tobias Zwick <o...@westnordost.de> > wrote: > > Hi there > > On tagging implicit speed limits in the United Kingdom, the wiki > lists > the following values [1] for "maxspeed:type": > > GB:nsl_single (=60 mph), GB:nsl_dual (=70 mph) and GB:motorway > (=70 mph) > > I understand that the current legislation defines a road with > road-lighting as a built-up area in which a lower implicit speed > limit > of 30 mph applies. There is no mention of it in the wiki, no > GB:urban, > GB:lit, GB:zone30 or anything like that, so something should be > defined > and documented by (you,) the British OSM community. > > My question: > How to tag roads in which such an implicit speed limit for built-up > areas applies? > > The question is motivated by an issue report for StreetComplete [2] > > Cheers > Tobias > > [1] > > https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table > > [2] https://github.com/westnordost/StreetComplete/issues/1037 > > > > > > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?
Okay, I have the impression that the tenor of the answers I got so far is that a "maxspeed:type=GB:something" tagging would not be necessary because in practice in the UK, any 30mph limit on lit streets will be posted explicitly. Thus, the maxspeed should be specified explicitly (along with "maxspeed:type=sign"). To those who find I summed up their opinion on that matter correctly, I would like to confront you with an actual problem I encountered with the surveyor-app StreetComplete of which I am the author of. I linked the ticket to this issue in my original post. I am quite sure that this problem can lead to wrong tagging, specifically that normal urban roads, even residential ones, are tagged with "maxspeed:type=nsl_single" when they should not. So I very much want to solve this problem as soon as possible and I am hoping you can help to find a solution to it and/or understand my point of view that *some* "maxspeed:type" or similar tagging might be necessary. I will now explain how this mistagging might come about in the dialogue of the user with the app: The app shows the street section which it is about highlighted and asks: *"What is the speed limit sign for this street?"* The user can then either fill in an explicit speed limit or answer "There is no sign". So, in case the user does not see any sign, as he would on a typical British urban street, he answers: *"There is no sign"* The app asks: *"Are you sure no limit is posted? Did you check at the ends of the street? If there are no signs along the whole street which apply for the highlighted section, default speed limits apply."* ...and in case of a road tagged as residential, it shows a slow-zone sign and adds: *"If there is a sign like this at the main street intersection, you won't find individual signs within the zone because the speed limit posted there applies to the whole zone."* When the user answers *"Yes, no sign"*, the app just asks (for GB): *"Are the carriageways of this road here physically separated (i.e. through a barrier)? The default speed limit depends on whether this is the case or not."* The app then tags "maxspeed:type=nsl_single" or "maxspeed:type=nsl_dual" based on the user's answer. So, if I understand correctly, this "default 30mph limit" within lit sections of British roads is always signed, yes, but otherwise behave like 20mph zones in that there are no repeater signs at intersections and *not even* in roads that branch of this main road and roads that branch of the branched off roads (right?). This would mean, that in Britain, it is not enough to tell the user to look for a sign at the start of the road, but to, well, what exactly? This is where I need your help. How should the dialog be changed (in GB) to not create any misunderstandings here? Tobias On 30/04/2018 19:41, Tobias Zwick wrote: > Hi there > > On tagging implicit speed limits in the United Kingdom, the wiki lists > the following values [1] for "maxspeed:type": > > GB:nsl_single (=60 mph), GB:nsl_dual (=70 mph) and GB:motorway (=70 mph) > > I understand that the current legislation defines a road with > road-lighting as a built-up area in which a lower implicit speed limit > of 30 mph applies. There is no mention of it in the wiki, no GB:urban, > GB:lit, GB:zone30 or anything like that, so something should be defined > and documented by (you,) the British OSM community. > > My question: > How to tag roads in which such an implicit speed limit for built-up > areas applies? > > The question is motivated by an issue report for StreetComplete [2] > > Cheers > Tobias > > [1] > https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table > > [2] https://github.com/westnordost/StreetComplete/issues/1037 > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?
Regarding the 20mph zones (see https://en.wikipedia.org/wiki/30_km/h_zone), analogous to other countries where they exist, they would be tagged as maxspeed:type=GB:zone20. On 30/04/2018 20:57, Philip Barnes wrote: > Whilst in theory there is an implicit 30mph when street lights are > present and there are no repeater signs indicating a higher limit then > the speed limit is 30 mph. It has nothing to do with urban, the same > rule will apply on lit rural roads. These days it is complicated by > 20mph limits which also have no repeaters. > > That is the theory, however in over 40 years of driving and even longer > cycling I have never come across an unsigned 30mph limit. It is always > signed as you enter the zone. Whilst it's useful for confirmation whilst > driving, it is not really useful for mapping, you need to survey the > start points so that it can be split at the appropriate points. > > Phil (trigpoint) > > > On 30 April 2018 18:41:26 BST, Tobias Zwick <o...@westnordost.de> wrote: > > Hi there > > On tagging implicit speed limits in the United Kingdom, the wiki lists > the following values [1] for "maxspeed:type": > > GB:nsl_single (=60 mph), GB:nsl_dual (=70 mph) and GB:motorway (=70 mph) > > I understand that the current legislation defines a road with > road-lighting as a built-up area in which a lower implicit speed limit > of 30 mph applies. There is no mention of it in the wiki, no GB:urban, > GB:lit, GB:zone30 or anything like that, so something should be defined > and documented by (you,) the British OSM community. > > My question: > How to tag roads in which such an implicit speed limit for built-up > areas applies? > > The question is motivated by an issue report for StreetComplete [2] > > Cheers > Tobias > > [1] > > https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table > > [2] https://github.com/westnordost/StreetComplete/issues/1037 > > > > Talk-GB mailing list > Talk-GB@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-gb > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] Implicit speed limits: What to tag in built-up areas?
I apologize for the misunderstanding, this is about implicit speed limits when there is *no sign* that ordains another speed limit, of course. Cheers Tobias On 30/04/2018 20:50, Brian Prangle wrote: > You can't make that assumption of an implicit 30mph limit. Major roads > in in built up areas can be 40 mph and increasingly speed limits are > being reduced to 20mph in built up areas > > Regards > > Brian > > On 30 April 2018 at 18:41, Tobias Zwick <o...@westnordost.de > <mailto:o...@westnordost.de>> wrote: > > Hi there > > On tagging implicit speed limits in the United Kingdom, the wiki lists > the following values [1] for "maxspeed:type": > > GB:nsl_single (=60 mph), GB:nsl_dual (=70 mph) and GB:motorway (=70 mph) > > I understand that the current legislation defines a road with > road-lighting as a built-up area in which a lower implicit speed limit > of 30 mph applies. There is no mention of it in the wiki, no GB:urban, > GB:lit, GB:zone30 or anything like that, so something should be defined > and documented by (you,) the British OSM community. > > My question: > How to tag roads in which such an implicit speed limit for built-up > areas applies? > > The question is motivated by an issue report for StreetComplete [2] > > Cheers > Tobias > > [1] > > https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table > > <https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table> > > [2] https://github.com/westnordost/StreetComplete/issues/1037 > <https://github.com/westnordost/StreetComplete/issues/1037> > > ___ > Talk-GB mailing list > Talk-GB@openstreetmap.org <mailto:Talk-GB@openstreetmap.org> > https://lists.openstreetmap.org/listinfo/talk-gb > <https://lists.openstreetmap.org/listinfo/talk-gb> > > ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] Implicit speed limits: What to tag in built-up areas?
Hi there On tagging implicit speed limits in the United Kingdom, the wiki lists the following values [1] for "maxspeed:type": GB:nsl_single (=60 mph), GB:nsl_dual (=70 mph) and GB:motorway (=70 mph) I understand that the current legislation defines a road with road-lighting as a built-up area in which a lower implicit speed limit of 30 mph applies. There is no mention of it in the wiki, no GB:urban, GB:lit, GB:zone30 or anything like that, so something should be defined and documented by (you,) the British OSM community. My question: How to tag roads in which such an implicit speed limit for built-up areas applies? The question is motivated by an issue report for StreetComplete [2] Cheers Tobias [1] https://wiki.openstreetmap.org/wiki/Speed_limits#Country_code.2Fcategory_conversion_table [2] https://github.com/westnordost/StreetComplete/issues/1037 ___ Talk-GB mailing list Talk-GB@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-gb
Re: [OSM-talk] [Diversity-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?
On 25.04.2018 15:23, Martin Koppenhoefer wrote: > Unisex=yes is defined as a shortcut for male=yes + female=yes This may be a stupid question, but where are you all getting this definition from? I assumed the key already had the meaning that Rory is suggesting here. And at least on the Key:unisex and Tag:amenity=toilet wiki pages, I see nothing to contradict that. The former page mentions that the tag implies male=yes and female=yes, but "implies" should not be confused with "is equivalent to". ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Sidewalk symmetry
On 24.04.2018 02:17, Clifford Snow wrote: > But if you want > someone to use the data, then map it as separate ways. That's not the case, and it's a bit frustrating to read this just after I wrote a mail explaining this point. To reiterate: * With separate ways, we don't know which road section a sidewalk belongs to. * This knowledge is necessary for many applications. For such a fundamental property, "research scientists believe they can use the spatial proximity" is not good enough imo. It has to be practical to obtain this relationship from OSM data. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Name:* tags in the local language
On 24.04.2018 19:23, Paul Norman wrote: > It is sometimes recommended that when you add a name in another language > you also indicate the name in the local language by adding a suitable > name:* tag at the same time. For example, if adding "name:fr=Londres" to > London, you would also add "name:en=London" if it weren't present. > > This practice is not widely followed. I have to say I'm not a fan of this practice, at least for straightforward cases. Yes, there are parts of the world where explicit language information is necessary. But in many others, there is an obvious default, and it feels wrong to require mappers to manually repeat this on millions of individual elements. Don't add extra tags to German names in Germany, for example – tag the exceptions from the rule instead. As a less important secondary point, I also consider the specific tagging (duplicating the name with a different key) counter-intuitive and would prefer a "language of the name" key, with the language given as the value. The purpose of that tag would be much more self-documenting than with the recommendation described above. That being said, displaying labels in the user's language is an exciting use case, and I hope we can find a solution that allows your project to succeed. Could you elaborate a bit more on the technical limitations regarding regional processing? > Fixing this in software doesn't work > well because it requires regional processing of what are increasingly > small regions as you get to less used languages. You mention increasingly small regions as the obstacle. Would that still allow for the pragmatic compromise of setting country-level defaults, and using explicit tagging only for smaller-scale language regions? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How do you mapping gender neutral toilets? What should the unisex tag mean?
Why do you think it necessary to map at all if any particular toilet is segregated or not beyond whether I can go there as a man/woman? What is the application? On 24/04/2018 18:27, Rory McCann wrote: > Hi all, > Let's have a wee talk about how should one map gender neutral (and > gender segregated) toilets. There is a unisex=yes for toilets which > looks like it might be the number one tag to use. The bog standard > meaning of "unisex toilet"[1] is a gender neutral toilet, i.e. not > segregated into separate male & female facilities. > > Many smaller public toilets are single occupancy and hence unisex, many > larger public toilets (e.g. in shopping centers) are segregated. Social > conservatives are mostly losing the battle on same-sex marriage, so > their new target is trans people, and they're proposing "bathroom laws" > to limit trans people's access to public life. Some organizations are > making their toilets "gender neutral" in response. So there are probably > a lot of gender neutral public toilets, and it's very useful for some > people to know where they are. > > But I don't think that's how "unisex=yes" been used in OSM. The wiki > page says "unisex=yes" is a shorthand for "male=yes female=yes". The > JOSM validator used to suggest that replacement, until I filed a bug[2]. > iD's preset has 3 mutually exclusive options, Male, Female and Unisex, > it won't let you add both male=yes female=yes. > > If I see "amenity=toilets unisex=yes", I would think this is a gender > neutral toilet. If I see "amenity=toilets female=yes male=yes" I would > think gender segregated. Big difference. > > I propose that we start viewing "unisex=yes" on toilets as meaning > "gender neutral toilet", which is different from "male=yes female=yes", > which is "gender segregated". > > Thoughts? Feedback? Anything I'm missing? Is unisex-yes tag being used > by many projects? What do they interpret it as? It's good not to force > things. > > A year ago Micah Cochran's suggestion[3] would be along these lines, but > some changed to toilets:for:unisex=yes (etc.) > > Rory > > P.S. I am doing this as part of the "Diversity Quarterly Project"[4], > which for the quarter is gendered toilets. Plenty of toilets have no > male/female (and/or unisex) tag, and we should add those tags. > > [1] https://en.wikipedia.org/wiki/Unisex_public_toilet > [2] https://josm.openstreetmap.de/ticket/15536 > [3] > https://wiki.openstreetmap.org/wiki/Proposed_features/Toilet_Tagging_Improvements > > [4] https://wiki.openstreetmap.org/wiki/Diversity_Quarterly_Project/2018_Q2 > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Sidewalk symmetry
On 18.04.2018 05:03, Andrew Harvey wrote: > highway, surface, maxspeed, maxweight, maxheight, width, oneway, access, > lanes, turn:lanes, lit, parking:lane:left, parking:lane:right, > parking:condition:left, parking:condition:right,parking:lane:left:type, > parking:lane:right:type, etc. The percentage of roads tagged with all these details is vanishingly small, and will likely remain so for at least another decade. At the level of detail that's realistically achievable in the medium term, sidewalk tags make a lot of sense: They're easy to use for the common case (where sometimes not even the existence of sidewalks is mapped yet), and still allow for micromapping in pockets of unusually high data quality. > I realise editors can and do abstract some of this, but if we can put > all those sidewalk attributes on their own ways it makes it much easier > to map by reducing the complexity of the highway centerline. Comparing the mapping styles solely based on ease of mapping would only make sense if separate ways were able to express the same information contained in sidewalk tags. That's not the case, though: With separate sidewalk ways, it's impossible (in the general case) to figure out which road section that sidewalk way belongs to. Not having this basic information available makes separately mapped sidewalks unusable for entire categories of applications – sometimes leading to worse outcomes than not having the sidewalk mapped at all. And while you could fix that issue with relations, this would clearly not be easier for mappers than using sidewalk tags is. As for the original question: sidewalk=separate seems like an attempt to solve the aforementioned issue, but it does not actually achieve this goal – it only tells you that *some* sidewalk way belongs to this section of road, but does not help you to find out *which* sidewalk way that is. As such, it's not a very useful tag, and not a compelling reason to map asymmetric real-world situations in a symmetric way. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] "The Future of Free and Open-Source Maps" Slashdot.org , Saturday February 17, 2018
I also read this article and I found it identifies some areas in which (the central infrastructure of) OpenStreetMap could improve. What I do not like about this article is the deeply pessimistic and resigned tone of it, like clickbait. It reads like "OSM needs to change from the core up or else it will be doomed!". Yeah, I don't think so. And I do not think that this mode of appeal is that productive. It's good if it sparks discussions about what we can and want to improve, but I do not think that it is going to inspire anyone to "save" OSM by innovating things. This is not how it works in FOSS, and not how innovation works. AI detections of features from pictures/drone videos for example is not going to happen because someone writes that we _really_ need this now to keep up, but because someone is enthused about the concept (and is able to capture others with that). Also, Serge maybe doesn't know https://blog.mapillary.com/update/2015/01/27/traffic-signs.html That there might be a conflict of interest regarding pulling more technology and services into the core OSM toolset is an interesting thought that did not cross my mind before and that may very well be true. Though on the other hand, I consider the fact that OSM runs on a "shoestring budget" as something that contributes to OSM's sustainability: I.e. I observe with concern that Wikimedia apparently requires more and more money every year to survive. OSM's minimalistic organizational structure is simply a different concept than WP. Regarding the "area" type, I agree that it would be a good improvement to introduce a more fixed notion of areas in OSM data. To introduce another data type has quite the ramifications on backward compatibility but there may be other options. Right now, every single piece of software needs to maintain an area detection based on tags like this: https://github.com/westnordost/StreetComplete/blob/master/app/src/main/java/de/westnordost/streetcomplete/data/meta/OsmAreas.java#L13-L28 Naturally, it is different, thus inconsistent, for any piece of software - and needs to be updated for any tagging scheme that comes up. If I were to name the biggest challenge for us, it would be the maintainability of the map data, a topic that he never mentions directly. Tobias On 17.2.2018 10:56 AM, Oleksiy Muzalyev wrote: > This article is on the front page of the Slashdot today: > > Fri 16 February 2018 "Why OpenStreetMap is in Serious Trouble" > > https://blog.emacsen.net/blog/2018/02/16/osm-is-in-trouble/ > > > "The Future of Free and Open-Source Maps" > > https://news.slashdot.org/story/18/02/16/2216228/the-future-of-free-and-open-source-maps > > > > I actually read the article, and though it has got insightful > information and interesting ideas, I have doubts about some suggestions. > > For instance, reviews. I hope it will not come to what there is at some > commercial maps, when one adds say a building and then has to wait for a > month that an almighty moderator approves it, so that it appears on the > map. > > I also skeptical of massive imports from governments' databases. These > databases were created in the last century, with outdated tools, > sometimes by disinterested underpaid clerks, probably in a climate of > secrecy of that era. And such an import may replace the quality data > from modern satellite imagery, GPS traces, surveys, etc. > > Best regards, > > O. > > > ___ > talk mailing list > talk@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
