OpenStreetMap

When OpenStreetMap met Mapbox-GL : 🍚IDLY-GL

Posted by kepta on 14 May 2018 in English (English)

Today I am super excited to announce Idly-Gl! It is an opensource Mapbox GL plugin which renders OpenStreetMap data.

idly-gl

What is Idly-Gl?

Idly-Gl is a small plugin which reads data from Openstreetmap's API and renders it on any Mapbox GL map. Click here for a demo.

What is IDLY 🍚?

Idly is an Indian rice cake 🍚. I picked this name as it can be the little brother of iD editor.

Why did you create it?

I work with a lot of Mapbox-gl maps and I am very impressed with their speed and portability. I have also worked with iD editor and it has impressed me with the way it handles OSM data. The only problem is that these two don't talk to each other well. To bridge the gap, we would have a button to open it in iD. This works well when you have to make an edit, but if a user just wants to inspect/visualize OSM data the only option is to open the OSM website.

What does it do?

  • 😎 It renders live osm data on a mapbox-gl map, which makes it blazingly fast.

image

  • 👯‍♀️ It tries to mimic iD editor's familiar styling.

idly_id_style

  • 🕵 Dig deep into OSM entities, by interacting with them.

screen

  • 💪 Add to any existing Mapbox-gl map to give it OSM superpowers.

add_anytime

What is next?

  • Idly-gl already does an impressive 3d buildings. I plan on adding some advanced 3d visualization of OSM data, provided Mapbox-gl supports it.
  • The Openstreetmap 's entity inspector provides a nice way to inspect an entity. I imagine Idly-gl doing the same thing. There are certain features like viewing the history or the changeset which are not yet there in Idly-gl, but I have plans to add them.
  • If all goes fine, I think being able to search would be great. I imagine putting a query like highway=* and Idly-gl only shows all the highways on the map.
  • I also wanna try to add some sort of linting into Idly-gl. There are already some great rules at osmlint, which I feel can be used to highlight entities which violate any selected linting rule.
  • Currently it just visualizes Turn restrictions. I plan on adding more Restriction visualization, but the tricky part is how to best visualize restrictions without the map being too cluttered.

What is the goal Idly-gl?

The goal of Idly-gl is to be a highly customizable developer tool which helps the developers add powerful OSM data inspection/visualization into their apps.

How do I add it to my website?

I am glad that you want to give it a try, head over to the Github repository Idly-gl!

Where can I play with it?

Idly-gl Demo

(Tip: If you want to see the 3d buildings, make sure you switch on 3d extrusion layer)

Final thoughts

Idly-gl is currently very new and I am super excited to talk about it. I would really appreciate if you could try it out and give me feedback or ideas on how to further improve this tool and help OSM community build amazing things on top of it.

Comment from Chetan_Gowda on 14 May 2018 at 14:53

This is awesome Khushan! I love Idly-gl and Idlies! Amazing work :)

Comment from Dalkeith on 14 May 2018 at 15:14

Great work - make tools that you can use for yourself and if others use them as well even better

Comment from 4004 on 14 May 2018 at 21:19

Something that should've been done some time ago, a very neat idea

Comment from Andy Allan on 15 May 2018 at 00:56

Nice project! However, it violates the API Usage Policy. The API is only provided for editing OpenStreetMap data. If you want to display OSM data then you need to get that data via planet.openstreetmap.org or a service that is built on top of the planet feeds.

Comment from kepta on 15 May 2018 at 04:47

Thanks for flagging the API Usage Policy, just want to reinstate that it is a developer tool and not directly for users to use, I will make the API URL configurable and let the developers decide what API to use if in case they violate API Usage Policy, ref

Comment from Komяpa on 15 May 2018 at 20:10

I like this project!

It's a shame almost all posts about it are followed up by someone telling "you shouldn't do it, it violates". Is this thing going to break OSM? If yes, how can we make this fate come closer, so someone pays attention and fixes what's broken, instead of stopping people from doing things? :)

Comment from PlaneMad on 15 May 2018 at 20:28

This is so cool, Kushan! This makes it so much easier to browse the OSM data compared to using the default 'data' mode in the website or any editor.

The OSM project has always maintained that this is a data project and not a visual map project. Idly actually realizes this for the first time, making it easy for anyone to touch and feel what OSM is about.

Comment from Andy Allan on 16 May 2018 at 01:04

@Komяpa Of course it would be great if we could support unlimited requests on the /map call. But since that's not the case today then I think it's nicer to give an early warning rather than a potential bigger problem later on!

As I'm sure you're aware, but for the benefit of others who might be interested, the /map API call is hard to scale for two reasons. Firstly, it works like a WMS service with arbitrary extents, rather than like tiles with fixed extents. Secondly, it's crucial for all editing software that it provides read-after-write consistency, so that when a changeset is saved, the next /map request is guaranteed to contain that fresh data. So both these reasons make it hard to cache responses and without any caching it's hard to scale.

There have been proposals to fix both of these over the last few years. This would be by making map calls tiled, and by providing a "not-before-changeset" parameter or similar for the consistency issue. Then we could cache responses without breaking the editing workflow, and support more use of the /map call. But like many things, we need more people coding, and more community support for those who are already coding. Suggesting that we should deliberately violate the policy, and "break OSM" so that "someone pays attention" would not be the best approach! :-)

Comment from mmd on 16 May 2018 at 05:39

But like many things, we need more people coding, and more community support for those who are already coding.

@Andy Allan: as you're mentioning this point: the pull request to remove those remaining slow parts in the map call is already out there, waiting to be reviewed, merged and deployed: https://github.com/zerebubuth/openstreetmap-cgimap/pull/142

@Komяpa : you're still very welcomed to rerun your test setup to see how this change affects runtime, see this comment

Comment from Andy Allan on 16 May 2018 at 05:58

@Andy Allan: as you're mentioning this point: the pull request to remove those remaining slow parts in the map call is already out there, waiting to be reviewed, merged and deployed: https://github.com/zerebubuth/openstreetmap-cgimap/pull/142

That PR is unrelated to what I've described above. Sure, it speeds the map call up, but it doesn't make it any more cacheable that now.

Comment from mmd on 16 May 2018 at 06:10

Sure, it doesn't address the caching part. Otoh, such a cache will be incredibly difficult (and expensive) to keep in sync and given that we'll hopefully end up with very small database times and the expected savings being relatively smaller, I would reevaluate this topic once changes are in place.

Comment from mmd on 16 May 2018 at 09:29

Apologies, I really don't intend to hijack this blog post...

@Andy Allan:

Secondly, it's crucial for all editing software that it provides read-after-write consistency, so that when a changeset is saved, the next /map request is guaranteed to contain that fresh data.

Just wanted to add a short remark about this point. There's really a rather small but noticeable replication delay, which is typically in the range of 1, maybe 2 seconds. Some applications like the iD editor introduced an artificial wait time of about 2.5 seconds to be sure that the /map call they use to re-populate the editor contains all data which has just been uploaded. Still, in some exceptional cases, the data might not be replicated yet.

Please see https://github.com/openstreetmap/iD/issues/1646 for more details and further discussion.

Login to leave a comment