Diary Entries in English

Recent diary entries

Beginning in June of 2019, I began importing building footprints for counties inWisconsin. These were sourced from the State Cartographer’s office, and is part of a larger project of importing this data for other counties in the state.

osm.wiki/Wisconsin_Multi-County_Building_Footprint_Import

I finished Menominee county, have added all areas not already mapped for Wood county, and have now started on Winnebago county.

Posted by deptho on 4 July 2019 in English.

Just noticed wiki.openstreetmap.org/wiki/Key:source suggesting the changeset should describe the source of the change rather than every object. I’ll reduce the number/type of objects in my changesets to make it easier to relate the changes to the changeset description/sources.

Some of you will remember - and will have participated in - a demographic survey i conducted almost two years ago which aimed to establish whether there were any differences between the genders in the way contributors edit in OSM. Since then I have conducted several analyses of the data I collected and shared the results at several conferences. Each of the these papers is available on my researchgate profile which can be accessed from the following link.

https://www.researchgate.net/profile/Zoe_Gardner4

I’m delighted to announce that the following peer reviewed paper titled “Quantifying gendered participation in OpenStreetMap: Responding to theories of female (under)representation in crowdsourced mapping”, based on the data I collected from the generous OSM users that participated, has just been published and is accessible online using the link below.

http://link.springer.com/article/10.1007/s10708-019-10035-z

See full entry

If you’re organizing an OpenStreetMap-related event, consider adding it to the wiki’s global OSM event calendar, which also appears in each issue of weeklyOSM. Even if you don’t expect to attract new attendees via the event calendar, it’s a decent way to raise awareness of your local community within the broader OSM community.

To add an event to the calendar, go to the Main Page and click the little blue ✏️ link at the top of the calendar. Follow the instructions on the edit page and click “Save changes”. Note that editing the calendar requires a free wiki account with a confirmed e-mail address. Otherwise it’d be too easy for spam to get in.

(If you’re organizing a regularly recurring event for a local community, you should also advertise it in the community index that appears after uploading a changeset in iD.)

Same great taste with half the punctuation

The event calendar has been rewritten to make it easier for non-programmers to contribute new events. In the past, adding an event to the wiki’s event calendar meant editing delicate HTML microformats and idiosyncratic templates. But more realistically, it meant copy-pasting an existing event and hoping for the best. Now a single template handles the implementation details for you, so you can focus on the details that matter.

Before:

