Last summer I was deployed for the Humanitarian OpenStreetMap Team (HOT) Uganda project and wanted to share an account of some of my time in the field.

My past two years working on global health and development - in the epicenter of the field - Washington, D.C. - gave me a good understanding of the refugee crisis and the problems faced by displaced populations around the world. Or so I had thought.

There are currently estimated to be ~1.4 million refugees in Uganda. It is here that, after a 25 hour flight with two layovers and multiple anti-nausea tablets, I arrived, eager to work with the Humanitarian OpenStreetMap Team (HOT) to promote the mapping of refugee environments for humanitarian purposes. I spent my first few days getting oriented in the HOT office in Kampala, and thoroughly enjoying all the city has to offer (rolex stands need to make their way to the States, pronto!). We then headed north to Arua where the huge settlements of Rhino and Imvepi are located.
Shamillah and Allan, my amazing partners in crime

In Arua, our task was simple – we train refugee students and teachers on the OpenStreetMap (OSM) platform and mobile data collection in three secondary schools: Ofua Secondary School, Rhino High School, and Imvepi Secondary School. We set off from Kampala at 10 AM on Tuesday. Two car breakdowns, a driving ticket, a taxi, and 15 hours later, Shamillah, Allan, and I finally arrived. Pushing our broken car out of the road!

Over time, I have come to value experience over theory. No amount of rote knowledge can replace the understanding your senses provide you. Read all the poetry in the world, but until you experience love, you do not know what it means to find home in another being. Study music theory all you want, but it can never invoke the feeling of transcendence that the sound of a sitar brings with it. The refugee crisis is no exception. Nothing prepared me for witnessing the aftermath of the mass migration of people fleeing war and conflict.

A bit more about HOT’s mission before I continue: HOT, through training local communities and authorities, promotes the utilization of OSM. This is a free ‘wiki’-style map, which can be used by anybody with a log-in to trace and tag satellite imagery from various sources to help identify important features of any area, contributing to a fully mapped globe. HOT also utilizes a mobile application called OpenDataKit (ODK), which surveyors use to collect GPS coordinates and attributes of various points of interests (i.e. schools, hospitals, water points, latrines, etc.) that are then fed into OpenStreetMap for public consumption. Introducing these tools to refugee schools was something I was particularly excited about because they not only exposed refugee communities to new technology, but also provided them with a sense of ownership and accountability of their living and work spaces.

Trying to explain GPS coordinates to students. I thought I was making sense…

Shamilah, Allan, and I spent the next three days visiting the schools and training both teachers and students on these two facets of our work. Our first training site, Afua Secondary School, presented the unique challenge of working (in ICT) without a power source. Since we were not able to project the website and guide the trainees as easily as we would’ve liked, Allan improvised, using his amazing drawing skills to replicate the web interface on the chalkboard and direct the students that way. Luckily, power was available at our next site, Rhino High School, so we were able to use the projector. I still remember the energy in the room when we searched for the students’ hometown in South Sudan, Yei, on OSM. Hope, pain, longing, and awe all pervaded through the class as we virtually walked through the streets of Yei. Re-energized by the enthusiasm, we returned to the camps the next day for our final training only to find that due to miscommunication amongst staff members of Imvepi Secondary School, time had not been allotted for our visit - we unfortunately had to leave without training the students at that location…

I gathered my thoughts during our twelve hour bus ride back to Kampala, the city that had now become home. What exactly was I feeling? It took some mental poking and prodding but I finally pinpointed it to be frustration. We had just spent three days introducing interesting, helpful, and hopeful technology to students who it seemed many times did not even have access to power, much less computer labs. A one-off training in these circumstances would be limited in its ability to leave a lasting impact. Ignorance is bliss they say. Would introducing laptops and cellphones and selfies, opening these students’ eyes to such resources without a means to access in the future be doing more damage than good? After conversing with my team members about some of my reservations, I realized how aware HOT is of these issues and all it is doing to increase the sustainability of its work and its impact on the global community. HOT spends every last penny to continue these trainings, get people mapping for their own purposes, introduce this system to the NGO world, and skill citizens for employment. Furthermore, there is greater accessibility to mobile phones amongst refugee populations than I originally assumed. But it is still a battle.

Selfie time! The students absolutely loved being able to take pictures

Integration of the various humanitarian efforts underway in Uganda is a big first step to creating more sustainable benefits to the refugee community. While all humanitarian coordination in Uganda goes, in theory, through one channel, UNHCR, an increase in collaboration within and between the humanitarian sectors is necessary to identify needs which are not being met, and to direct resources in a more strategic manner.

There must be a greater push to coordinate efforts if we truly want to make a difference in refugee communities. Some of HOT’s maps of ‘community-witnessed services’ are now on the UNHCR Coordination Web Portal. HOT’s mapping endeavors, if properly utilized, are very helpful in identifying problems in the settlements that need to be taken into consideration when planning resource distribution. If the humanitarian sector at large adapts HOT’s maps into its planning process, there is the potential to greatly reduce the inconsistencies in aid dispersal and increase the impact interventions have in refugee communities.

One last note: seeing and hearing Ugandans’ warm and welcoming attitude towards refugees was such a breath of fresh air. I found Uganda to be a far less antagonistic host country than America, both in policy and in practice, despite its greater limitation on resources. America could learn a thing or two from Uganda on how to approach displaced populations…

All smiles outside Rhino Camp High School

Bonjour, Je n’arrive plus à modifier des données sur ma carte. pouvez vous me donner la démarche afin de pouvoir le faire? cordialement patrick hervet

Warning! High Geek Index (GI) ahead!

What the OSM Admin could be looking forward to each day

Brief Background
On 16 June 2019 I had yet another bruising encounter with the OSM Admin (“Oh look: someone has just opened a new issue from the OpenStreetMap Issues page. Let’s just — Click! — close that so that no-one else can comment on it”).

On the 12 June BloatedStreetMap had informed the world that the Map was way fatter than it needed to be. My naive vision for OSM is to help produce a map used by millions of people every day. That idea frightens the crap out of our Admin and, in response, they lock down the Map as hard as they can.

Here are the lines in the OSM robots.txt (dated Sat, 15 Jun 2019 23:55:12 GMT) that stop all legit Search Engines (SEs) from browsing the map (and thus, unless you already know about it you will never visit it):

