OpenStreetMap

Users' Diaries

Recent diary entries

Posted by mayanaut on 18 March 2024 in English.

I’ve been kind of bouncing around various projects the past week.

I have tentatively completed sidewalk mapping in Emsworth Borough, and have moved on to adding sidewalks and pedestrian crossings in Avalon. I also did a little revamp of the playground adjacent to the Avalon Elementary School. It turns out that as I was extending the sidewalk along California Avenue, I met up with some previously mapped sidewalk bits, which is nice. Although they have not added a lot of the tags I do, so I will circle back to make this area a little more seamless with what I’ve added to the west.

I’m planning to go through Ben Avon and Emsworth to tag pedestrian crossings and curbs a little more consistently; I had been changing the way I tag things as I went based on new information/methodology.

I got kind of distracted when I realized that Pittsburgh Botanical Garden needed some updating due to their recent renovations. I was able to add the new visitor center and update a lot of the concrete paths, but I have some question marks as to the accuracy of some of the other paths on the property. I will take some good GPX tracks the next time I am there (likely this week). I especially want to see what progress has been made on the feature that is to the southwest of the Lotus Pond. I will also try to acquire a more precise/accurate/official property map from PBG, because the pictoral one on their website is great for ordinary wayfinding, but wholly inadequate in precisely showing where things are.

Posted by SomeoneElse on 18 March 2024 in English.

There’s lots of data stored in OSM about bus stops, but often maps and apps created with OSM data don’t make much use of it (with OsmAnd being the notable exception). For here’s a bus stop as shown by OSM Carto:

Bus stop in York in OSM Carto

You can see that it’s a bus stop, and you’d be able to see the name if you could zoom in a bit more. However, in OSM there’s actually lots more information. For the map styles that I look after (both web-based raster maps and for Garmin devices) I tried to add a bit more detail. Here’s the result:

Bus stop in York at map.atownsend.org.uk

The bus stop icon has several extra elements that can be varied. The main part is the bus - still present but disused stops get a black “x” instead. Most bus stops have a pole. and that is shown to the right. The “r” indicates that there’s some sort of real-time display at the stop and the “s” that there’s a button that people can press to hear an announcement saying when the next buses are due. A “t” is shown if there’s just a timetable. The stop name itself is composed of several components - the name field itself, and also if set ref and naptan:Indicator, often “opp” or “adj” in the UK.

A feature of bus stops in my local area is that most also have a QR code of the form http://deps.at/?32900012, which redirects to a website for that stop that shows the same information as on real-time displays. The parameter is the naptan:NaptanCode. Unfortunately this doesn’t work for all stops, so I’ve manually added the website locally only where it actually works. The website is shown on the stop when you zoom in.

Bus stop showing website

The full variety of symbols can be seen in the legend here. Zoom in to see larger icons.

Several tags are used to decide whether a bus stop pole is likely to be there or not, and I’ve used "physically_present=yes is used on disused bus stops to indicate that a pole exists but they’re not in use. Some in my local area are signed as not in use, but the majority are not - the only indication is uaully the lack of a timetable.

Newer buses locally do have displayed and spoken announcements of stop names on board, but sometimes the name on the stop, the name displayed on the bus and the name announced on the bus are all different - see for example here and here. I’ve used bus_display_name and bus_speech_output_name where these differ. I made those last two names up; I couldn’t see anything at taginfo and a mailing list post didn’t generate any other suggestions. If either of the other names isn’t contained within the main one, I’ve appended them to the end, like this:

Bus stop with multiple names

Of course, if someone can suggest a better tag for these names I’m all ears (but not alt_name or some semicolon=separated monstrosity as neither of those would explain which name is which).

Maps for Garmin are similar, except that relevant information is appended to the name directly. Also note that a number of Garmin devices such as older Garmin Nuvi satnavs (and presumably newer Garmin drive ones) support speech output directly.

Location: Leeman Road, Holgate, York, England, YO26 4YB, United Kingdom

Today I decided to introduce a new format for sharing OpenStreetMap-NextGen development progress with the community. I’ll post weekly/bi-weekly updates highlighting changes and the current project status. Since this is the first update, I’ll cover some recent highlights.