|-class="h-event"
| {{Cal|pizza}} || {{Dm|y=2019|Feb 7}} || <span class="p-name">[//www.meetup.com/Code-for-San-Jose/events/256761257/ Civic Hack Night & Map Night], [[San José, California|San José]], [[California]], [[United States]]</span> {{SmallFlag|USA}} {{SmallFlag|California}}

After:

{{Calendar/event
| type = pizza
| date = 2019-07-11
| name = Civic Hack Night & Map Night
| url = //www.meetup.com/Code-for-San-Jose/events/261576831/
| city = San José
| citylink = San José, California
| region = California
| country = United States
}}

See full entry

Location: University, Dinkytown, University, Minneapolis, Hennepin County, Minnesota, United States
Posted by ashish123 on 30 June 2019 in English.

In pt-assistant my next task is to improve the visualization. as route relations make a spider-like structure so visualization of relations becomes too tough. So the task is to break the route relations into segments where each segment serves a bunch of relations and will be a collection of ways which are serving the same bunch of common relations. for complete details, you can look TaskManager

Posted by tchaddad on 29 June 2019 in English.

The GSoC project to add Wikidata to Nominatim is now well underway. This post will focus on the first phases that have centered on updating Wikipedia extraction scripts in order to build a modern Wikipedia extract for use in Nominatim. English Language Wikipedia logo

A little background

Why is Wikipedia data important to Nominatim? What many OpenStreetMap users might not know is that Wikipedia can be used as an optional auxiliary data source to help indicate the importance of OSM features. Nominatim will work without this information but it will improve the quality of the results if this is installed. To augment the accuracy of geocoded rankings, Nominatim uses page ranking of Wikipedia pages to help indicate the relative importance of OSM features. This is done by calculating an importance score between 0 and 1 based on the number of inlinks to a Wikipedia article for a given location. If two places have the same name and one is more important than the other, the Wikipedia score often points to the correct place.

See full entry

DigitalGlobe, now Maxar [1], is transitioning the OpenStreetMap imagery endpoints (from “DigitalGlobe Standard” to “Maxar Standard”; and from “DigitalGlobe Premium” to “Maxar Premium”). OSM users should see content parity between the old and the new layers by June 30, 2019. Starting July 1, 2019, there will be only two Maxar layers available from within the OSM editors – labeled with Beta.

Our new imagery services use http/2 protocol. Please note that there are some known speed issues with the JOSM editor. A JOSM plugin for http/2 support is expected before the end of July (ticket #17861). In the meantime, increasing the concurrent connections (e.g. to 20) will help. iD editor already supports http/2.

The good news: imagery will be more recent and more frequently updated with our latest Maxar mosaic content. We hope that our improved production processes (bundle block adjustment, atmospheric compensation, continuous updates, etc.) will benefit OSM contributors.

As always, thanks to everyone within OSM for all your support and feedback. Shout out to the maintainers and contributors for iD and JOSM who have been fantastic to work with. Look for Maxar at State of the Map and State of the Map US; we will be attending and presenting more information on this new image service. And please feel free to send us feedback. Happy editing!

[1] https://www.maxar.com/

Originally published here: https://atakua.org/w/landcover-conflation-unsolved-issues.html

This post continues where the previous one left off.

After some time spent on processing and importing land cover data, I have several ideas on how to further improve and streamline both the import process and in general work with land cover features in JOSM.

Suggested tools to help with land cover data

Certain typical tasks arise over and over again when one works with polygons meant to represent land cover, regardless of whether they are imported or manually traced. At the moment there are no adequate tools in JOSM to assist with such tasks.

The trick here is not trying to find an exact geometric solution to the tasks at hand, but rather imitate what a human would reasonably do to finish such a task. And a human would cut corners, allow some inexactness traded in for speed of completion.

Floodfill tool

A common task is to fill a gap between two or several polygons. An example would be to map a new farm field situated between several forests or clammed between several intersecting road segments. Currently one has to carefully trace a new way along the existing borders, either reusing nodes or leaving a small gap between the new ways and adjacent ones.

The idea here is similar to pouring a bucket of paint into the middle of the empty area and then letting it spread out naturally to fill the empty area. The paint will then spread out until it hits borders, or until it runs out of paint.

The same approach can be implemented in a tool that starts from a single node (or rather, from a tiny closed way) which then grows in all directions. Its growth is stopped when a segment of the new way hits a boundary in a form of an existing way. Optionally, the new way can then snap to existing way there.

See full entry

Introduction

This is the second post made regarding the Google Summer of Code 2019 progress. The first month is coming to an end and with it, the first 2 tasks as well. In this entry I will present what is new and what has changed, in regards to the first task as well as the work and decisions made on the second one. Exported images of demo renderings are also included at the bottom of this entry. You can see all the changes mentioned below in the pull request here
So, let’s begin:

Minor noteworthy changes on the 1st task

If you happened to follow my previous diary entry as well you may have noticed that it was mentioned that “Depending on their importance, I may include a brief of them in the next diary post”, referring to additional changes. Major ones are presented in the next paragraph below but I chose to also include the ones listed here; although they may not directly affect the flow/functionality of the program they still do play their role.
What is new:

  • Javadoc is created in important parts of the code such as the configureMaterial() method in TrafficSignModule and the File field in both TextTextureData (TTD) and ImageTextureData. The later Javadoc addition is to demonstrate the major differences these fields have despite their overall similarity.
  • Getter functions have been removed from TTD and its fields have been made public, following the concept of its parent superclass TextureData.
  • "osm2world" is now appended to every prefix of a temporary image created in TTD getFile() method as a way to help users understand where those new files in their systems came from
  • Last but not least, the hashCode() and equals() methods are now only defined in the TTD and ImageTextureData child classes instead of the TextureData parent one. Prior to that, an ImageTextureData object could be deemed equal to a TextureData one, as they used to bear the same fields, which should obviously not happen.

Major changes on the 1st task

See full entry

Posted by omgitsgela on 26 June 2019 in English. Last updated on 27 June 2019.

Did you just get a Chromebook, and excited to get mapping with it? You can run JOSM on Chromebook with a little bit of effort. This guide was written for ChromeOS 74.0.3729.159 and up and relies on the Debian Stretch 9 emulator Crostini. As you’re entering these commands, you can copy and paste them from the website to the Debian terminal by using a right click (or Alt + Click if you don’t have an external mouse connected)

Step 1 - Enable Linux Apps

Open the Settings app, and search for Linux. Click “Turn On” to enable Linux support. On the popup installer, click Install. Sit back and wait. When the installation is complete, a Debian Linux shell terminal will automatically open.

Step 2 - Add the JOSM repository

This command adds the JOSM repository to the sources list. echo deb https://josm.openstreetmap.de/apt alldist universe | sudo tee -a /etc/apt/sources.list

Download and register the OpenStreetMap public key. wget -q https://josm.openstreetmap.de/josm-apt.key -O- | sudo apt-key add -

Step 3 - Update the APT repositories and install

This will query updates to all packages, and install josm afterwards. This will take quite some time. Go grab a coffee. sudo apt update ; sudo apt install josm

Step 4 - Run JOSM

Open up JOSM within the App Folder “Linux Apps” from the launcher. It’s possible that JOSM could have too small a font to read on your screen. The fix is to install Java 11 and use UIScaling to render the applet with a larger font. If you wish to fix this and give JOSM a larger font, follow the next steps:

Optional Step 5 - Enable Backports

Debian Stretch doesn’t come with Java JDK 11 by default, but we can enable it by adding the backports software repository.

echo deb http://deb.debian.org/debian stretch-backports main sudo tee -a /etc/apt/sources.list

Optional Step 6 - Install JDK 11

See full entry

Originally posted here: https://atakua.org/w/landcover-conflation-practical-issues.html

This is the third part of summarizing my experience with conflation of land cover data for Sweden. More examples of practical problems and ways to address them follow.

The same or similar problems may or may not arise during other imports of closed (multi)polygons in the future, so tips and tricks to save time will become handy. Note that some points from the previous part may be repeated here, but with more thoughts or ideas on how to address them.

Why bother with land cover import

The general idea of importing any data into OSM is to save time on doing the same by hand.

Classic data sources for the OSM contents are:

See full entry

Hi to all,

I would like to introduce myself and share my interest of being part of HOTOSM board.

I have had the privilege to participate in various projects involving Humanitarian Mapping. As a volunteer I have been representing OpenStreetMap and HOTOSM in different forums and I am Co-Founder of the Geochicas initiative in the one we want to impulse more female presence in Geospatial technologies and increase the number of women adding Open Data in OpenStreetMap.

Most recently I participated as HOT volunteer in Guatemala. HOTOSM Team was supporting the Clinton Health Access Initiative and the Guatemala Ministry of Health to assist local technicians who are in the field all year fighting diseases such as Dengue, Zika, Chingkonkuña, and Malaria in the area of Escuintla. HOT arrived in Guatemala to support the Ministry of Health with the use of Open Data Kit (ODK) and OpenMapKit (OMK) in order to have a more detailed census and action plan using open source tools so the goal to eliminate malaria can be tracked and achieved by 2020. I participated in the training activities with the HOTOSM team.

Since 2014 I became fascinated with HOTOSM and OSM when I realized all the potential it could have to change people realities and how we can improve their lives so I started getting involved in the Open Data and Open Mapping world. In 2016 on behalf of HOTOSM I received the honor of being one of the 50 Digital Leaders of Mexico and last year INEGI (after a few years of exchanging communication with them) invited OpenStreetMap Mexico to be part of the Consulting Council to be able to review their strategy and tools before launching to the public.

See full entry