The OSMF board has finally published the draft for the OSMF attribution guideline they have been working on - together with the firm intention to approve that in the next public board meeting without changes. This is unfortunately reminiscent of previous cases of the OSMF board developing policy and documents internally among themselves without public scrutiny and presenting them to the public as a done deal, ultimately with often very sub-optimal results.
So these comments are less in the hope that the board will revise their work style and discuss policy openly and publicly with the community from the start because they realize that this yields objectively better results and more to help the community understand the (in large parts somewhat confusing and difficult to understand) text and its provenance and implications.
I will not present a full history here - largely because it would make this text too long to read in a reasonable amount of time but also because much of that history has not been open to direct public observation and can only be reconstructed from minutes of LWG and board meetings which inevitably only show a selective record of history.
Many years ago some OSM community members have started developing some practical guidance documents explaining how to use OSM data practically in compliance with the License - thereby explaining the relatively abstract text of the ODbL and what the OSM community considers this to mean in practical terms. In 2014 Michael Collinson started organizing these more systematically in what was called the Community Guidelines and engaged in fairly elaborate public discussions with the community to design guidance that reflects community consensus on OSM data use. These guidelines however were only discussing specific aspects of the ODbL and do not represent an exhaustive guidance to the License. In particular they were missing any substantial practical guidance on the two core principles of the ODbL, namely the attribution and the share-alike principles. These were mentioned in passing in the other guidelines (i.e. that you have to attribute and you have to share derivative databases under certain conditions) but there was no guidance how to actually do that.
Over the years corporate data users have essentially tested with how little attribution (and share-alike) they can practically get away with and OSM community members became increasingly annoyed with that. In particular the services of Mapbox and Carto became heavily criticized for encouraging their customers for only providing OSM attribution that is hidden by default. The matter was discussed frequently on OSM channels - in particular here.
Back in 2019 then the LWG (with most of its members being lawyers on the payroll of corporate OSM data users) started writing a guideline on attribution. When this was presented to the larger OSM community it received very critical comments regarding the leniency the draft showed with commercial OSM data users - essentially allowing them to make their attribution of OSM contingent on compatibility with their business model. A revised draft was not much better and again received substantial critique.
In 2020 the LWG continued working on their draft - but without much further discussion in public with the larger OSM community. Instead they sought input from visitors of SotM conferences (which of course tend to have a higher fraction of voices sympathetic to the corporate interests). The OSMF board also got involved in the process and they themselves worked on a modified draft - likewise without open public discussion with the larger OSM community but focusing on consulting with representatives of corporate OSM data users. During that time the only not corporate affiliated members of the LWG left (Nuno and Simon) so the LWG was a corporate only working group until Dermot McNally (from OSM Ireland) joined. During early 2021 further internal work ensued, the OSMF board apparently also got external legal advice (but neither the questions they asked nor the answers received were made public) until in June the draft the board intends to become the final version was published (without an edit history - apparently the board writes this on Google Docs).
A lot could be critically discussed about this whole process (and i hinted at a few concerns in the above outline what happened) - but this is not what i want to focus on here. I will try to comment on the text itself ignoring as much as possible how it came into being (though i will mention this when it helps understanding why the text is written the way it is).
I also like to mention that in light of this process and the realization that the OSMF board does clearly not intend to write a Community Guideline in the original sense of the word as a guideline representing the consensus view of the wider mapper community i have some time ago made an attempt to formulate independently a guidance document that attempts to do exactly that - the Community Attribution Advice.
Back at the end of last year when i looked back at the developments in the OSMF and looked forward at the upcoming year i discussed the attribution guidelines and in essence i mentioned that the board has the choice between deciding on a guideline that serves the interests of the OSMF financiers or a guideline that reflects community consensus on the interpretation of the ODbL in practical use. What the board tries now with their draft is a compromise between both and to be honest: They did a better job at that then i expected them to be able to do. Note however this is less of a compliment than it might seem because the attempt at a compromise between two diametrical positions like that is clearly doomed of course. As a result the text is what you would typically call a lame compromise, fairly full of contradictions - both with itself and with the ODbL itself. You can see quite well how the formulations were honed to reflect the balance of interests as perceived by the board members in their consultations with each other and with the corporate stakeholders. Relatively little regard seems to have been given to the inner logic of the text and the consistency of the statements made. As a result of that the text lacks an overarching principle and is therefore hard to read and it very difficult to derive guidance from it beyond the specific use cases the authors had in mind when writing the text (and even that in many cases seems to contain contradicting messages).
This issue is in particular visible in the introduction which consists essentially of a list of mostly unconnected statements. Most of them deal with the attempt of explaining the supposed relationship between the guidelines and the ODbL. This is somewhat self contradicting since presenting the guidelines as a “safe harbour” and having a prominent disclaimer that compliance with the guidelines does not guarantee compliance with the ODbL and that the OSMF reserves the right to demand more attribution in the future do not really work together.
There is also a statement that is clearly factually wrong in the form of “Note that attribution is only necessary when a Produced Work is used Publicly (as defined by the ODbL)” - the ODbL also requires attribution for public use of the database/derivative database when no produced work is involved (see section 4.2). That attribution requirement is different (and more extensive) than that for produced works but the above statement is clearly misleading the reader to believe that attribution is only required for produced works and not for other public uses of the database.
The section “Why attribution is important” seems to reflect the new business like attitude of the OSMF regarding OSM, caring primarily about market share and usefulness of the data but not viewing OpenStreetMap as a social project that much any more. No mentioning of the significance of attribution as part of the social contract between mappers and between mappers and data users beyond “encourages them to contribute more” and “maximises the quality of the map”. Everyone is encouraged to compare that to the Community Attribution Advice.
The section “Requirements to fit within OSMF’s safe harbour” is the good part of the document (apart from the fundamental flaw with the “safe harbour” concept of course - see above). Here the board clearly departed from the corporate wish-list ideas in the LWG drafts and is asking quite clearly (even if a bit convoluted) for unconditional attribution. Since i frequently have criticized the board for the lack of backbone in dealing with corporate OSM data users i would like to point out clearly that this is a bold statement that - in light of the OSMFs financial dependence on corporate donations - took quite some courage obviously and i am positively surprised by that.
My main critique of this part is that it focuses too much on visual applications and attribution in static text form to be visually read by the user. The ODbL is agnostic in that regard, it only speaks of making people aware. Since this section is aimed at formulating generic attribution requirements (more specific examples are discussed later) it would have been good to keep it more generic and not imply that a valid attribution has to be visual (through formulations like “placed in the vicinity”, “legible”).
The same critique applies to the next section, “Attribution text”. What is written there is mostly good and important advice - but it is on specific (even though common) use cases and not suitable as a universal ‘must’ requirement for any and all OSM data use. Presenting it as such IMO weakens the message rather than emphasizing it.
My positive comments end here because what follows in “Safe harbour requirements for specific scenarios” is what we in German call “Verschlimmbesserung” of the LWG draft. It is really unfortunate that after having the courage to replace the lenient generic attribution ideas drafted by the LWG with concrete hard requirements they could not get themselves to rewrite this part from ground up. Maybe that is because they wanted to retain something from the LWG draft to not ostentatiously disregard all of their work. I don’t know for sure. What i do know is that the flaws in this part significantly diminish the positive impression from the previous. But lets get to things one at a time.
This section unfortunately fails to make a distinction between using and distributing databases.
Unfortunately the same screenshot that has been used since the early drafts for the guideline is still in there - showing a map that prominently features non-OSM data (for landcover rendering) - kind of contradicting the statement that “OSM does not wish to claim credit for data or other material that did not come from it”. And while mentioning that it is ok to have a mechanism that allows users to hide the attribution the text unfortunately does not mention that this is only allowable in single user viewing situations. If on a public map display the technician starting the display routinely hides the attribution and all users subsequently do not see it that is not in compliance with the ODbL.
Unfortunately despite clear critique in the past this section still gives data users a blank cheque essentially saying that any subset of OSM data covering less than 10000 square meters (that is 100mx100m) is considered to be insubstantial no matter how substantial it is in terms of the volume of data. This is even more concerning since the rule of thumb that any use with less than 100 features is mentioned to be considered insubstantial as well. Hence the additional inclusion of the 10000 square meters rule (which - as i mentioned previously - is fabricated out of thin air here without any argumentative basis in reality) explicitly weakens the premise that if an extract of OSM data is considered substantial is a matter of the volume and complexity of the data and the investment of mappers’ time that went into it. The OSMF board here essentially declares nearly all indoor mapping in OSM on its own to be not subject to any ODbL protection when used individually for individual buildings only - no matter how sophisticated the mapping is. You could argue that the OSMF this way also betrays their own mission statement by declaring certain types of mapping (the detailed and substantial mapping on a scale of less than 100x100m) as out-of-scope for OSM and thereby effectively drive(s) mapping in a particular direction.
Like in a good thriller the guideline draft is building up tension slowly to come to the big finale here. This point had been in the first LWG draft already and the board kept it without major modifications - despite it being completely off-topic in a guideline on attribution. The only change they made is quite clearly an attempt to superficially pacify some of the critique that was being made regarding this section in the LWG draft by specifically declaring the example that was given in that critique (the possibility that ML/AI algorithms can under some circumstances reproduce parts of the training data - like a translation algorithm spitting out snippets from the texts it has been trained with when being fed with garbage data in use) as being not covered by this section. That does not change anything in substance about the message of course since that was just an example to illustrate the critique.
Given the sweeping critique of this section and its presence in a document on attribution it seems odd that the OSMF board decided to keep this in the guideline. I am not completely sure why. The most likely explanation is that they have not fully realized the far reaching implications of this section and they - as mentioned above - wanted to give the corporate data users something to balance having cut their wish-list on attribution rules. This would match the overall paradigm of the board in the last years to consider policy development as a negotiation of interests rather than a matter of arguments and reasoning.
What this section does is essentially declaring an exception of the license for use of OSM data in the design of data driven algorithms (meaning algorithms the behavior of which is not primarily defined by a human programmer but by feeding it some data and the algorithm incorporating that data to define its behavior). The guideline draft uses different terms which are used in different meaning elsewhere (like training) but the way these terms are used in the guideline is very generic - hence it is more clear to speak of data driven algorithms. Now the ODbL is very clear on the matter in principle: If you use a substantial amount of OSM data in a way that is a derivative work of the data the results of that are either a collective database, a derivative database or a produced work. And despite some people claiming that there could be cases where a substantial use of OSM data could be neither and as a result magically could be used without any restrictions that idea has no solid basis in either the law or the ODbL and the intention of the ODbL is clearly to only have these three possibilities.
Now what the guideline draft says is the following:
If you look at this logic carefully you can see that this is essentially the wild dream of Facebook & Co. Creating the legal basis of designing data driven algorithms with extensive memory that you can feed with any copyrighted, proprietary or confidential personal data you can get into your fingers and that you can then adjust to produce any kind of economically valuable data without any legal or economic implications towards the data you use. The OSMF board here essentially gives a universal permission to do that with OSM data. The only constraint they added (that you cannot use this to exactly reproduce the training data) is insignificant because no one who creates a derivative database wants to exactly recreate the original data anyway, you want to create something with additional value for you.
My impression is that this point could be - for the corporate data users who primarily wrote the original LWG text - of higher strategic importance than the practical attribution leniency the board has cut out. And it has potential implications even beyond OSM and the ODbL. My impression is that the OSMF board has not realized the potentially far reaching consequences of handing this as a pacifying gift to the corporate data users and financiers of the OSMF.
Or let me put it in a different way: The discussion on the ethical context and implications of data driven algorithms in our society as a whole has just started and the OSMF board making a drastic statement prejudicing that discussion is something i can only characterize as reckless.
The rest of the specific scenarios discussed in the text mostly suffer from what i would describe as URL fetish. The OSMF board wants openstreetmap.org/copyright to be shown everywhere and considers this (which is not in any way mandated by the ODbL) more important apparently than what the ODbL actually asks for, namely to make the users aware that the data is licensed under the ODbL. Falk has nicely pointed out this weird preference in his recent FOSSGIS talk. The traditional interpretation of linking to openstreetmap.org/copyright has always been that this is considered to be a compact form to satisfy the requirement of the ODbL to make the users aware of the license in interactive online applications (if it actually is can be open to discussion of course). That is for example explicated in the Licence and Legal FAQ of the OSMF. And in offline or non-interactive use cases this is not sufficient and you have to explicitly mention the ODbL instead (like with the Contains information from OpenStreetMap, which is made available at openstreetmap.org under the Open Database License (ODbL) i suggest in the Community attribution advice). So the OSMF board is with their new attribution guidelines in this aspect quite clearly at odds with both the ODbL and with their own previous guidance.
Overall there are - as discussed - good and bad things about this guideline draft. I want to emphasize again that i am positively surprised how far the OSMF board has come to push back against the hands that feed them so to speak. So my explicit respect and acknowledgement for that. But as also shown there are a lot of deficits in the text beyond that. By
they came up with many of the same problems as in previous similar cases leading to sub-optimal results and missed opportunities.
I can understand and to some extent even support Frederik’s take on the matter that this as is represents important progress compared to the direction the attribution guideline went before and it would be important to cash in on this progress and not loose it due to remaining deficits in the text. But still the amount of unused potential, the thought of how much better these guidelines could have been with just a little more open scrutiny and a tiny bit of copy-editing for readability and consistency, makes me sad, especially considering how much of a déjà-vu that is from previous cases.
What a pleasure to find out that Esri permits mappers to access their collection of past imageries known as World Imagery Wayback.
Map it like the early noughties!
Why older imageries can be useful, some might argue.
It was already stated in the diary post that “The older imagery may include the features you are editing with better clarity or relative accuracy.”
Indeed. So, this was proven during one of my edits made today.
Other mappers might consider me as a waterway mapper junkie. Yeah, I’m so very into it, when the right mood comes.
Straight into today’s anecdote: a KartaView picture suggests there is a nearby waterway.
The freshest Maxar imagery indicated so too. With a caveat.
The path of said stream sneaks from the south east to the north west. Around the oil palms next to a Chinese burial ground, however, it is unclear how and where it connects to the nearby river.
This is probably one of the many cases where Esri Wayback Imagery comes to the rescue! Problem is solved.
However, since waterways are a dynamic geographical feature, so some critical reasoning should be included as well. But personally, this is perfectly A-OK (in this specific case).
Well, at least Esri World Imagery Wayback allows me to access the (only?) greyscale imagery from the early 2010s (was available on Mapbox Satellite before the gradual bit by bit imagery refresh). Which I find it very useful to detect possible waterways.
Um geógrafo, uma criança abandonada, um hacker e um concurseiro entram em um bar…
Não lembro da primeira vez que eu tivera contato com o projeto do OpenStreetMap, porém sei que envolveu a minha busca nos últimos anos por alternativas às ferramentas do Google. Tudo isso uma consequência do meu desejo por privacidade na Internet gerada pelos escândalos da NSA revelados por Edward Snowden, além do mal que eu sentia ao usar tantas tecnologias centradas em uma só organização.
Eu já tentara usar o OSM como alternativa ao Google Maps porém, na maioria das vezes, retornava frustrado por não encontrar nada na minha região interiorana. Sentia vontade de contribuir mas achava que poderia ser complicado demais e tinha medo que minhas edições fossem consideradas “cópias ilegais” de outros sites. Até então, não fazia ideia que o projeto valorizava o conhecimento tradicional do mapeador.
Na ordem cronológica dos acontecimentos, o geógrafo que chegou no bar não foi a primeira pessoa a entrar. Na verdade, o hacker e a criança abandonada já estavam ali dentro e ninguém saberia dizer ao certo quando chegaram. Porém, como o geógrafo se tornou importante naquele estabelecimento, decidi destacá-lo primeiramente.
Quem é o geógrafo? O geógrafo (que não era geógrafo) era um mapeador. E foi ele que me apresentou o OSMAnd. Sempre tive o desejo de ter um app que me possibilitasse acessar mapas no meu smartphone Android de forma offline já que raramento uso Internet ao sair de casa e em boa parte de locais rurais por aqui não têm sinal telefônico. Além disso, um manual de sobrevivência que tenho guardado no celular e costumo ler o recomendava. Fiquei fissurado com o app. Finalmente podia visualizar minhas trilhas no meio do nada e até compartilhá-las caso quisesse. Baixei os mapas do meu estado e do estado vizinho, junto com a topografia e utilizo-o bastante sobreposto à camada de visão de satélite da Microsoft Earth. Assim, a falta de locais no OSM podia ser parcialmente suprida.
Nesse instante, alguém entra pela porta do bar e pede uma caneca de cerveja, apressado. Afinal, a vida é corrida.
A vida profissional de um recém formado em licenciatura é complexa. A dificuldade de encontrar um emprego fixo é uma realidade, principalmente em regiões do Nordeste que o investimento pesado em cursos de Licenciatura formaram diversos profissionais na mesma área. Tanto a falta de experiência quanto a conhecida “politicagem” frequente em regiões interioranas impossibilitam que jovens formados consigam atuar. Assim, concursos públicas são uma rara oportunidade de conseguir o sonhado emprego fixo.
Para realizar a prova de um desses concursos, precisei viajar para Campina Grande e, como estava indo com conhecidos, decidi experimentar o OSMAnd durante o trajeto e comparar com os resultados obtidos com o Google. De minha cidade até lá, acredito que 90% dos mapas no OSM estão incompletos ou desatualizados mas isso não foi um problema. Como as estradas estão catalogadas e Campina Grande tem uma boa percentagem mapeada no OSM chegamos ao nosso destino facilmente. O OSMAnd praticamente foi idêntico ao Google mas apresentou a vantagem inegável de funcionar offline e não “invadir e vender” minha privacidade. Mais estrelinhas do meu coração para o app.
Mas então, como eu poderia resolver o problema imenso da falta de atualização e de locais da minha região no OSM? Uma busca rápida por usuários próximos me revelou apenas edições muito antigas e coisas simples como nomes de escolas e estabelecimentos principais faltavam. Bem, se ninguém mais editava o mapa… Por que não eu mesmo fazer isso? Afinal, se eu saio de casa só para tirar a bunda do sofá, esticar as pernas ou tomar sol, poderia muito bem aproveitar minhas caminhadas e contribuir com algo. E aí, todas as estrelinhas do meu coração alcançam o Geógrafo (que não é geógrafo) por me dar suporte e ajuda em vários momentos. Além disso, eu poderia unir todas as minhas metas de: não ser tão sedentário, entreter a criança abandonada do meu “vazio interior”, fotografar e aprender edição com o Gimp e ainda reviver um hobby de criação de mapas fictícios que há anos não revisitava.
O hacker, no banquinho ao lado da criança, levanta bêbado e começa a gritar com ela “seja útil, faça algo que preste!”. A criança não chora e questiona o que ele quer que ela faça. O hacker grita “Hackitat!”
Hackitat é um documentário elaborado por crowdfunding e que me deu um estalo sobre as potencialidade de mapas livres, abertos e gerados pela comunidade. Assisti como recomendação de algum “desconhecido virtual”. O documentário em si é sobre hacktivismo e a primeira parte menciona a criação de um mapa comunitário para detecção de locais contaminados por radiação do desastre de Fukushima, no Japão. Embora ele por inteiro tenha prendido a minha atenção, essa parte em si me atraiu bastante pois interligou áreas que sempre me interessaram: tecnologia, ativismo, ambientalismo, inovação, preocupação com o próximo… E por aí vai. O estalo ainda ressoa na minha cabeça e despertou em mim o desejo de interligar a Química (minha formação), o ambientalismo (um dos meus ideais mais ferrenhos) e o mapeamento (meu mais novo hobby). Ainda não tenho colocado em prática tal meta pois ainda preciso aprender muito a usar, contribuir e editar o OSM.
Hacker desaba sobre uma mesa e a criança tenta ajudá-lo. Ele levanta e sai de cena, fugindo pela porta sem pagar. A criança corre atrás dele e desaparece. O concurseiro observa o geógrafo e sorri. Apressado, paga as contas e levanta-se para sair mas o outro segura o seu braço: “Precisamos ajudá-los”, diz o geógrafo apontando para a porta. Os dois saem juntos.
O barista surge por detrás da bancada segurando um caderninho de anotações. Com uma caneta começa a escrever um rascunho: “um geógrafo, uma criança abandonada, um hacker e um concurseiro entram em um bar…”. Risca toda a frase e reescreve: “um mapeador e um aprendiz entram num bar… E atualizam e adicionam novas tags que faltavam naquele ponto.”
The Riverside Estate was missing all buildings and addresses. Roads haven’t been refined for over five years.
I’ve spent 3 days of my holiday to improve the estate’s mapping.
Оказывается, село Таврическое находится и в Донецкой и Запорожской области :-)
P. S. я редактировал их двоих.
Думаю, на многое не повлияет, тем более в Запорожской всё более куда интереснее)
ich habe nicht all zuviel Ahnung von vielem hinter Openstreetmap. Eines frage ich mich aber schon. Das “Ding” heißt Openstreetmap ist aber im Beschreiben von Straßen geradezu naiv. Auch die Darstellung (in den Renderern und Editoren (soweit ich sie kenne)) von Straßeneigenschaften sind, finde ich, unterrepräsentiert/unterentwickelt. Ob z.B. ein Bürgersteig an einer Straße “dranhängt” (und wo) sehe ich nicht in der Karte. Auch die Straßenbreite und die Anzahl Fahrspuren, kann man nicht richtig erkennen oder bearbeiten. Damit muss man wohl in dieser Straßenkarte leben. Dabei heraus kommt dann eben “Gebastel”. Da es ein Projekt von Freiwilligen ist, will ich da auch gar nicht weiter “mekern”, ist halt so.
Und auch, wenn ich es gerade mal lustig finde mit der 3D-Darstellung herum zu spielen: Setzte ich ein Flächenpolygon, z.B. für ein Dach, sehe ich nicht, wo der Ursprungsnode ist. Problem ist aber, vom Ort des Ursprungsnodes sind andere Eigenschaften abhängig, das nervt und mache eigenschaften kann ich deshalb nur mit mehreren Tagen herumprobieren richtig setzen….
Ich versuche mich da so durchzuschlagen, ich mappe nur in der Gegend, die ich auch kenne (wo ich wohne) und “spiele” da auch rum um herauszufinden, was gut funktioniert Hauptziel ist eine gute Karte zu haben die möglichst viel korrekt beschreibt. Wenn jemand einen Tipp für mich hat, kann er sich gerne nett und freundlich und möglichst mit Links angereichert an mich wenden, ich könnte ja etwas dazu lernen. Was ich so anderswo gesehen habe, schreckt mich schon etwas ab. Muss es denn immer gleich “Betonkopf” sein? (Meine Meinung ist die Richtige! Mach so, wie ich das interpretiere!). Das wünsche ich mir dringend nicht für Kommentare an mich.
Several years ago, Esri made its World Imagery map accessible through OSM editors such as iD and JOSM. The goal of this was to give OSM mappers some additional options for high-res imagery when creating and editing features in OSM.
The Esri World Imagery map is compiled from multiple sources, including Maxar satellite imagery as well as aerial imagery from various GIS organizations (e.g. cities, counties, states/provinces, etc.). In general, the World Imagery map is curated to feature the most recent imagery we have available for a given area, though we do retain some older imagery for a while if it is better in other respects (e.g. currency, clarity).
The World Imagery map is updated every few weeks with the latest imagery that we’ve assembled and processed. During a release, we replace the current set of image tiles with a new set of image tile for several areas where we have updates. For example, in our most recent update, we updated the imagery in Western Europe with the latest Maxar imagery.
For most users and use cases, these updates are a good thing because they provide access to more current imagery. In some cases, however, it may be less desirable. The latest imagery may be more current, but it may also be more cloudy for a specific location, or the imagery might have shifted a few meters relative to existing features in the OSM data. In these cases, the previous or even older imagery may be preferred for editing. The older imagery may include the features you are editing with better clarity or relative accuracy. This is why many of us compare imagery background layers when editing OSM data for a given area.
A few years ago, Esri introduced World Imagery Wayback to our collection of World Imagery offerings. Wayback Imagery is a digital archive of the World Imagery map that enables users to access over 120 versions of World Imagery published over the past 7+ years, starting February 2014. Users can browse and select any one of the versions of World Imagery (e.g. the version released on YYYY-MM-DD) and access the imagery that existed in the World Imagery map starting at that time.
The best way to explore this imagery is through the World Imagery Wayback app. The app is fairly self-explanatory but there are some steps described in this blog post for how to use the Wayback app, and browse the Wayback archive. Once you familiarize yourself with that info, you can follow the steps below to use Wayback imagery in OSM editors such as iD or RapiD.
An OSM mapper recently contacted Esri (osm@esri.com) about whether it was possible to access the previous version of World Imagery in iD because they preferred the previous imagery for an area they were mapping, and they were delighted to learn that it was possible to access in iD. I was delighted too because I hadn’t actually tried it previously myself!
Below are suggested steps for adding a specific Wayback layer to iD:
You can now use the Wayback imagery as your custom background layer during your editing. You can toggle between the custom layer and the current Esri World Imagery, or other available backgrounds such as Bing aerial imagery, as you see fit.
Happy mapping!
Data they say is the “new oil”. This phrase, although seemingly far fetched is nothing short of the truth in today’s ecosystem.
Начал “великий” маппинговый поход. Буду выделять дома и дороги в сёлах близлежащих с Мариуполем. Первая цель - село Таврическое
Hallo, kann jemand Griechischen und Serbischen, Bulgarischen Alfabe in Latein um ändern?? weil auf Mapfactor navi kann man es nicht ändern. danke
I’ve written an overview of the patterns of major roads across Australia, based on OpenStreetMap data.
https://littlemaps692810600.wordpress.com/2021/06/21/australian-roads-in-openstreetmap/
There’s lots of colorful maps, charts and tables. It’s a deep dive that breaks down the total length of motorways, trunk, primary, secondary and tertiary roads in all Australian states, and the proportion of each that is paved and unpaved. (With a couple of local exceptions, virtually all of these roads now have surface tags.) It focuses on the patterns of the roads themselves, not tagging patterns.
So, if you’ve ever wondered: (1) what proportion of all major roads is unsealed and unsealed; (2) how the Tasmanian road network varies from that in other states; (3) where to find the longest, unpaved, trunk road in Australia; and (4) many other nerdy road facts, please take a read.
Estacionamiento de bicicletas en Ciudad Jardín. Fuente: Mapillary, imagen de Areyesl (CC BY-SA 4.0).
El usuario Areyesl está haciendo un gran trabajo con los datos de estacionamientos de bicicletas en Málaga. Se importaron un gran número de ellos a partir de datos abiertos del Ayuntamiento de Málaga, aunque no eran todo lo precisos ni completos que se pudiera desear. Desde entonces —incluso desde antes—, Areyesl ha estado visitando uno por uno estos emplazamientos, corrigiendo las imprecisiones y completando la información que faltaba. También está añadiendo imágenes en Mapillary de cada estacionamiento.
Probablemente sean los mejores datos disponibles sobre este tipo de instalaciones, incluso mejores que los ofrecidos actualmente por el Ayuntamiento de Málaga. El crédito es obviamente colectivo y corresponde a todos los colaboradores de OpenStreetMap —incluido el propio Ayuntamiento—, aunque en este caso particular habría que hacer una mención especial a la labor de Areyesl.
Los datos se pueden descargar haciendo una sencilla consulta en Overpass turbo, el software de minado de datos de OpenStreetMap. Cada estacionamiento está etiquetado con su tipología y su capacidad, entre otras informaciones. ¡Hasta con fotos! Cada elemento con foto tiene vinculada su imagen en Mapillary, por lo que se puede acceder a las imágenes de cada estacionamiento con un simple clic.
我十分喜爱地图一类的事物，但总是找不到能让我施展自己的热爱的地方。这天，我无意间发现了这个网站，便发觉这里就是我想要找的地方。能够与一个城市内的各个地区，乃至世界各国的其他城市的人，分享、交流本地的地理信息，这就让人十分激动了！
Складно мапити в онлайн редакторі, або не все зрозуміло які теги ставити? Тоді спробуй цю програму: StreetComplete
Вона просто задає питання і простими словами пояснює що це таке. Далі просто оберіть те що ви бачите і все - на карту буде доданий тег/місце.
Завантажити програму тут
Avenida Guilherme Cotching 100% numerada , com dezenas de pontos de interesse, canteiros, paradas de ônibus , clinicas,posto policial,pontos de táxi etc.
言いたいことが山ほどある。
Ich stelle fest, dass immer häufiger die Mapper in ihren Änderungssatz-Kommentaren nur eine Liste von Hashtags schreiben. Ich habe speziell in Nepal versucht, eine Verhaltensänderung zu erreichen: - Artikel im Forum - individuelle Changeset comments - Aufforderung in der Facebook-Gruppe - Meldung an die DWG
Leider bin ich hier fast komplett gescheitert.
Ich habe nun das Problem in verschiedenen Ländern näher untersucht. Nach der Neis-Statistik habe ich jeweils geschaut, wie viele der 10 fleißigsten Mapper in den letzten Tagen ausschließlich hashtags in ihren changeset comments schreiben. USA 1 Norway 0 India 0 Brazil 0 Philippines 6 China 0 Indonesia 2 Nepal 5 Congo 3 Russia 0 Vietnam 1 Somalia 0 Zambia 6 Japan 0 UK 0 Germany 0 France 0 Madagascar 3 Greece 0 Tanzania 1 Paraguay 0 Uganda 3 Bangladesh 6 Burundi 7
Durchsucht man die Länderstatistiken ab Rang 10 abwärts, verschlechtern sich die Ergebnisse.
Falls wir die „Richtlinien“ im Wiki weiterhin für beachtenswert halten, sollten Wege gefunden werden, wie diese auch durchgesetzt werden können.
sorry for the delay
unisex
amentity=toilets
Previously: 2021: Jan. Feb.
2020: Jan. Feb. Mar. Apr. May June July Aug. Sept. Oct. Nov. Dec.
I used a couple of services that sent me emails when a change was made in my area
They disappeared
Is there any alternative ?