You can subscribe to my diary updates on RSS: link.

New Settings Page (⭐ Highlight)

New settings page screenshot

I’ve begun migrating the settings/preferences section. My goal is to streamline this experience, as I’ve found the current system a bit complex. Surprisingly, many users don’t know it’s possible to change the default editor — I want to make this more obvious.

A new menu on the left of the screenshot (hidden, not yet finished) will provide clear navigation between general, 2FA, OAuth, and other settings.

This page is still work in progress. I intend to add a help text explaining how to contribute to translations and that the translations are made by the community.

Image optimization logging output, console screenshot

This screenshot highlights a new image optimization algorithm, which uses a binary search-like algorithm to find the perfect image optimization configuration in limited amount of steps.

Last Week’s Progress

I am heavily focused on migrating the HTML templates and pages. I believe it is a critical step towards opening up the NextGen codebase to new contributors. Without those (mostly) functional pages, it is difficult to add new features or improvements.

The following templates have been worked on:

  • /welcome - finished
  • /fixthemap - finished
  • email base template - finished
  • email signup confirm - finished
  • /settings - work in progress

I have additionally addressed issues that lead to some issues with API endpoints, as well as worked on frontend and backend optimizations. You can see the full breakdown in the repository commits log. I keep my work completely transparent.

OpenStreetMap Website Vulnerability Report

I finally published my OpenStreetMap website vulnerability report. I conducted this security audit while studying the website source code, which was a mandatory step to preserve backwards compatibility.

Some of the highlight findings is a security flaw allowing an attacker to blindly reply to any private message as anybody. Another surprising finding is that the Ruby website stores user authentication tokens in plain text. If an attacker had gained access to the server where these tokens were stored (with just read access), they could have potentially compromised a large number of accounts.

All of the vulnerabilities have already been fixed or are being fixed in the NextGen implementation.

OpenStreetMap NextGen Benchmark 1 of 4: Static and unauthenticated requests

I have recently published the first benchmark of the OpenStreetMap-NG. It focuses on measuring static and unauthenticated requests as this code is fairly stable unlikely to be changed. Future benchmarks will include more realistic scenarios.

I compared the results with the current Ruby website implementation. I faced issues with reproducing deployment scenario on my local machine due to outdated documentation (and since I am a Ruby-noob, I couldn’t fix it myself).

Despite the imperfect benchmarks, I believe the obtained numbers hint at the potential performance gains of NextGen’s codebase.

🦀 Project Sponsors

In my development diaries, I want to include a dedicated section thanking my current project patrons. It’s through their support that I’m able to work full-time on OpenStreetMap-NextGen. Rather than focusing on the amount donated, I want to highlight the individuals themselves — it’s the gesture that is the primary driving factor.

Currently, my work is sponsored by 2 patrons on Liberapay, including one private donor, and one public donor with the mysterious looking username ~1847430.

Thank you to both of you, you made me smile 😋.

If you’d like to join my development sponsors, you can find me on Liberapay or GitHub Sponsors. Currently, all contributions go directly towards the development of OpenStreetMap NextGen.

Donate using Liberapay

Disclaimer

Please note that this project is not affiliated with the OpenStreetMap Foundation. It’s the result of my voluntary work and personal choices.

Eco Mappers OSM Rwanda ODD,

As we commemorated International Open Data Day and International Women’s Day, we embarked on a journey to intertwine these essential themes for equitable development. On Saturday, March 9, 2021, amidst a global celebration of Open Data Day, our event in Rwanda stood as a beacon of empowerment, bringing together over 50 enthusiastic participants eager to delve into the world of open data.

Before delving into the event’s highlights, it’s crucial to acknowledge the significance of Open Data Day. With more than 60 events worldwide, it underscores the global community’s commitment to promoting open data’s usage and accessibility. Thanks to the support from key funders, including the Open Knowledge Foundation, these events serve as catalysts for change, fostering collaboration and innovation.

Ahead of our event,

we conducted a survey to gauge participants’ understanding of open data. This initial assessment laid the groundwork for tailored sessions aimed at bridging knowledge gaps and empowering participants, particularly Rwandan women, in leveraging open data for societal progress.

