[Ed note: this is a ‘preprint’ because my usual blog has technical problems]

A few days back I read this article about the longest straight lines on land and sea and I wondered how routers would handle the load, at least for the land one.

So I set up a route between Rua da Fortaleza, Sagres, Portugal, and what looks like the main square in Quanzhou, China. SRTM and GraphHopper handled the request just fine, while for some reason valhalla didn’t. Then I upped the stakes, by requesting foot routes. Foot routes are harder because the foot network is way bigger than the road network. SRTM and GH succeeded, but not without some effort. I tried to benchmark it, but it seem at least OSRM seems to cache the results, which makes sense. Interestingly, the route more or less follows the great circle all the way down to around Tyumen, Russia, where it starts to deviate more and more as the roads become less and less frequent. Also, OSRM proposes a land only route, while GH also includes ferries, but that depends on how OSM uses GH and how GH (and probably OSRM too) are configured.

I also read the foot notes on that article[1]. It mentions that Sagres is also the end of the longest land route, period; the other end is in Russia. First thing to note is that is says that the end is close to the North Korea border, “the eastern terminus of that country’s road network”. I wonder where he got that nibble, because I found there are connected roads almost all the way to the Chukchi Peninsula, crossing the antemeridian. I found that all routers choke there. So the calculation for the longest foot route will have to wait until this is fixed; I’m not going to settle for partial results :)

Lastly, That Other Map does not even has those routes, so technically they don’t have that problem :)

---

[1] you do that, right? :)

Have you ever tried to share a location with a OSM based application with another person? I have tried many times. My issue is that I’m almost the only person not using gmaps, and so far I haven’t been able to do that successfully. At the beginning I thought it was a Google thing, where they forced their product down everybody’s throats by ignoring geo: URIs, but last night I found the reason:

Messaging applications do not recognize these URIs.

To be honest, Google does somehow force themselves on everybody’s throats: It doesn’t send geo: URIs, just a link to goo.gl. Many other Android map apps do the same, not always to goo.gl but other times to their own sites. So far I have only found OsmAnd that sends geo: links. But all of them can handle such URIs, they’re not stupid :)

Between sender and receiver there’s the messaging app, which acts a the transport. So far I have found only Element Android (Matrix’s client) that recognizes geo: URIs as links and lets Android resolve that into a map app. Other IM apps treat them as just text. Most browsers will handle geo: URIs if they’re a link in an HTML page, even on the desktop version, but most will not handle it if you type it in the location/search bar.

I know this does not seem completely related to OSM, but I think that being able to share locations from any map app (most of them OSM based), using any messaging app and viewing the location with any map app (again, most OSM based) is a good thing to have.

I started a small wiki page tracking app status and sometimes links to the issues in their bug trackers we we could go and put some pressure for support. osm.wiki/Geo_URI_scheme Go and vote in your favorite apps, or open new ones!

I’ve been trying to continue implementing https://github.com/gravitystorm/openstreetmap-carto/issues/110#issuecomment-377527922 , but I hit a wall with CartoCSS, and frankly, I don’t know where to ask questions about it. Do you think it makes sense to create a #cartocss channel in the OFTC network?

Ever since reCAPTCHA become mainstream we knew that Google was using us as mechanical turks. At the beginning it seemed OK because we were reading books and newspapers, but then the system started asking questions like which of these squares had cars or traffic signs or store fronts in it, and you had to be kinda dumb not to realize you were training an Street View AI[1]. Since then, I’ve been trying to avoid sites that ask me to work for free for Google.

On the other hand, I’m kinda sick and tired of the SPAM that comes through the RSS feeds of https://blogs.osm.org/ . I think this is mostly due to the fact that opening an account does not involve proving you’re not a robot.

So, what about creating a captcha system that at the same time helps building the OSM database? What is not clear to me is what exactly the system would be helping to do. I think the simplest and more impacting would be to recognize simple features that would help mappers to find things to maps, more than trying trying to train an AI to map automatically.

I wonder what would the suppliers, like Bing, Mapbox, etc, think of such use of the imagery they license to OSM for mapping, specially if the system starts to be used by third party sites to block bots/spammers.

---

[1] If you want to know a little more, please read https://www.techradar.com/news/captcha-if-you-can-how-youve-been-training-ai-for-years-without-realising-it.

I reimported Europe lately, but I forgot a column. Because I had several space problems which I had to solve by hand (and also because it takes a lot of time), I simply sat down and reprocessed the extract with pysomium, adding the missing data to the rendering database. More details in my glob

This post should be in my glob, bu it’s down for the moment :(

For a long time now I’ve been thinking on a problem: OSM data sometimes contains riverbanks that have no centerline. This means that someone mapped (part of) the coasts of a river (or stream!), but didn’t care about adding a line that would mark its centerline.

But this should be computationally solvable, right? Well, it’s not that easy. See, for given any riverbank polygon in OSM’s database, you have 4 types of segments: those representing the right and left riverbanks (two types) and the flow-in and flow-out segments, which link the banks upstream and downstream. With a little bit of luck there will be only one flow-in and one flow-out segment, but there are no guarantees here.

One method could try and identify these segments, then draw a line starting in the middle of the flow-in segment, calculating the middle by traversing both banks at the same time, and finally connect to the middle for the flow-out segment. Identifying the segments by itself is hard, but it is also possible that the result is not optimal, leading to a jagged line. I didn’t try anything on those lines, but I could try some examples by hand…

Enter topology, the section of maths that deals with this kind of problems. The skeleton of a polygon is a group of lines that are equidistant to the borders of the polygon. One of the properties this set of lines provides is direction, which can be exploited to find the banks and try to apply the previous algorithm. But a skeleton has a lot of ‘branches’ that might confuse the algo. Going a little further, there’s the medial axis, which in most cases can be considered a simplified skeleton, without most of the skeleton branches.

… 查看完整日記項目

Last year the USGS started releasing 1 arc DEM files. I’ve been using their 3arc files for a couple of years, so I decided to take a look of their quality. I ended up discussing something else:

http://www.grulic.org.ar/~mdione/glob/posts/filling-voids-in-DEMs/

I mostly finished analysing how much it costs to me to keep the data up to date and rendering the maps. I will have to change the map design a little, but at the end the project seems useful. all the details in the following links:

http://www.grulic.org.ar/~mdione/glob/posts/appending-osm-data-with-flat-nodes/

http://www.grulic.org.ar/~mdione/glob/posts/detailed-osm-mapnik-redering-times/

You can see the rendered map here:

http://grulicueva.homenet.org/~mdione/Elevation.html

Another analisys on my efforts to import big ammounts of data to my notebook: fixes sone last post, a graph showing memory usage and an analysis on whether it makes sense for me to apply daily diffs, given my space constraints.

http://www.grulic.org.ar/~mdione/glob/posts/appending-osm-data-with-flat-nodes/

I wrote a post in my blog telling my story about importing Europe in a notebook, how much time it takes, andwhat are the resulting rought rendering times.

http://www.grulic.org.ar/~mdione/glob/posts/osm-planet-importing-and-rendering-times/

I decided to put online my design and rendering efforts here:

http://grulicueva.homenet.org/~mdione/Elevation.html

There is a melange of different design stages, the latest rendered is in the Deutschland area. Next steps are finish the design of the contour (hypsometric) curves with text and integrating the latest changes from upstream. A not so detailed explanation on how I did this is here:

http://www.grulic.org.ar/~mdione/glob/posts/Elevation/

The system is not completely automated yet, I also have to work on that.