Disallow: /*lat=
Disallow: /*node=
Disallow: /*way=
Disallow: /*relation=

Now, I understand why that is done, My point is that it could be different (item (2) in HiddenStreetMap). It all depends on what you want:– grow & expand or become a minor footnote in history. Anyway…

I took the lessons of BloatedStreetMap and used them to write out my first five issues in OSM ([1] [2] [3] [4] [5] [6]).

The admin were not interested in fixing [2] (HTML) nor [5] (XML). [1] (missing Last-Modified) was fixed the same day, and that actually also fixed [3] (static files) but not [4] & [6] (piwik.osm files). [6] was only there to point out to everybody that OSM was sending a webbug to everybody’s machines (despicable behaviour) so I concentrated on pressing to fix [4] (a JS file), which got done the following day. In the meanwhile I discovered that our Admin had already reversed the [1] fix.

Geeky Background
HTTP was initiated by TimBL in 1989. Between then & the introduction of HTTP/1.0 on May 1996 (rfc1945) every time that you clicked on a web-page it was sent to you, even if you had already viewed it before. After that date, and as long as both the server & your browser had updated, after receiving a 200 OK response from the server for the first time with a specific page, your browser stored a copy (“cache”) of that web-page on disk. The next time you clicked on the link, the browser checked for the page in the cache first. If the page was there the browser sent a conditional GET & if the server sent a 304 Not Modified then your browser showed you the page from the cache, which was far quicker than bringing it across the net. It also greatly reduced the load on the server.

Thus the interaction between browser & server became a Negotiation rather than just a Transaction, in which the browser found out whether the Cache that it already had was the latest version of the web-page or perhaps it had been updated. The point was that these new-fangled web-pages were becoming popular and also more complicated with more parts to them.

Some novel portions of HTTP/1.0 were HTTP Headers and the following Request/Response Headers (these are metadata rather than part of the HTTP Body):–

• Expires (response header)
• If-Modified-Since (request header)
• Last-Modified (response header)
• Pragma (request header)

That was hugely successful & was followed in June 1999 by HTTP/1.1 (rfc2616), the Content Negotiation of which was updated 2014 by rfc7232 and Caching updated 2014 by rfc7234.

Amongst the new 1.1 headers introduced were:–

• Cache-Control (request/response header)
• ETag (response header)
• If-Match (request header)
• If-None-Match (request header)
• If-Range (request header)
• If-Unmodified-Since (request header)

GZIP Encoding

Not yet mentioned but already available at HTTP/1.0 was the possibility of transfer-encoding, usually using gzip, an open-source method which can typically reduce a web-page by 70%, meaning that it takes only ⅓ of the time to transfer across the net.

ETag

You can tell that this is already very complicated and ETags, designed as a replacement for Last-Modified, raises the bar considerably. The description in rfc2616 is woolly (“provides the current value of the entity tag for the requested variant”) and suggests that it was brewed up near the end of a boozy lunchtime & afterwards, when sober, nobody could actually remember what it was supposed to be but they still went with it. Personally, I believe that it was a mistake to introduce them. After all, what’s wrong with a unique name?

In the modern era it is typical for a ‘server’ to actually be multiple servers physically located on different continents, and the DNS-response to the client will take into account their GPS location. That can become a problem, as Apache uses the file inode to produce a strong ETag, meaning that the ETag may vary between different servers storing the same file. Indeed, we will discover later on that Apache has more than one problem with ETags.

That should be sufficient to get the naïve yet intelligent reader up-to-speed sufficiently to understand the meat of what follows next. Now to begin to get into the heart of what the Title to this Diary is talking about.

W3C lose the Industry’s Trust

The W3C began to come out with more & more outlandish stuff, which caused everyone else to decide that they had lost their marbles. I shall give just two examples, both from CSS:

1. CSS1 Formatting Model
   This said that:

   The width of an element is the width of the content … The height is the height of the content

   …which meant that you had to add the .width + .padding + .border together to get to the width of the box (and then .margin separates that box from other boxes).
    
   If you think about that for a few moments you will realise that it is perfectly bizarre, and goes against all well-accepted layout practice at the time. Indeed, M$ Internet Explorer 5 on the PC refused to accept it, which caused almighty problems (their boxes were bigger than everybody else’s boxes).
    
   The other thing that it did was to cause most web-designers to use tables for layout, because tables revert to ‘normal’ layout rules in which the width of a box is the width of the box, and not the width of the contents of the box. Doh!  

2. CSS1 Line-Box Formatting
   This is part of the Inline elements section and receives little documentation in CSS1. In a nutshell, the W3C designers did not consult any print typesetters & trashed all the well-known rules established for Fonts over the previous few hundred years. They made it almost impossible to mix differing fonts on the page and obtain a professional result (in brief, css1 abandoned the font baseline as the common feature for all font-display).

In the face of such narcissistic behaviour, the browser operators established their own body and began to operate independently to the W3C. A good example of that brings us up-to-date & on-topic:

Cache-Control: immutable

I mentioned at the top of this little missive that I had recently reported that the OSM map was missing the Last-Modified header that would allow almost all pages to obtain the benefit of 304 Not Modified server responses as introduced to HTTP in 1996 ([1]), and that the OSM admin had first complained about my report & then immediately added the fix the same day; most of the files now showed a 304 on a simple refresh. Hooray!. However, the following day it all got reversed. Boo!

Using the Network | Headers page of the Web Developer tool for Handel Street under FireFox 60.7.0esr (64-bit) the Last-Modified had now been swapped for most peculiar eTag values (eg etag: “c4”). All static files (CSS, JS, etc.) now showed 200 OK, but that value was greyed out. I finally understood what was going on when I discovered & researched the following Response Header new value:

cache-control: immutable, max-age=31536000

The max-age is easy (“keep the cache for a year”), but what on earth was cache-control: immutable?

(more to follow)

The June solstice is upon us, which means the seasons are changing — and with that, lots of opportunities to map, no matter which hemisphere you’re in!

If you’re in the northern hemisphere, why not take a look at your local outdoor fun: maybe it’s swimming pools, beaches, hiking and biking trails, and the like. The parks and playgrounds might be busy, as well as sports pitches, places to camp, national parks, wildlife parks and more. Midsummer is also a holiday in many countries, why not map the local traditions like permanent maypoles? Or mapping your local ice cream parlours might be fun.

And if you’re in the southern hemisphere, it’s winter! It may be a bit colder, and good weather for winter sports like skiing, or maybe just staying indoors at your local pub, restaurant, indoor pool and so on. Are your local favorites on the map already? There are also winter festivals all over the hemisphere, have you mapped them? And in warmer climates, it may be nice weather for exploring outside, going surfing, taking road trips and more.

Speaking of the solstice, are the observatories and other astronomical facilities in your area mapped? Is the sundial of the cover photograph mapped?

You can also try recording GPS tracks or taking GPS-tagged photos of your outings to help yourself and others add more data to the map. Or you can even look for things named summer and help complete the map there! For example, the hamlet of Summer, Algeria, the Summer Palace in Beijing, the Summer Place pub in San Francisco and the Summer Hill Creek in Australia. Or maybe there are locations named Winter near you.

Do you have any other ideas for seasonal mapping? Let everyone know in the comments.

a melhor maneira de fazer estes entroncamentos e cruzamentos https://www.openstreetmap.org/edit?gpx=3018902#map=18/39.32868/-9.00256

Перевод свежего выпуска WeeklyOSM № 464 на русский - выполнен.

Обратите внимание на следующие моменты:

• Японский сервис “Machi-aruki Map maker“
• Размышления Мальвики Махеш об обозначении спорных границ на эл.картах и карту оспариваемых территорий мира
• Карта велодружелюбности Берлина

Building the map up

Thinking about how data is contributed to OSM, an interesting problem is how the detail and level of information is increased over time. Some things are quite easy to refine, but others are definitely not.

Adding basic data

This appears to be straight forward. OSM makes it easy to add some data. Things like tracing aerial imagery to add roads, residential land use, parks. It’s rough data quality, but is not a problem, as to put assumed detail in would not be so helpful.. In the UK, it is increasingly rare to have a totally blank canvas to start with. It feels like most of the coarsest data of roads and villages have been mapped.

Improving data

Once new data sets are available, like street level imagery, further granular detail can be added. The ability to refine the coarsely entered data varies a lot, depending on what it is. A building being determined as a place of worship, or simply a detached house is easily done. change the tag, draw the outline or adjust the bounds if needed. Adding an address.

You can do this on one building on a street and it is an improvement, even if you haven’t done the rest of the street.

Some cases where it falls down

A few examples I’ve seen through my own experience or via talk-gb is where useful data could be added, but unless it is entered to a high level of detail throughout the vicinity, and in its entirety, instead of enriching the map, it can hinder its use.

Sidewalks and pavements

I love this kind of information, but it is difficult to add. You can add it as a tag to a way, or as a separate way. There are many long standing differing of conventions of where to add this data and where not to. The topic of sidewalks/pavements merits its own post. In the UK, sidewalks are generally not added at all, or only added if the pavement is separated from the adjacent road by something else. Routing engines seemingly assume most roads (motorways excluded) as possible to walk along. With the exception of some major roads and motorways, there’s no legal reason not to thing that, but plenty of practical ones.

But the point here is, if you only add the pavement as a separate way (or as tags, even) to a single road in a neighbourhood, it needs a lot of detail up front. Without that detail, it can be found to be not useful, confusing routing engines, data extraction and humans reading the map.

The ease of humans reading the map is interesting. Mapping for the renderer is not a great habit, but presentation of data for users is important, such that you can’t totally ignore it. Yeah, the renderer should be fixed instead, but with half a dozen rendering engines dominating the usage, there’s some convergence of how tags are being interpreted and drawn.

Road Junctions

A simple junction might first be mapped as a couple or more ways intersecting. To enrich this data, you can fairly easily be converted into a roundabout, or add turning restrictions.

It gets more difficult once traffic signalling is to be added, and exceptionally more difficult to add in pedestrian crossing points - particularly if the pedestrian crossing is split to only cross one direction of traffic at a time. Pedestrian interfaces to the road junction are hugely important and useful to have mapped - in my opinion. No one likes to find they can’t cross over the road from one particular side of the junction and could have done so had they crossed onto the opposite pavement 100 meters earlier. Or having to cross 4+ lanes of traffic where a traffic island could have halved that.

This is not something that can be gradually added to a map. You need certain things to be at a suitable level of detail before you can meaningfully add this adjacent data.

I like that openstreetmap allows people to map the things that interest them the most, but there’s clearly a hierarchy of detail where some items enable others.

We are announcing the call for nominees for the OpenStreetMap Awards 2019, which will be presented this September at the State of the Map 2019 conference in Heidelberg!

These are community awards, as nominees and winners are chosen by the community. The Awards strive to be a worldwide event for all OpenStreetMap members, including developers, mappers, community leaders, blog writers and everyone else. We need your help to find the best of OpenStreetMap globally.

For the fourth awards, we have made some changes. Gone are the three regional categories. Sorry. We have strong enough OSM representation in these countries to be listed together with other candidates. Also, there is a new category: Team Achievement Award. Companies, teams and groups should go there, to not compete with people in other categories. We had quite a lot of issues because of that mixing previously: how do you compare a mapper and an entire local chapter?

We’re mostly looking for new innovations, so only projects/works that were announced after June 1st 2018 are eligible. The Ulf Möller Award is an exception to this. Everyone is eligible regardless of the time when they were active in the project. You personally and your friends are eligible, do add yourself! Winners of past awards and selection committee members (in their categories) cannot be nominated.

The call for nominees will close in a month — on 15th of July. Whenever you see an interesting entry on OSM diaries or in WeeklyOSM, take a moment to submit the name for the award. The more nominees we have, the more interesting the final voting will be. Please keep in mind that we have the OpenStreetMap Awards and nominate people now!

Hello HOT members,

Thanks very much for taking the time to click through, read, and consider my candidate statement for a position on the HOT Board of Directors.

My name is Rob Baker and I’m currently the Director of Human Security and Technology at the Harvard Humanitarian Initiative, located at Harvard University in Cambridge, MA, USA. Prior to joining the team here, I was located in Washington, DC for seven years where I worked as Lead Technologist for USAID’s Global Development Lab; the World Bank’s Innovation Lab, where I ran a team on open data; a White House Presidential Innovation Fellow, where my team and I installed the agency’s first CDO and created open data policy; and was COO of Ushahidi, having started with them as a volunteer in 2010 following the Haiti earthquake.

It was in 2010 when I got involved with OSM and when HOT launched. I contributed to mapping parties in Haiti and in Indonesia, working to help train local communities on not only the practice but the value of being seen on the map. In the years since, I was proud to represent HOT at several public events and continue to champion everything from the old Field Papers to Missing Maps.

I hope that I can use my diverse, humanitarian experience to be an active advocate for HOT. My background as a technologist and coder means I understand and, more importantly, help translate technical processes, especially for non-technical audiences. I understand what it’s like working with larger institutions and bureaucracies, what constraints they have and how to navigate those policies. And my entire career is in non-profits and development work, so how our iNGO, governmental ministries, and CSOs operate in these contexts. While I have not been able to directly contribute to HOT for some time, I know this is a meaningful way I can be more involved.

So how would I like to be involved and what do I see as priority issues for HOT? In addition to doing what I think are the core tasks of helping grow and foster the HOT community and find new partnerships:

• I’d like to continue the efforts of the board to promote and foster diversity and gender inclusivity among our community of contributors and users. The current board and the community have made tremendous progress here but we all have to continue to make this a priority, making sure it’s not only addressed but operationalize. This means ongoing dialogue with the community to make sure voices are heard and proactively running our own analytics to identify and address gaps.

• To promote more data consistency and quality. Conversations about standardizing our approach are not the most exciting and can feel very prescriptive but they’re also the means by which we overcome more barriers to adoption, where companies, governments, and organizations feel confident about HOT’s contributions and OSM at large, and users are more satisfied that their contributions are truly making a noticeable difference.

• To help highlight use cases of HOT, providing the context required by organizations to understand the costs and challenges involved but more so the many benefits that come with seeing this work in the context of a humanitarian response or contributing to resilience building. I think growing the community is always important, but I’d sooner direct more attention to improving and refining HOT’s narrative so that our current community feels valued and new and current partners clearly see the reasons to remain involved and invested.

• Help further issues related to code of conduct, ethics, and duty of care. This is something my team and I research, and such a critical part of all humanitarian response. I think it provides an opportunity for HOT on a couple fronts, where there is an opportunity to make sure we are doing the best we can four our members and community, and where HOT has made so much progress on this front, serving as a model to other organizations.

Thank you for taking the time to read all this, for your consideration, and for everything you do to make HOT and OSM great.

Best regards, R

I had the idea it would be easy to do a few quick fixes to some regional shortcomings of OpenStreetMap. It turned out that I was totally wrong. Quick is a term anyone new to OSM should erase from his vocabulary, if my experiences are something like typical. It was frustrating from the very start and it did not change the few times I tried to contribute to the project.

I do not think that OSM can reach really many users if it stays like this. It is just not possible to do a few quick additions to the maps without spending a lot of time to find out how to do even the simplest changes. It should be possible, for example, to intuitively mark a road as closed when road works pop up. There would have to be buttons for frequent changes like closing a road due to road works. Would operating the maps, putting in changes, would be an intuitive task, I am sure many more would contribute and there would be much less missing in the maps and the map would be more up to date.

Sorry for the negative comment to a project I think is basically a good project. But I really think there should be changes to make it a lot easier for newbies to contribute. I am not ready to put in that much time just to figure out how to do things.

Yesterday OpenStreetMap (OSM) became YaketySaxStreetMap (YSSM)

“Not really the kind of experience you may want”

Today’s update
Enabling Last-Modified has fixed all problems with all files, with the sole exception of the HTML/XML + piwick files. The first two could be fixed but our admin is not prepared to look at it, and the last come from another site are being looked at right now. Still, a prompt fix for all the rest, so well done for that. Shame that I had to suffer a full day’s worth of insults just to get that done.

Yesterday, 16 June began for me with a series of posts into openstreetmap-website/issues (my first use of a GitHub issues page). The start of my YaketySaxStreetMap day.

Benny Hill & Yakety Sax
Benny Hill was a multi-millionaire comedy actor that featured on TV thoughout my late-youth. One of his signature pieces was a speeded-up pre-filmed physical-comedy routine with Yakety Sax blaring out as the background music. If you download the MP3 from the web-page link, and play it whilst beating your head against a brick wall, then you will get the inside feeling of what yesterday was like for me.

More strolls down Memory Lane
After discovering earlier in the month that this site’s setup unnecessarily bloats all site-bandwidth and thus inflates site-load I documented those discoveries here. Doing that helped me get my head straight about what was happening so that I could (perhaps) give a useful report where it was needed, the website issues page. I found that to be a most painful experience.

1. Last-Modified header missing from almost all Website Static Files
   This was a bizarre experience, which led to me asking the YSSM Admin if he was a Gemini (due to the 180° Volte-face that he performed):
    
    → First: The YSSM Admin closed the Issue
     (he always does that, presumably to stop anybody else from being able to comment; after all, this website is his personal property)
    → Second: The YSSM Admin commented “Please don’t waster your time”
    → Third: An hour later he said “Re-enabled the Last-Modified header in openstreetmap/chef@d7eb7df”
    
2. HTML document can never receive a 304 Not Modified
   The origin server supplies a different eTag value on every access even though those are just seconds apart. That is an undeniable bug.
    
   Again, most frustrating. All I got from this was insult & attack from the YSSM Admin. Nothing got resolved & someone else closed it with “Locking this because it is not productive.” No-one else is willing to tackle the admin over his insulting & narcissistic behaviour, and thus they become complicit in it and it grows.
    
3. Certain Static (?) files can never receive a 304 Not Modified
   16 different files which appear to be files-on-disk. The caching is accurate for these files but the server never sends either eTag nor Last-Modified for the files so their delivery can never be sped up. Once again, a clear bug.
    
   I forgot to include the cache-control value in my first post. I knew that the admin was close behind me in looking at the posts (because he immediately closed each one after reading it) so I added a comment to flag the fact of the addition + edited the original post to add that value. The admin then added an insulting comment: “Look if you have something sensible to report then please do so in a clear way.”
    
   I responded: “I’ve noticed that you go out of your way to insult every new person that comes along, so it is hardly surprising that you stop most people from getting involved.” No newbie should be dealt with like this. No old fogie like me should have to deal with it. We are attempting to report bugs, not insult the organisation nor it’s workers. He really needs to get over himself.
    
4. A Static JS file can never receive a 304 Not Modified
   This is the inside-out version of the previous static files. It has a strong eTag + Last-Modified, but no caching nor Expires so no 304.
    
   The IP for openstreetmap.org is 130.117.76.[11-13], and that is unrelated to the 193.60.236.14 for piwik.openstreetmap.org that supplies this file (Information Systems, University College London), but I did not suspect that at that time. Nothing was happening on GitHub with this file so I telephoned Craig, a senior Network Engineer to try to talk with the Webmaster for that server. I eventually got an email back referring me back to OSM (UCL host it but OSM administer it). Talk now continues in GitHub.
    
5. A Static (?) XML file can never receive a 304 Not Modified
   The reply for this small file gets to the heart of the problem, which is to do with attitude and is actually not at all technical.
    
6. The 1x1 GIF pixels do not receive a 304 Not Modified
   (another product of my apalling sense of humour)
   The admin informed us that “Piwiki is nothing to do with this repository.”
    
   So, it seems that this webbug comes from University College London (actually that statement is misleading as UCL host the servers but OSM administer them).

I’ve been collecting geo-referenced photos since I started contributing to OpenStreetMap. When I discovered Mapillary a few years ago, I decided to upload these photos so that other people can use them in their own mapping.

Street art in Marikina’s freedom wall

Here’s a few sequence I found interesting to revisit whenever I go to the Mapillary website (links to each sequence are included for viewing the high-res photos). They are categorized according to the mode of travel.

☑️ 🚶

University steps, Philippines - I used to work within a university campus, part of my daily commute is to carry my bike on a footway with ~90-steps. It’s always a challenge to do this every morning!

Bahubali monolith, Vindhyagiri Hill, India - When I moved to India, my colleagues would take me to temples outside of Bangalore. Here’s the interior of the Jain temple of Bahubali above a hill in Shravanabelagola in Hassan. Temples in India only allows walking on foot starting from the climb up the hill and into the complex.

Bohol, Philippines - A casual walk around an island with white sand beach.

☑️ 🚲

Marikina River Park, Philippines - Cycling is my preferred mode of travel. On weekends, I usually take my kids to the nearby riverside park for casual cycling. Mounting the camera allows me to do surveying too!

☑️ 🚣 🛳

Venice Grand Canal, Italy - Travelling Venice is only possible by boat, what a great way to experience photo mapping through the Grand Canal!

Mangrove forest, Philippines - While doing a university research for monitoring recovery of mangrove forest, the only way to survey is by air or through the muddy substrate. This time I opted to use a kayak.

☑️ 🚗

Mindanao refugee camp, Philippines - When the Mamasapano clash happened. A lot of civilian were displaced in the surrounding towns due to the military operations. I worked with the regional response agency in mapping and documenting the IDP camps around the region. In most cases, it is the first time these informal camps were documented in a digital map.

TY Haiyan affected communities, Philippines - In the aftermath of the Typhoon Haiyan/Yolanda, there is an urgency to map and document the damage for the post-recovery efforts. I visited a lot of these areas as part of my work. My camera took continuous shots for most of the trip.

Next? 🐴 ✈️ 🚅 🚀 🎈 🚡

Who knows? I plan to continue collecting and sharing photos in Mapillary, maybe with other mode of transport. 😛

Do you want to know more about collecting street-level photos? We have an exciting session about that in the inaugural Pista ng Mapa in Dumaguete on Aug 1-3. Come join us and you might get nice schwags from Mapillary!

Upload of Umap files exported manually via the Umap web interface has been supported by my MapOSMatic instance for quite a while, and the MapOSMatic API has also supported submitting a Umap file via an URL instead of uploading an actual file.

There’s also a (so far inofficial) export URL for exporting an Umap for exporting a map directly, without manual browser interaction.

See this Umap Github issue for a more detailed description.

The basic idea is that for a map with Id 123 the stable web access URL would be:

https://umap.openstreetmap.fr/m/123

and the inofficial map export URL

https://umap.openstreetmap.de/en/map/123/geojson

Unfortunately the export file retrieved this URL is not yet complete though, as unlike the manualy exported file unsing “Export all data” in the web interface, it only contain the maps meta data, and references to the actual data layers, but not the actual layer data itself.

So when processing a file exported this way, we first need to check the “urls” dictionary from the map properties for the datalayer_view URL path, and combine this with the protocol and host part from the maps own export URL.

For the original Umap instance the datalayer_view looks like this:

/en/datalayer/{pk}/

and so the full URL template becomes

https://umap.openstreetmap.de/en/datalayer/{pk}/

The {pk} placeholder needs to be replaced with the Ids from the datalayers list entries, which e.g. look like this:

{
"name": "Layer 1",
"id": 123456,
"displayOnLoad": true
}

So we need to download actual layers data from URLs like

https://umap.openstreetmap.de/en/datalayer/123456/

which returns JSON data we need to append to the layers list to form a complete export file.

Once we fetched and merged all data layers we can then process the resulting JSON document the same way as the JSON exported from the web frontend.

This should allow a more direct integration between Umap and MapOSMatic servers, to automate the process of creating printed representations of maps generated with Umap.

An API request to render an umap with Id 123 would then simply look like this:

{
    "umap_url": "https://umap.openstreetmap.fr/en/map/123/geojson/"
}

In actual PHP code for example launching a map rendering job for this umap would look like this:

<?php
require_once 'HTTP/Request2.php';

header("Content-type: text/plain");

define('BASE_URL', 'https://print.get-map.org/apis/v1/');

$data = ['umap_url' => 'https://umap.openstreetmap.fr/en/map/123/geojson/'];

$request = new HTTP_Request2(BASE_URL . "jobs");

$request->setMethod(HTTP_Request2::METHOD_POST)
        ->addPostParameter('job', json_encode($data));

$response = $request->send();
$status   = $response->getStatus();

if ($status < 200 || $status > 299) {
    print_r($response->getBody());
    exit;
}

$reply = json_decode($response->getBody());
echo "Result URL: ".$reply->interactive."\n";

04.06.2019-10.06.2019

Mapping

• Jean-Louis Zimmerman twittert ein paar ungewöhnliche Kuriositäten, die Herausforderungen für das OSM-Mapping und -Tagging darstellen können. (automatische Übersetzung)
• Joseph Eisenberg hat auf der Mailingliste Tagging sein Proposal für den Tag waterway=tidal_channel zur Diskussion gestellt. Grundlage dafür ist eine Diskussion, die bereits im September 2018 stattgefunden hat, um natürliche Gezeitenwasserwege zu mappen.
• Der OSM-Mapper simon04 hat auf der Mailingliste Talk-at berichtet, dass er die neuen Layer vom österreichischen Opendataportal (OGD) in den Editor-Layer-Index eingepflegt hat. Näheres dazu beschreibt er auf seiner github-Seite.
• Im deutschen OSM-Forum wird darüber diskutiert, ob es angemessen ist, Straßen kurz vor Kreuzungen aufzuteilen, weil Tempolimit-Schilder nicht auf der Kreuzung, sondern wenige Meter später stehen.
• [1] Mapping North Korea ist ein neues Projekt von Maarten van den Hoven zur Fernkartierung von Nordkorea mit einer Weboberfläche im Tasking-Manager-Stil.
• Um Menschen in Krisengebieten rasch helfen zu können, sind Helferinnen und Helfer auf hochwertiges Kartenmaterial angewiesen. Für viele Gebiete müssen diese Karten erst angefertigt werden. Dabei wird ÄRZTE OHNE GRENZEN von moderner Technik unterstützt – und von tausenden Freiwilligen. Am 25. Juni von 19:00 – 22:00 treffen sich Interessierte zu einem Missing Maps Mapathon bei Wikimedia in Berlin.

Community

• Nicolas Chavent veröffentlichte einen Twitter-Moment über zwei Wochen OSM und kostenloses Geomatik-Training in Brazzaville (Kongo), das sich an die lokale OSM-Gemeinschaft und Interessenvertreter aus Forschung und Entwicklung sowie an lokale Behörden richtete. Die Kurse wurden mit Hilfe von Mitgliedern kongolesischer Gemeinschaften und einem togoischen Mapper mit Unterstützung der Internationalen Organisation der Francophonie (OIF) durchgeführt.
• Auf der Mailingliste Talk wurde die Frage gestellt, ob es Freiwillige gibt, die ein Diskussionsforum auf der kommenden SotM über den OSM-Editor iD organisieren wollen. Es gibt allerdings Gegenmeinungen, dass es nicht gut ist ein Tribunal über iD abzuhalten, sondern dass es besser wäre bis zum 1. September Ideen zu sammeln und diese dann zu diskutieren.
• Der OSM-Benutzer Joseph Eisenberg hat auf der Mailingliste OSM-talk die Frage gestellt, ob das Element data item auf OSM-Wikiseiten für Beschreibungstexte zu verwenden ist. Hintergrund dazu ist, dass er auf den Wikiseiten zu den Tags natural=peninsula und natural=isthmus keine oder nur sehr kurze Beschreibungen gefunden hat. Beim Anpassen der Wikiseiten konnte er kein Element für die Beschreibung finden und wurde von anderen OSM-Benutzern auf das Element data item hingewiesen. Joseph Eisenberg meint außerdem, dass die Wikiseite zu dem Element sehr verwirrend und daher die Verwendung für ihn nicht klar sei.
• Eine Diskussion im deutschen Forum über das Mapping von „Unverpackt“-Läden, bisher mit bulk_purchase getaggt, folgte eine Diskussion im französischen Forum über das gleiche Thema, aber unabhängig voneinander. Nun wird bilateral nach Möglichkeiten und neuem Tagging gesucht, um verpackungsfreie Einkaufsmöglichkeiten, sowie die Möglichkeit, eigene Verpackungen zum Einkauf mitzubringen, auch in OSM abzubilden.

Importe

• HOT hat einen Tasking-Manager mit der Unterstützung der gängigsten Machine-learning-Techniken eingerichtet.

OpenStreetMap Foundation

• Hanna Krüger hat Informationen zum Frauenanteil und der Verteilung anderer Merkmale unter den Teilnehmern der FOSSGIS-Konferenzen der letzten Jahre zusammengetragen (PDF).
• Das Protokoll der Sitzung der Data Working Group der OSMF vom 22. Mai wurde veröffentlicht.

Humanitarian OSM

• Die Seite geospatialworld hat einen Artikel über das Missing Maps Projekt publiziert, in dem das Projekt und deren Ziele vorgestellt werden.
• Intel Folsom veranstaltete einen Mapathon mit dem Missing Maps Projekt. Geschätzte Teilnehmerzahl waren 56 Kartographen plus 2 Freiwillige vom Roten Kreuz und 1 Freiwilliger von Intel, um ihre Fragen zu beantworten.

Karten

• Turksever twittert über ICT4Society in der Türkei, ein Projekt unter Verwendung von OSM und Mapillary, um die soziale Integration von Menschen mit Behinderungen zu verbessern.

Lizenzen

• Nuno Caldeira hat den OSMF-Vorstand gebeten, Facebook gemäß Artikel 9.4c der Open Database License über die bestehenden Lizenzverletzungen in Kenntnis zu setzen und ein Erlöschen der Nutzungsrechte bei ausbleibender Einhaltung nach 30 Tagen anzukündigen. Das führte zu einer längeren Diskussion auf der Mailingliste Talk.

Programme

• K_sakanoshita hat (Twitter, Facebook) eine neue Version von „Machi-aruki Map maker“ veröffentlicht. Neue Funktionen erlauben es Cafés, Restaurants und Hydranten in OSM einzupflegen.

Programmierung

• Quincy Morgan erwähnt in einem GitHub-Ticket, dass iD ab Version 3.0 ein allgemeiner GeoJSON-Editor werden solle.

Releases

• In der neuen iOS-Version von OsmAnd 2.80 werden, wie bereits von Android gewohnt, Mapillary-Fotos für die Navigation angezeigt. Neben einer Leistungsverbesserung gab es noch viele weitere Anpassungen. Dazu ist näheres im Blog von OsmAnd zu erfahren.

Kennst du schon …

• … das 3D Tool 3D OSM Buildings? Die Parameter lassen sich nach eigenen Wünschen einstellen.

Weitere Themen mit Geo-Bezug

• Die längste Glasbodenbrücke der Welt wurde vor kurzem in Ostchina als neue Attraktion im „Huaxi World Adventure Park“ an der Chinesischen Mauer eröffnet und löst mit 518 m Länge den bisherigen Rekordhalter (488 m) ab. Im OSM-Tagging liegt noch Potenzial. Es verwundert, dass „die Mauer“ nicht erfasst ist.
• Margaret Lee beschreibt in Mapbox’s Blog den Prozess von einer leeren Karte zu einer Live-Karte.
• Malvika Mahesh, ein Praktikant der Observer Research Foundation, schreibt in seinem Artikel “Drawing Lines On The Internet: Border Conflicts And The Politics Behind Digital Maps’ Sound Acceptable?” über die unterschiedliche Behandlung von Grenzen in digitalen Karten. Er betont auch die „on the ground“-Regel in OSM und hinterfragt Googles Vorgehensweise. U.a. wird eine Karte strittiger Grenzen verlinkt.
• Garmin hat ein neues Offroad-Navi „Overlander“ herausgebracht. Dazu sind OpenStreetMap-Karten mit Daten zum Höhenprofil für die Reliefdarstellung implementiert. Mit vielen weiteren Features, aber auch zu einem stolzen Preis, ist das „Overlande“ eher ein Gerät für „Weltenbummler“ mit entsprechend ausgestattetem Fahrzeug.
• Am 5. Juni fand der Weltumwelttag statt. Der GIScience News Blog, Uni Heidelberg, erinnert daran und zeigt noch mal die globale OSM-basierte Klimaschutzkarte, mit der Aufforderung, durch einen nachhaltigeren Lebensstil zum Klimaschutz beizutragen.
• Google hat ein Rollout für Google Maps, das die Anzeige der aktuell gefahrenen Geschwindigkeit ermöglicht, gestartet. Will man darauf allerdings nicht warten, kann man sich mit Hilfe der App Velociraptor die Geschwindigkeitsdaten aus den Datenquellen TomTom Maps, HERE Maps oder OSM per Overlay in Google Maps einblenden, wobei nur die OSM-Daten kostenlos zur Verfügung stehen.
• Im GoogleWatchBlog wird der Erfolg von Apple Maps beleuchtet, die mit eigenen Mitteln an einer Streetview-Funktion arbeitet. OpenStreetMap wird am Rande erwähnt als größter Mitbewerber „allerdings nur im Mapping- und Routen-Bereich und ohne kommerzielle Interessen“.
• Die Verkehrswende in Berlin hin zu einer fahrradfreundlichen Stadt wird mit OpenStreetMap unter FixMyBerlin visualisiert; in einem zweiten Layer wird der derzeitige Zustand der Radfahrerfreundlichkeit dargestellt.
• BMW veröffentlicht „sicherheitsrelevante Verkehrsdaten“, die von BMW-Fahrzeugen erfasst worden sind, unter der CC-BY-NC-SA-Lizenz, die kommerzielle Nutzung ausschließt, in der BMW-Pressemitteilung aber fälschlicherweise als „frei“ bezeichnet wird.

Wochenvorschau

Wo	Was	Wann	Land
Montpellier	State of the Map France	2019-06-14-2019-06-16
Essen	5. OSM-Sommercamp und 12. FOSSGIS-Hackingevent im Linuxhotel	2019-06-14-2019-06-16
Bonn	Bonner Stammtisch	2019-06-18
Lüneburg	Lüneburger Mappertreffen	2019-06-18
Rostock	Rostocker Treffen	2019-06-18
Karlsruhe	Stammtisch	2019-06-19
Leoberdorf	Leobersdorfer Stammtisch	2019-06-20
Rennes	Préparer ses randos pédestres ou vélos	2019-06-23
Bremen	Bremer Mappertreffen	2019-06-24
Montpellier	Réunion mensuelle	2019-06-26
Lübeck	Lübecker Mappertreffen	2019-06-27
Mannheim	Mannheimer Mapathons e.V.	2019-06-27
Düsseldorf	Stammtisch	2019-06-28
Cologne	Köln Stammtisch	2019-07-03
Stuttgart	Stuttgarter Stammtisch	2019-07-03
Essen	Mappertreffen	2019-07-04
Bochum	Mappertreffen	2019-07-04
Nantes	Réunion mensuelle	2019-07-04
Dresden	Stammtisch Dresden	2019-07-04
Heidelberg	Erasmus+ EuYoutH OSM Meeting	2019-09-18-2019-09-23
Heidelberg	HOT Summit 2019	2019-09-19-2019-09-20
Heidelberg	State of the Map 2019 [2]	2019-09-21-2019-09-23

Hinweis:
Wer seinen Termin hier in der Liste sehen möchte, trage ihn in den Kalender ein. Nur Termine, die dort stehen, werden in die Wochennotiz übernommen. Bitte prüfe die Veranstaltung in unserem öffentlichen Kalendertool und korrigiere bitte die Einträge im Kalender, wenn notwendig.

Diese Wochennotiz wurde erstellt von Map-Peter, Nakaner, Rainero, Rogehm, SK53, SomeoneElse, bjoern_m, derFred, doktorpixel14, geologist.

Many companies and organizations have a group of mappers editing on OpenStreetMap. We have created a feature on OSMCha to publish team lists of users, and then filter or hide changesets created by one or more mapping teams.

This week we pushed some adjustments to make it more useful for the OpenStreetMap community. So let’s see how it works.

In the OSMCha user menu, there is an option “My teams”.

That opens the “My mapping teams page”, listing the teams your user has already created on OSMCha. Clicking on the “Add +” button, you will be able to add the details of a new team.

The required minimum structure of the users JSON format is:

[{"username": "user_1"}, {"username": "user_2"}]

However you can add other fields if you want.

If the team you created is part of an organized editing initiative, please open an issue on our GitHub repository requesting your team to be considered a “Verified team”. That way, an OSMCha admin can validate your team and it will appear on the filter page with an indication that the team was created and maintained by your company/organization.

Finally, on the Filters page, we have three team fields: “Mapping teams”, “Hide mapping teams”, and “Hide verified mapping teams”. They allow for filtering or exclusion of changesets from one or more teams, and to hide changesets created by all the verified mapping teams.

The mapping team management can also be used through the API. Check out the API Docs for instructions about the endpoints.

We expect this new feature helps the OSM community to be even more effective on changeset validation. If you have some question or new ideas, please open an issue on our GitHub.

04/06/2019-10/06/2019

Mapping

• Jean-Louis Zimmerman tweets a few unusual curiosities which may challenge OSM mapping and tagging. (automatic translation)
• Joseph Eisenberg has posted his proposal for the tag waterway=tidal channel to the tagging mailing list for discussion. It is based on a discussion that took place in September 2018 to map natural tidal waterways.
• The OSM mapper Simon Legner reported (translation) on the Talk-at mailing list that he added the new layers of the Austrian government’s Open Data portal (OGD) to the editor layer index. He describes more about it on his github page.
• [1] Mapping North Korea is a new project from Maarten van den Hoven to remotely map North Korea, with a Tasking Manager style web interface.
• In order to be able to help people in crisis areas quickly, helpers depend on high-quality maps. For many areas, these maps must first be produced. In doing so, Doctors Without Borders is supported by modern technology – and by thousands of volunteers. On 25 June 2019 from 19:00 – 22:00, meet interested people for a Missing Maps Mapathon at Wikimedia in Berlin.

Community

• Nicolas Chavent published a Twitter moment about two weeks of OSM and free Geomatics training in Brazzaville (Congo) targeted to the local OSM community and stakeholders from the research, development and local authorities. The courses were facilitated with the help of members of Congolese communities and a Togolese mapper with the support of the International Organisation of Francophonie (OIF).
• On the mailing list OSM-talk the question was asked whether there are volunteers who want to organise a discussion forum at the upcoming SotM about the OSM Editor iD. However, a suggestion was made that it is not a good idea to hold a “tribunal” on iD, but that it would be better to collect ideas by September 1st and then discuss them.
• The OSM user Joseph Eisenberg asked on the mailing list OSM-talk whether the element data item on OSM Wiki pages should be used for description texts. The reason for this is that he found no or only very short descriptions for the tags, natural=peninsula and natural=isthmus on the wiki pages. When editing the wiki pages he could not find an element for the description and was referred to the element data item by other OSM users. Eisenberg also says that the wiki page for the element is very confusing and therefore its use is not clear to him.
• A discussion (translation) about the mapping of “unpacked” stores on the German forum, previously tagged with bulk_purchase, was followed by a discussion (translation) on the French forum on the same topic, but independently of each other. Now new tagging is discussed together in English under the heading “Tag[ging] shops accepting that customers bring their own containers”.

Imports

• HOT have set up a Tasking Manager for computer vision imports.

OpenStreetMap Foundation

• The minutes of the meeting of the OSMF Data Working Group on 22 May 2019 have been published.

Humanitarian OSM

• The website geospatialworld has published an article about the Missing Map project. It introduces the project and its goals.
• Intel Folsom hosted a mapathon with the Missing Maps Project. Estimated attendance was 56 mappers, plus 2 volunteers from the Red Cross and 1 volunteer from Intel to answer their questions. You can read more here.

Maps

• Said Turksever tweeted about ICT4Society in Turkey, a project using OSM and Mapillary to help improve social inclusion for people with disabilities, and links to the resulting map.

Licences

• Following a long discussion with Facebook and their map suppliers (Mapbox), Nuno Caldeira asked the Board of OSMF about terminating Facebook’s rights under ODbL. As source of his request he mentioned chapter 9.4 c) of the ODbL. This follows a long discussion about attribution of OSM in February and March this year on the main “talk” list.

Software

• K_sakanoshita published (Twitter, Facebook) new version of “Machi-aruki Map maker“, used for creating printed maps for disaster planning etc. New features are now available to add cafes and restaurants, fire hydrant icons and labels.

Programming

• Quincy Morgan suggests in a GitHub ticket that iD from version 3.0 should become a general GeoJSON editor.

Releases

• In the new release of OsmAnd 2.80 (iOS), Mapillary photos are displayed for navigation, as is already the case on Android. In addition to performance improvements there were many other adjustments. You can read more about this in OsmAnd’s blog.

Did you know …

• … a few lines of code with the 3-D Tool 3D OSM Buildings lets us rotate a panoramic view.

Other “geo” things

• The longest glass floor bridge in the world was recently opened in East China as a new attraction in the “Huaxi World Adventure Park” at the Great Wall of China. With a length of 518 m it replaces the previous record holder (488 m). Here’s where you can find this on OSM.
• Margaret Lee describes in Mapbox’s blog “The route from a blank map to a live map”.
• Malvika Mahesh, a research intern of the Observer Research Foundation, writes in his article “Drawing Lines On The Internet: Border Conflicts And The Politics Behind Digital Maps” on the different treatment of borders in digital maps. He also praises OpenStreetMap’s “on the ground” rule (see also OSM’s Disputed Territories (PDF) policy – itself not always accepted across the board in OSM) , and criticises Google’s current approach. An interesting link from that article is a map summarising worldwide disputes.
• World Environment Day took place on 5 June. A post at the University of Heidelberg’s GIScience News Blog links to the global OSM-based climate protection map, with a call to contribute to climate protection through more sustainable lifestyles.
• The changes in Berlin from being a car-friendly to a bicycle-friendly city can be seen at FixMyBerlin, where the current state of cycle-friendliness is also displayed.
• BMW published (translation) “safety-relevant traffic data”, collected by BMW vehicles, under the CC-BY-NC-SA license, which excludes commercial use, but which a BMW press release incorrectly describes as “free”.

Upcoming Events

Where	What	When	Country
Montpellier	State of the Map France	2019-06-14-2019-06-16
Essen	5. OSM-Sommercamp und 12. FOSSGIS-Hackingevent im Linuxhotel	2019-06-14-2019-06-16
Kyoto	京都！街歩き！マッピングパーティ：第9回 光明寺	2019-06-15
Dublin	OSM Ireland AGM & Talks	2019-06-15
Coimbra	Training School on Quality Control of OpenStreetMap Data	2019-06-17-2019-06-19
Cologne Bonn Airport	Bonner Stammtisch	2019-06-18
Lüneburg	Lüneburger Mappertreffen	2019-06-18
Rostock	Rostocker Treffen	2019-06-18
Coimbra	Coimbra Mapping Party	2019-06-18
Karlsruhe	Stammtisch	2019-06-19
Leoberdorf	Leobersdorfer Stammtisch	2019-06-20
Rennes	Préparer ses randos pédestres ou vélos	2019-06-23
Bremen	Bremer Mappertreffen	2019-06-24
Angra do Heroísmo	Erasmus+ EuYoutH OSM Meeting	2019-06-24-2019-06-29
Salt Lake City	SLC Map Night	2019-06-25
Montpellier	Réunion mensuelle	2019-06-26
São Paulo	OpenStreetMap no MundoGeo Connect	2019-06-26
Lübeck	Lübecker Mappertreffen	2019-06-27
Mannheim	Mannheimer Mapathons e.V.	2019-06-27
Düsseldorf	Stammtisch	2019-06-28
Kyoto	幕末京都オープンデータソン#11：京の浪士と池田屋事件	2019-06-29
Sakai	百舌鳥古墳群マッピングパーティ	2019-06-30
Žilina	Missing Maps mapathon Zilina #5 at Faculty of Management Science and Informatics University of Zilina	2019-07-02
Cologne	Köln Stammtisch	2019-07-03
Stuttgart	Stuttgarter Stammtisch	2019-07-03
Essen	Mappertreffen	2019-07-04
Bochum	Mappertreffen	2019-07-04
Nantes	Réunion mensuelle	2019-07-04
Dresden	Stammtisch Dresden	2019-07-04
Ivrea	Incontro mensile	2019-07-06
Makati City	OSMPH × GrabPH Mapathon 1	2019-07-06
Santa Fe	State of the Map Argentina 2019	2019-07-27
Minneapolis	State of the Map U.S. 2019 [1]	2019-09-06-2019-09-08
Edinburgh	FOSS4GUK 2019	2019-09-18-2019-09-21
Heidelberg	Erasmus+ EuYoutH OSM Meeting	2019-09-18-2019-09-23
Heidelberg	HOT Summit 2019	2019-09-19-2019-09-20
Heidelberg	State of the Map 2019 [2]	2019-09-21-2019-09-23
Wellington	FOSS4G SotM Oceania 2019	2019-11-12-2019-11-15
Grand-Bassam	State of the Map Africa 2019	2019-11-22-2019-11-24

Note: If you like to see your event here, please put it into the calendar. Only data which is there, will appear in weeklyOSM. Please check your event in our public calendar preview and correct it, where appropriate.

This weeklyOSM was produced by Nakaner, Polyglot, Rogehm, SK53, SomeoneElse, TheSwavu, derFred, geologist, jinalfoflia.

Has OpenStreetMap (OSM) become GaslitStreetMap (GSM)?

“Believe What I Tell You & Not What You See”

A stroll down Memory Lane
In Spam Attacks the floods of spam drowning these Diary pages were quantified, whilst in Extreme SEO was news that the spam had now been killed by killing all Diary page visibility. In HiddenStreetMap it was that large parts of the entire site are invisible to the general public, and Diary pages are completely dark. BloatedStreetMap was news that this site’s setup unnecessarily bloats all site-bandwidth and thus inflates site-load.

I presented evidence throughout the above, but also pointed out that it was not just a technical issue. It was first a question of attitude & desire. To quote the Spice Girls, what do you really, really want?

If SFS are handling a similar workload as GSM, which they are, yet doing it with a single server whilst GSM has 90 servers, which it has, then there is clear headroom for the SEs to light up this site.
 • A setup that conforms with industry best-practice to remove the bloat would be a good start
 • Standard methods are available to stop fast-scrapes
 • Moderation on new users is the standard method to bring spam under control, yet leave current users fully visible.

My evidence was ignored and I experienced personal attack from a small coterie who can be found throughout the site GitHub comments. They are in part a self-affirming circle showing classic narcissistic behaviour.

Those that were narcissists never thanked me for the evidence, nor examined it, but only attacked me in personal terms for anything that they considered reflected badly upon themselves. I’ll give some clear examples of this later, but first…

Here is the definition of “Gaslighting” from Wikipedia, so familiar now to USA readers due to it’s constant use by the malignant narcissist that now occupies the White House:

Gaslighting is a form of psychological manipulation in which a person seeks to sow seeds of doubt in a targeted individual or in members of a targeted group, making them question their own memory, perception, and sanity. Using persistent denial, misdirection, contradiction, and lying, gaslighting involves attempts to destabilize the victim and delegitimize the victim’s belief.

I made 3 assertions in HiddenStreetMap:–

1. These Diary Pages are Closed Tight Shut
2. The Map Pages are Closed Tight Shut
3. All Admin action appears to be Unilateral - Zero Consultation

A Classic Example of Gaslighting & Mis-Direction:–
After writing HiddenStreetMap the GSM Admin immediately tried to gaslight me:–

10 June 2019 07:18:
Wasn’t it you that suggested blocking indexing of the diary pages as a temporary measure?

That was nonsense. I think that the Diary pages are useful, and my prior suggestion was to place new users into moderation. That Admin, in contrast, hates these diaries and wants to remove them:–

18 May 2019, 10:08 BST:
Frankly I think a more reasoned response would be that it is ridiculous for us to be running a blog system that is entirely unrelated to our primary purpose and just ditch the diaries altogether.

18 May 2019 at 10:05
Personally at this point I am inclined to just close down the diaries - they are not core to our service and should probably never have been implemented and it’s unlikely we will ever be able to implement the sort of tools that a product focused on blogging can manage and that they will continue to consume ever larger amounts of administrators time.

Rather than being a servant to a larger affair, that Admin believes himself to be in charge of it all. That is a most dangerous delusion. However, do not miss the misdirection (yet another Gaslight technique deployed by narcissists). Blocking Diary pages from indexing by the SEs was a unilateral Admin action which he does not want to be discussed, so he attempts to deflect into other matters. Once you know how they work this is oh so predictable.

For a final word on the diaries, realise that they allow air & light into a common discussion across all issues related to OSM, but not GSM. The Admin wants these diaries to be dark, and that is precisely what a narcissist would want.

A final, less important example of gaslighting:–
…came on 5 June with the Extreme SEO post. I listed the contents of robots.txt and pointed out that it contained a broken link to the Sitemap. Without acknowledgement nor thanks it got fixed by the Admin on the same day shortly after the post went up. However, underlining the previous paragraph, 4 years previously BushmanK opened an issue pointing out that the Sitemap was missing and got short shrift about it from the Admin (a Sitemap is a vital tool for good SEO, whilst a broken robots.txt is the perfect way to get downgraded by the SEs). Nevertheless, on Thu, 06 Jun 2019 17:07:41 GMT the previous day’s fix was post-allocated to that old issue.

Please forgive a long post. I’m trying to disinfect the foul atmosphere here with sunlight.

The Greek OSM community would like to hear from you on how junction:ref=* can be used on free-flowing motorway interchanges.

Examples of motorway interchanges under discussion include the M4/M25 interchange near Heathrow, and the Α1/Α6 interchange near Metamorfosi.

Whatever is decided by the Greek community may influence how we use junction:ref=* for similar interchanges worldwide.

Comments and suggestions may be posted on the key’s talk page, or the forum thread: both pages are monitored.

Rua Butantã, Avenida Eusébio Matoso, Rua Paes Leme, Rua Eugênio de Medeiros e Diversas outras na região 100% numeradas , foram corrigidos erros na nomeação excluídos edifícios não mais existentes inclusos faixas de pedestres semáforos pontos de ônibus iluminação etc.

Over the years there were requests for UTM support in my MapOSMatic instance every once in a while.

I now spent most of the first day of this years FOSSGIS Summer Camp on the topic, and I’m now happy to announce a first exeprimental implementation of an UTM grid overlay.

The screenshot shows the grid overlay only for clarity, it shows the grid for transition between two UTM zones, and the not-yet-perfect label placing:

If you are interested in further progress on this feature you may wat to subscribe to the Feature Request

Зато крымнаш

Mirko Cuneo, Imprenditore Digitale ed esperto di tecniche di vendita. CEO di Nextre Digital

We recently rewrote the OSM Inspector Routing View. The old views were used quite a lot by mappers to find potential routing errors. Unfortunately, they made use of PostGIS to find nearby, unconnected roads which meant having to import the whole road network into a PostGIS database every day. To make matters worse, the island and duplicate segment detection was implemented using OSRM which also has relatively heavy system requirements, especially if you do not limit yourself to automobile routing. This made us have a closer look at using GraphHopper to generate the routing view.

The new backend code was implemented from scratch and does not aim to be a one-by-one reimplementation. It uses GraphHopper to read the planet, build up the graph, analyse it and find nearby edges. Our code uses a forked version of GraphHopper 0.12 with the following changes:

• The original GraphHopper lacks some callback functions in its OSMReader class. Our changes allow us to build additional indexes and populate maps mapping from internal edge or node IDs to OSM object IDs.
• The PrepareRoutingSubnetworks class which removes islands from the graph is not extensible but we need to write the edges being removed to a GeoJSON file.

In addition to forking, we implemented a new routing profile (“flag encoder” in GraphHopper speak) accepting any road and ignoring access restrictions. It is used to find duplicated edges, unconnected roads, and islands.

The backend code is available on GitHub.

The new routing view has the following groups of layers:

Duplicated Edges

These layers show edges which exist twice in the graph. The blue ones are almost always real errors and should be fixed by comparing the tags and history of both ways. The purple ones are locations where two edges have equal geometry and at least one of them is an area. Opinions whether areas should share nodes with neighbouring roads are diverse among the OSM community. Therefore, these cases are shown in a separate layer at high zoom levels only.

The results of the duplicated edges layer (not involving areas) are similar to those of OSRM. Minor differences are possible where OSRM excluded a road due to access restrictions while our new implementation includes it.

Islands

The use of GraphHopper allows us to identify routing islands for multiple types of vehicles in one go. The OSM Inspector now provides islands for cars and bicycles using slightly modified version of the original profiles of GraphHopper (we use fewer bits to store the speed because island detection does not take travel times or distances into account). In addition, a layer with islands inaccessible to any vehicle is provided. This layer contains fewer entries in total but those contained are more serious because they are not caused by correct or incorrect access restriction tagging in OSM.

Unconnected Nodes

Most development time was spent finding a set of unconnected nodes layers with a proper separation of very likely, likely, potential errors and likely false positives. We are grateful to the folks on the German OSM forum who pointed out many bugs and too high rates of false positives.

Nodes where a single edge ends but with other edges within 15 meters are assigned to one of 6 priority classes. A distance below 2 meters makes a unconnected node appear in the top layer. The further composition of the layers depends on the road class, the distance, and access restrictions. The priority of unconnected nodes involving private access roads is reduced by 1. Service roads and footpaths get low default levels. In addition, the following rules avoid too many false positives:

• noexit=yes and entrance=* make unconnected nodes disappear.
• Nearby edges on different layers/levels are ignored.
• Linear barriers (fences, walls, embankments) are taken into account.
• Unconnected open ends of parking aisles are ignored if they snap to a parallel edge.
• If the distance between the open end node and its snap point on the graph is less than twice as long as the beeline distance, no point is shown.

The “snap points” layer shows the snap points of open ends helping to understand the situation.

Not all entries in the unconnected nodes layers are mistakes. Often, adding a linear barrier is helpful. The more blueish a point is, the less likely it is a mistake at all. Don’t feel forced to add noexit=yes to every point the OSM Inspector complains about. You are not mapping for the validator