During the event,

we focused on equipping Rwandan women with insights into their current roles and future prospects in the open data landscape. Drawing inspiration from success stories of young Rwandan women in the field, we showcased the transformative power of open data initiatives. By highlighting these narratives, we aimed to inspire and empower women to actively engage in projects championing equality through data-driven approaches. Alt text

Reflecting on the event,

several lessons emerged, offering valuable insights for future endeavours. Firstly, we learned that inclusivity is paramount in fostering equitable development. Regardless of one’s background or prior knowledge, there’s always room for individuals to contribute meaningfully to open data initiatives. By providing accessible information and creating welcoming spaces, we can effectively engage citizens in driving societal change.

Furthermore, our experience highlighted the importance of fostering a supportive community for women in open data. In Rwanda open community, we witnessed a diverse landscape of women, ranging from newcomers to seasoned veterans, each contributing unique perspectives and initiatives. Facilitating platforms for knowledge sharing and collaboration among these women is essential for nurturing talent and fostering innovation in the pursuit of equal development.

Alt text

As we navigate the evolving landscape of open data and women empowerment, it’s imperative to remain committed to our collective goal of creating a more inclusive and equitable society. Through initiatives like OpenStreetMap and Eco Mappers Rwanda, we continue to harness the journey in open Mapping in 3 Planetary Crisis , (Climate change, Biodiversity loss and Pollution) to Influence future Resilient Rwanda through youth open mapping participation. Since power of data drive positive change, empower marginalized communities, and pave the way for a brighter future.

In conclusion,

Our event served as a testament to the transformative potential of open data and the pivotal role of women in shaping its future. As we celebrate our achievements, let us thank and appreciate all the Men who are always theirs to push the agender of promoting Women in geospatial tech and the open data representation Intentionally, let us remain steadfast in our commitment to harnessing data for the greater good and advancing the cause of equality, one map at a time. https://upload.wikimedia.org/wikipedia/commons/1/1f/International_women%27s_day_2024_Celebration_in_Rwanda_and_Open_Data_Day778.jpg International women's day 2024 Celebration in Rwanda and Open Data Day778

93International women's day 2024 Celebration in Rwanda and Open Data Day

Posted by TrickyFoxy on 17 March 2024 in English.

Looking at the OSM map on website of the university:

Looking at photo:


I look at my yard in MapComplete, and there are some stalls on the road:

I look out the window (well, so that you can see it too, on yandex.panoramas):

You open Rapid and calm down: This is what the AI recognized. Everything is fine with OSM.

But the mapmakers took a wrong turn. Why do you need AI buildings in cities that are mapped by cartographers?!

But the mapmakers are happy with that. This is a long time ago Google with auto-recognition showed.

Смотришь на OSM-карту на сайте универа:

Смотришь на фотографию:


Смотришь на свой двор в MapComplete, а там ларьки какие-то на дороге стоят:

Смотришь в окно (ну а чтобы и вы увидели, на яндекс.панорамы):

Открываешь Rapid и успокаиваешься: это AI нараспознавал. С OSM всё в порядке.

А вот картоделы свернули куда-то не туда. Точнее их всё устраивает. Это давно гугл с автораспознаванием показал.

Last quarter, a “getting to know you” survey was made available to the local OpenStreetMap (OSM) communities in the Philippines, to help us better understand the current state of the active contributor base of our community.

The original idea was to run it just for the membership of local YouthMapper Chapters (YMC), but eventually it was made available to anyone who contributes to OSM in the Philippines, here or abroad, regardless of citizenship or affiliations.

I’m sharing my observations from the responses made by the participants who participated in the survey, again, majority of whom comprised of local YMC respondents.

Click on the images, to open them in full resolution in a separate tab.


Are you physically present in the Philippines?

While 86% of the mappers reported that they are physically in the country, mappers coming from elsewhere at 14% was bigger than I expected.

Are you in PH?


Which of the following best describe your primary undertaking in the OSM project?

61% of respondents identify as “Editor/Mapper”, and it’s intriguing to see quite a number identify as “Advocate/Promoter.””


Re-arrange the following (community, project or brand) that you tend to associate more with.

