|
Considering all underlying data is stored as SVG, why does OSM serves maps as raster data? Switching to SVG would:
So, why? Is it simply because OSM started with raster and changing cost is simply too big? |
|
A couple of misconceptions:
The most important reason however is lack of browser support. We'd like everyone to see the map, not only those with modern browsers on powerful processors. I think it is likely that we will switch to vector tiles at some point in the future but I'd guess it's going to be something like 2 years. You are of course welcome to set up your own vector tile server based on OSM, as others have done, e.g. http://www.opensciencemap.org/. About misconceptions 2. and 3. - usually vector data is smaller than raster data, but I cant tell how it would work in this case, thats true. I guess lack of browser support is the answer I was looking for.
(13 Jan '13, 23:39)
Expro
|
|
Have a look at the Kothic JS demo, even though it's fast it's alot slower than pngs, and it seems to takes up more or less the same amount of bandwidth. So basically it doesn't quite work on osm.org yet, but try kothic out it's pretty amazing. This is canvas rendering - so its basicly exacly same thing as rendering SVG data to raster on server side, but it simply happens on client side. What I had in mind was simply serving SVG embaded inside HTML page. Thanks for interesing link though!
(13 Jan '13, 23:21)
Expro
Well, unless you want to view the raw xml, it eventually has to be rendered into pixel based images, if it is SVG or some other vector format. The tiles that are served for KothicJS are simple vector data, so you can do other things with it than render it to a bitmap. What are you trying to achieve with "SVG embedded inside HTML" other than what KothicJS does? But as Frederik said, the underlying OSM data is not stored as SVG, so one would need to "render" it to SVG to start with.
(13 Jan '13, 23:36)
apmon
Currently, browsers are able to render embedded SVG on their own - no need to write (client side) renderer engine, as KothicJS did with use of canvas. But need of casting internal data format to SVH still remains as was pointed.
(13 Jan '13, 23:44)
Expro
@stephan75 Yeah, its esentially what I had in mind. And its really fast at desktop machine.
(14 Jan '13, 20:21)
Expro
But they aren't using SVG either, are they?
(16 Jan '13, 13:40)
emj
Also try using their public transport map on a nettop/netbook. Slow, zoom stops working after a while,...
(16 Jan '13, 17:04)
cartinus
showing 5 of 7
show 2 more comments
|
|
OSM isn't one map - it's the data. There are lots of OSM-based maps, some vector-based. The way that progress happens (e.g. the recent move to Leaflet) is that someone goes away and makes a variant that is an improvement, and it gets incorporated. The way that it doesn't happen is with people say "the volunteers who develop and run OSM services ought to do X". As software developer im quite aware of how open source projects usually develops. I was simply asking what is a reason of current state of OSM - not even remotly suggesting that this state should be different.
(13 Jan '13, 23:36)
Expro
|
|
I am guessing because not all browsers will display svgs as fast as rasters(IE mobile) also like all big projects it takes some time to change or update things.(Don't break what you already have). I would think that the devs are at the very least testing it out. Remember it has to work almost everywhere at a decent speed otherwise there will be a lot of complaints. With mobile devices it is better a server does the hard work than the device with limited resources and battery. Also there would need to be some work on the theme which also takes work and testing. I also think it needs mapnik2 and don't know if they switched over to mapnik2. |
