OpenStreetMap
Today I am super excited to announce Idly-Gl! It is an opensource Mapbox GL plugin which renders OpenStreetMap data.
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.
- 👯♀️ It tries to mimic iD editor’s familiar styling.
- 🕵 Dig deep into OSM entities, by interacting with them.
- 💪 Add to any existing Mapbox-gl map to give it OSM superpowers.
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?
*(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.
Дийцар
Коммент Chetan_Gowda 14 May 2018 14:53
This is awesome Khushan! I love Idly-gl and Idlies! Amazing work :)
Коммент Dalkeith 14 May 2018 15:14
Great work - make tools that you can use for yourself and if others use them as well even better
Коммент 4004 14 May 2018 21:19
Something that should’ve been done some time ago, a very neat idea
Коммент Andy Allan 15 May 2018 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.
Коммент kepta 15 May 2018 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
Коммент Komяpa 15 May 2018 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? :)
Коммент PlaneMad 15 May 2018 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.
Коммент Andy Allan 16 May 2018 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! :-)
Коммент mmd 16 May 2018 05:39
@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
Коммент Andy Allan 16 May 2018 05:58
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.
Коммент mmd 16 May 2018 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.
Коммент mmd 16 May 2018 09:29
Apologies, I really don’t intend to hijack this blog post…
@Andy Allan:
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.