The majority of participants identified with the “YouthMappers” brand, and a close second was “OpenStreetMap Philippines.”

This is probably more of an indication of participants associating with local, more familiar brands.


Re-arrange the following based on how you typically use OSM data/map

The users ranked the following as their top three choices: “OpenStreetMap.org as general web map”, and “GIS data source”, and “Data Visualization”


What’s your age?

The majority of the respondents are young contributors, and reflects the profile of the majority of the respondents: the YMCs.


Do you prefer any personal pronouns?

Most respondents don’t appear to prefer less of the traditional pronouns, but it’s gratifying to see numbers showing that the difference between those who chose “She” and “He” are not significant.

I suppose it can be said that Women are very active and engaged in the local communities.


How do you usually edit OpenStreetMap data?

This result was beguiling: 79% of the respondents reported either “Always” or “Often” using a PC/Laptop when editing OpenStreetMap. Meanwhile, from what I remember from previous global surveys of OSM respondents, it’s been reported that the majoirty of OSM contributors are editing on phones or other mobile devices.

The use of a PC/Laptop is also reflected in their choice (or familiarity) of editors. iD and JOSM are more familiar compared to any of the mobile editing apps mentioned in the survey, where most respondents answered “Rarely or Never”, or “Unheard of” when asked about these apps.

I suspect that the higher number of users who reported iD as “unheard of are simply unfamiliar with the name reference. It’s the default editor for OSM, and a big chunk of editors simply just start with them, and rarely refer to itself as “iD”.

In hindsight, an appropriate follow-up to this particular question should’ve been asking about the frequency of their OSM editing sessions.


Editing device: Computer vs Mobile


Favored OSM editor (Computer)


Favored OSM editor (Mobile)

EveryDoor takes the top prize, with OMaps and Osmand tied for second, for “Always/Often” category.

Theme Always / Often Sometimes Seldom Rarely or Never Unheard Of
EveryDoor 12 9 16 19 17
GoMap! 5 1 10 31 23
Organic Maps/Maps.Me 9 10 13 23 18
OsmAnd 9 6 12 25 20
MapComplete 5 6 10 25 27
StreetComplete/StreetComple_EE (SCEE) 6 4 10 26 26

What motivates you to contribute data to OSM?

The top motivation is “Learn/Improve my technical/mapping/GIS skills”, followed by “Contribute to Open Data / Philosophy”


What hinders you from editing OSM more than you want to?

For 86% of respondents, their primary impediment is “Not enough free time,” followed by “Inexperience/Skill Level”.

Not having enough time (for anything, really) is a difficult issue to address, but the second choice is actionable, if the local communities or volunteers can find the time to create training or mentorship opportunities.

The next deterrent, “I don’t know what to map” could be addressed by improving how we communicate or promote on-going mapping initiatives, but also by matching them with the interest of the contributors. Low interest = low engagement, which is also reflected by the 11 respondents who chose “Uninteresting challenges/mapping projects”


How likely are you going to contribute/participate in the following OSM data improvement themes in the Philippines?

The top 5 themes, according to respondents: 1. Add/Review Placenames 2. Address Improvement 3. Barrier/Access Tagging 4. Photo-mapping 5. Review buildings with typhoon-damaged tag


Poll results
Theme 1 3
Address Improvement 1 0 10 30 28
Add/Review Placenames 1 0 9 23 37
Administrative boundaries mapping 1 3 14 22 30
Barrier/Access tagging 0 2 10 28 29
Bridge Mapping 0 3 16 22 28
Close/resolve open Notes 1 6 25 21 15
Fix Nominatim QA issues 3 5 32 13 16
PHL island/islet, nodes to polygons 3 5 16 22 23
Photomapping 1 5 10 20 34
Review buildings with typhoon-damaged tag 2 5 9 20 33

¹ - “Not at all” ² - “Neutral” ³ - “Extremely likely”


Where do you get information/updates/help about OSM?

The majority of respondents get their OSM information and updates from traditional SNS, and the Open Web, using search engines.


OSM started 19 years ago (as of 2023). How long have you been actively contributing to the project?

Roughly one third of respondents have been mapping for 6 months or less, and another third has been mapping in OSM for 1-3 years.

That’s an interesting, rich mix of new and experienced mappers working in improving OpenStreetMap in the Philippines.


That’s the extent of the survey.

I look forward to the OSM-PH communities discussing this further, considering these insights, and adopting strategies to further improve our efforts to deepen our engagement within our communities.

../

Posted by Raquel Dezidério Souto on 16 March 2024 in Portuguese (Português).

🍾 YouthMappers UFRJ celebrates its first year!


Ler em português

The YouthMappers UFRJ (Rio de Janeiro, Brasil) completed one year on March 14th, 2024.

And to celebrate this special date, we interviewed Dr. Rogério Luís R. Borba, analyst at the IBGE Foundation and manager of the Brazilian Geospatial Data Directory (“Diretório Brasileiro de Dados Geoespaciais, DBDG) of the Brazilian National Spatial Data Infrastructure (“Infraestrutura Nacional de Dados Geoespaciais”, INDE).

🎥 Watch on IVIDES.org’s YouTube channel.

entrevista_youtube

Rogério talked to us about the importance of open data and how the collaborative mapping can helps Brazil in the production of official cartographic data. The interview was conducted by Dr. Raquel Dezidério Souto and all details can be found at:

🔗 https://ivides.org/youthmappers-entrevista-rogerio-borba

imagem_entrevista

The YouthMappers UFRJ chapter is an open collaborative mapping initiative, result of a partnership between the Virtual Institute for Sustainable Development - IVIDES.org and the Laboratory of Cartography - GeoCart-UFRJ, chaired by Dr. Raquel Dezidério Souto.

IVIDES_logo

youthmappers-ufrj

🍾 YouthMappers UFRJ comemora 1 ano de registro!


Read in English

O capítulo YouthMappers UFRJ (Rio de Janeiro, Brasil) completou, no dia 14 de março de 2024, 1 ano de registro internacional.

Para comemorar esta data especial, entrevistamos o Dr. Rogério Luís R. Borba, analista da Fundação IBGE e gerente do Diretório Brasileiro de Dados Geoespaciais (DBDG) da Infraestrutura Nacional de Dados Espaciais (INDE).

🎥 Assista no canal do IVIDES no YouTube.

entrevista_youtube

Rogério conversou conosco sobre a importância dos dados abertos e como os mapeamentos colaborativos podem auxiliar o Brasil na produção de dados cartográficos. A entrevista foi conduzida pela Dra. Raquel Dezidério Souto e os detalhes podem ser conhecidos em:

🔗 https://ivides.org/youthmappers-entrevista-rogerio-borba

imagem_entrevista

O capítulo YouthMappers UFRJ é uma iniciativa de mapeamento colaborativo aberto, fruto da parceria entre o Instituto Virtual para o Desenvolvimento Sustentável - IVIDES.org e o Laboratório de Cartografia - GeoCart-UFRJ, sendo presidido pela Dra. Raquel Dezidério Souto.

IVIDES_logo

youthmappers-ufrj

Posted by NorthCrab on 15 March 2024 in English. Last updated on 18 March 2024.

As part of my commitment to OpenStreetMap-NextGen migration, I undertook a comprehensive security review of the existing OpenStreetMap website. I followed the principles of coordinated vulnerability disclosure, working directly with the maintainers to responsibly report my findings. Today, I’m making the details of this process public and verifying the status of the fixes.

Disclosure Timeline

  • 2023-11-04 - Contacted Ruby security maintainers & disclosed the timeline publicly
  • 2023-11-08 - Maintainers acknowledged the report
  • 2023-12-04 - Reported additional vulnerabilities with a 3-month deadline
  • 2023-12-06 - Maintainers acknowledged the additional report
  • 2024-03-02 - Publicize vulnerability details
  • 2024-03-15 - Publicize vulnerability details

1. Plain-Text Authentication Token Storage

Authorization tokens (oauth, session, user tokens) are stored in plain text. Read access to the database allows full impersonation of any user.

Status as of 2024-03-15: Partially vulnerable (oauth still depends on plain text storage)

NextGen Codebase Status: Fixed (all authorization tokens and credentials are hashed or encrypted for secure storage)

2. Insecure Email Reply Address Tokenization

The tokens used to ensure the authenticity of email replies are too short (24-bit), making them susceptible to brute-force attacks. An attacker could potentially guess the token and impersonate a legitimate user in email conversations. This vulnerability is especially dangerous if the attacker already has access to a conversation’s metadata (allowing for complete security bypass).

Status as of 2024-03-15: Fixed (now with 48-bit security)

NextGen Codebase Status: Fixed (128 or 256-bit security; undecided)

3. Unbounded GPX Extraction Denial of Service

The OpenStreetMap website does not impose limits on the number of files that can be extracted from a GPX archive. Attackers can exploit this by uploading specially crafted archives containing a massive number of files, potentially overwhelming the system and causing it to crash.

Status as of 2024-03-15: Mostly vulnerable (a partial fix limits points within trace files but does not fully address the issue)

NextGen Codebase Status: Fixed

4. Notes Search Query Denial of Service

The /api/0.6/notes/search endpoint is poorly optimized. This allows attackers to craft specific search queries that are extremely resource-intensive, effectively using the search feature to launch a denial of service attack.

Status as of 2024-03-15: Vulnerable

NextGen Codebase Status: Not yet tested

5. String Comparison Timing Attack

The way the code compares strings can, under certain circumstances, leak timing information. When attackers can carefully measure these timing differences, they might be able to extract secret information, such as security keys and tokens.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Fixed

6. User Block and Rate Limit Bypass

A loophole exists where a malicious user can repeatedly delete and recreate their account (using the same credentials) to circumvent security measures like user blocks and rate limits.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Not yet tested

7. Application Preference Leakage

OpenStreetMap allows different applications to store user preferences. A flaw exists where any application can access preferences created by a different application. This could leak information, and might be abused to attack other vulnerable applications that mistakenly trust data stored in user preferences.

Status as of 2024-03-15: It’s intended behavior

NextGen Codebase Status: Fixed (in API 0.7; via optional preference partitioning)

8. Unrestricted Email Checking via Password Recovery

The password recovery feature can be abused to check if any arbitrary email address is associated with an OpenStreetMap account.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Fixed

9. Forced Downgrade from OAuth1.0a to OAuth1.0

Under specific conditions, the authentication protocol can be downgraded from the more secure OAuth1.0a to the less secure OAuth1.0. This downgrade would omit important security checks.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Fixed

10. Insufficient User Token Integrity Checks

Tokens, used for things like password resets or confirming email changes, aren’t properly differentiated. An attacker might be able to use a password reset token to change an email address, or vice-versa.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Fixed

11. Inadequate Randomness Source in Token Generation

The system generating security tokens relies on a weak source of randomness. Predictable tokens are much easier for attackers to guess or manipulate.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Fixed

12. Unicode Normalization Flaw Allowing Email/Display Name Duplication

The lack of Unicode normalization means a user can register with an email address or display name that is identical to an existing one (but uses different Unicode characters). This could be used to trick users or bypass database restrictions.

Status as of 2024-03-15: Fixed

NextGen Codebase Status: Not yet tested


Support the NextGen development

I work on the OpenStreetMap-NextGen full-time. If you find my work valuable, please consider supporting the development on Liberapay or GitHub. Every contribution helps push us closer to that first stable release. Thank you! 🦀

And a huge thank you to those who have already supported me!

Submit a correction

If you find any inaccuracies or have suggestions to improve this diary, please feel free to contact me via https://monicz.dev/#get-in-touch.

Disclaimer

Please note that this project is not affiliated with the OpenStreetMap Foundation. It’s the result of my voluntary work and personal choices.

Posted by Tommy Hoang Long on 15 March 2024 in English. Last updated on 19 March 2024.

Apparently, OSM in Vietnam is in a very poor condition. And one of the reasons would be the absence of several nature reserve areas, even compared to the two neighboring Indochinese brothers, Laos and Cambodia. Despite the fact that the Department of Forestry has published a document stating that there are 34 national parks and 56 nature reserves, until now (15 March) only half of them have been mapped to OSM.

Here’s the list:

National parks

Nature reserves

Nature reserves with official “Nature Reserve” title

Official “Nature Reserve” title refers to the fact that these areas have their own management board (ban quản lý) and is usually a division of the provincial departments of agriculture and rural development (Sở Nông nghiệp và Phát triển Nông thôn). These includes:

Nature reserves with informal “Nature Reserve” title

  • An Toàn
  • Bà Nà - Núi Chúa
  • Cham Chu
  • Chí Sán
  • Copia
  • Hữu Liên
  • Krông Trai
  • Na Hang
  • Nam Ka
  • Ngọc Linh (Quảng Nam)(*)
  • Nà Hẩu(*)
  • Sơn Trà
  • Sốp Cộp
  • Thần Sa - Phượng Hoàng
  • Tiền Hải
  • Tà Xùa
  • Tây Côn Lĩnh
  • Vân Long
  • Xuân Nha
  • Đồng Sơn - Kỳ Thượng
Posted by ENGELBERT MODO on 15 March 2024 in French (Français).

Please also share/blast in your socials/network :)

—— 👂👀 Have you heard? 📢 We have launched 🚀 the #OSMFMembershipCampaign 2024!

Help us grow and diversify #OSMF members in regions 🌍🌏🌎 where there are no or very few OSMF members! You can support! 🎯 https://blog.openstreetmap.org/2024/03/12/call-to-action-help-us-grow-and-diversify-osmf-membership/

Join ✍️https://supporting.openstreetmap.org/#Membership-Categories

openstreetmap

presentation of the Mapeaia Belém project to the Brazilian Openstreetmap community

we present the Mapeia Belém project to the Brazilian openstreetmap community, which is an initiative of UMBRAOSM União dos Mapeadores Brasileiros do Openstreetmap and partners such as Meninas da GEO, Capitulos Youthmappers and other groups and in addition to the Brazilian Openstreetmap community and aims to update data in city ​​of Belém for the Major Events that the city will host in 2024 and 2025 such as FOSS4G and COP 30.

Official launch of the project maps Belém in the Legal Amazon in 2023

MAPATHON activities we did in 2023 and 2024

activities on March 6, 2024, Open Data Day (ODD) 2024 - Belém - Pará Brazil.

the presentation of the Mapeaia Belém project can be seen at the link below; https://umbraosm.com.br/apresentacao_do_Projeto_Mapeia_Belem_na_amazonia_legal.pdf

https://wiki.openstreetmap.org/wiki/Pt:Projeto_Mapeia_%22Bel%C3%A9m%22_Edi%C3%A7%C3%A3o_2023/2024

project website

https://projetomapeiabelem.my.canva.site/home

UMBRAOSM - União dos Mapeadores Brasileiros do Openstreetmap

www.umbraosm.com.br

Location: São Brás, Belém, Região Geográfica Imediata de Belém, Região Geográfica Intermediária de Belém, Pará, North Region, Brazil
Posted by Infra-Simon on 14 March 2024 in German (Deutsch).

Hallo zusammen,

ich habe auf der Arbeit die Aufgabe das Parken in Frankfurt mithilfe des Rapid Editors zu taggen. Dafür möchte und soll ich so präzise wie möglich vorgehen. In vielen Straßen kommt es aber vor, dass verschiedene Parkrichtlinien oder Ausrichtungen bestehen. Außerdem sind einige Straßen sehr lang in OSM.

Eine Möglichkeit ist, die Straßen mithilfe eines Punkts zu teilen, um verschiedene parktags einzufügen. Das zerstückelt aber oft die Straßen und es entstehen kleine Teilstücke mit verschiedenen ID’s. Die zuvor eingefügten Attribute bleiben aber bestehen.

Jetzt ist die Frage, welche Folgen es hat, die Straßen aufzuteilen, um präzise Parkangaben tätigen zu können, oder ob das keine wirkliche Rolle spielt. Viele Straßen sind ja sowieso schon sehr aufgestückelt.

Über eine Antwort würde ich mich sehr freuen.

Gruß Simon (Infra-Simon)

Location: 60322, Nordend West, Innenstadt 3, Frankfurt am Main, Hessen, Deutschland

Algumas mudanças feitas para quem vive em Contagem: coloquei a barraca do Tio toninho em frente a prefeitura, algo que está a anos e não se foi notado no mapa. E algumas coisas em torno de Minas Gerais. Vou fazendo mudanças as quais considero necessárias. Bom mapeamento a todos!

Some changes made for those who live in Contagem: I placed Tio Toninho’s tent in front of the city hall, something that has been around for years and was not noticed on the map. And some things around Minas Gerais. I’m making changes that I consider necessary. Good mapping everyone!

Posted by Robhubi on 13 March 2024 in English.

The key “name” is one of the 10 most frequently used characteristics of objects - according to Taginfo 100 million times. It is probably also the tag with the most errors. A random sample in my neighbourhood showed an error rate of 8.4% (N=1092). Possible reasons:

  1. lack of knowledge
  2. misunderstanding
  3. tag missing

The proposal relates to point 2, possible misunderstandings regarding the meaning of the “name” tag.

Current Wiki structure

The main article names lists 14 different keys of the proper name, differentiates them from each other and from non-proper names and gives many examples. The article is quite extensive with 29k characters.

Of the 14 keys, 5 keys do not have their own wiki page: int_name, loc_name, nat_name, reg_name and nickname.

The article on the key name is similar to the main article names, only somewhat shorter. It is still quite extensive with 18k characters. All other articles are short.

Issues Main article “names”

Readability.

The text is very extensive and therefore requires perseverance. However, it deals with all aspects of name keys in detail and consistently. Many examples illustrate the basic idea.

Issues key:name

Readability, redundancy, clarity.

The text for the key name is very long at 18k characters, the essentials are lost in the sea of words. Much of it is a repetition of information that is already available elsewhere:

  • The “values” section is almost completely contained in the main article.
  • The “Variants” table is already completely contained in the main article.
  • The table of language subkeys covers more than 3 screen pages and is also fully covered on the “Multilingual names” page.
  • The sections “Road names” and “Additional data” are also already included in the main article. Only the sentence with “strapline” is supplementary.

In addition to the high redundancy, the text is also blurred. The core - the proper name - is not mentioned at all. The explanations lead to problematic statements.

An example. Quote:

sources of primary names: The most prominent name on a sign posted on the feature itself, especially for a feature in the built environment

So this building should be tagged with name=Toaletter?

(zoom)

Clearly wrong, as it contradicts the main article.

A second example. Quote:

As a rule of thumb, the primary name would be the most obvious name of the feature, the one that end users expect data consumers to expose in a label or other interface element.

This statement is nowhere to be found in the main article. The wording is also ambiguous, are we tagging according to reality or according to the wishes of the data consumer? The latter seems to apply here:

(zoom)

The data consumer may be happy with the name “Green Walk (Easy Access)”, but it is not a name in the sense of the main article.

Another example. Quote:

This key is set to the primary name of the feature in the real world.

I read it like this: “primary name is the most commonly used name for that feature”. “primary” here denotes an order if there are several names. However, it says nothing about which names are involved. Names are multifaceted: class name, collective name, mass name, proper name … which name is meant?

The sentence should read: This key is set to the proper name of the feature in the real world. Or also: This key is set to the primary proper name of the feature in the real world.

Name “Toaletter” in the example above is then clearly excluded as a class name for the name key. In addition to class names, name-like descriptions are often misunderstood as proper nouns. No wonder, really, if the proper name is not defined as a term.

The term “primary name” is not used anywhere in the main article. The entire main article revolves around the term proper name, but it is only used explicitly a few times. It is strange why it remains completely unmentioned as a central term in the entire key:name article.

Did the authors understand the name as a synonym for the proper name? Or have I lost my way in the labyrinth of foreign language, everyday usage, grammar and linguistic philosophy?

One thing is for sure: I’m not the only one. The many errors in tag names scattered around the world are a clear indication.

Goal

Clarity.

  • Focus article key:name on the essentials, maximum text volume 1 to 2 screen pages
  • Intensive integration of the main article by means of references
  • Pay attention to translatability

Here is a text proposal as a starting point.

Non-goal

Change to the scope of meaning of the key name, neither restricting nor expanding. Reference is the main article names.

… and you?

What is your opinion: do you think the proposed restructuring makes sense?