[OSM-dev] Migrating osm.org to vectors/Kartotherian

Sat Oct 31 18:43:40 UTC 2015

Thanks for all the responses! Are there any people on the stylesheet team
interested in working on this?  It might be possible to adapt osm-carto
work directly, since it is based on the same underlying technology.

Jochen, Kartotherian can dynamically alter/recombine tiles, e.g. adding
layers from multiple sources (e.g. language), or adding raster layers (both
raster and vector data can be stored in the same vtile). So we could create
a set of well-defined layers, stored either together or separate, and
combined on the fly.

Oleksiy, the true multilingual support requires Mapnik hstore support, see
#1113 [1]. Wikimedia DE might be able to help us with it, but it's still in
the air.  Another issue is Mapbox's WebGL cannot shape connected fonts yet
(e.g. Arabic), so they will still rely on the server-side renderig.

Martin:  If WebGL is a problem for mobile, they can fallback to PNGs
generated by Kartotherian, but we should consider the energy+time needed to
download high DPI PNG tiles vs smaller vector tiles + local rendering, plus
per-client customization aspects (multilingual, user-centric icons, etc)

Christoph, I agree that our current map is nowhere near as feature rich as
default OSM - we spent most of our time building the tile serving platform,
and spent very little time on the map itself.  We have even considered
using Natural Earth for the low zooms, possibly with an extra labels layer.

Benjamin, we had to alter Mapbox's Bright to use the free Google Noto
fonts. Can you help with automating WebGL setup & font generation for
Kartotherian? See [2]

Colin, we considered raster-layer combining for languages, but it might be
bad for caching, and would still require a lot of storage due to per-item
overhead. Storing all available languages in one vtile, and deciding at
render time seems more efficient.

Christoph, re multiple projections - if Mapnik implements vector tile
merging, we could in theory dynamicaly recombine tiles and change
projections, would't we? At a performance cost of course.  And we could
store some low-complexity data in the original format, converting it to the
needed tile on the fly, in any projection.

Thanks!!

[1] https://github.com/mapnik/mapnik/issues/1113
[2] https://github.com/kartotherian/osm-bright.tm2

On Sat, Oct 31, 2015 at 6:45 PM, Stadin, Benjamin <
Benjamin.Stadin at heidelberg-mobil.com> wrote:

> Hi Peter,
>
> Most what you said is already solved by data driven style possibilities
> and clustering that you have already with some existing WebGL libraries.
> E.g. which city label takes priority when zooming out over another city¹s
> label (by default the one with highest population), or whether city labels
> take priority over icons.
>
> I do not see why there would be any difference doing this on client or
> server side, besides you¹d have to adapt a few things at first of course.
> For an example, if you have an algorithm that places your labels depending
> on language and geometrical shape of labels, then this algorithm can
> likely be applied in realtime on the client side.
> If you have different anchor points for labels depending on language, then
> this is even less a problem: Decide by a filter rule in realtime which
> labels to render, each label may have a different position. This can be as
> simple as a single line in your style rule.
>
> Regards
> Ben
>
>
> Am 31.10.15 09:32 schrieb "Peter Wendorff" unter
> <wendorff at uni-paderborn.de>:
>
> >Hi Colin,
> >
> >just stitching a labels-layer and a base layer together would work, but
> >most often would not look well.
> >
> >Map rendering involves deciding which labels to show considering more
> >than just the labels, but icons and shields etc. as well to avoid
> >overlapping between all of them.
> >
> >You don't want to get a map where the label overlaps icons.
> >
> >As names in different languages differ in their need for geometrical
> >space on the map, these placement decisions have to be taken for each
> >language differently, thus the labels layer would include icons and
> >stuff like that as well - even oneway and so on.
> >
> >Of course it would be possible to do, but the result would look worse
> >than our current maps.
> >
> >regards
> >Peter
> >
> >Am 30.10.2015 um 12:41 schrieb Colin Smale:
> >> Can't we have a multi-lingual map by overlaying a base tile with a
> >> transparent text layer in the chosen language? We wouldn't *need* vector
> >> tiles for that, just a bit more storage (bitmap-based text layers should
> >> compress nicely) and clients which can handle the selection and display
> >> of the extra layer, which is pretty commonplace these days anyway).
> >>
> >> --colin
> >>
> >> On 2015-10-30 12:29, Oleksiy Muzalyev wrote:
> >>
> >>> I've heard from the OSM operations team's member at the conference
> >>> that it is the question of the servers' infrastructure cost.
> >>>
> >>> But if we have a vector-based map itself language selection, that we
> >>> could just add tags /name:fr/ or /name: ru/ and have the OSM map of
> >>> say New York in French or in Russian for tourists. Or map of Siberia
> >>> in German also for tourists, Middle East in English, etc. without any
> >>> additions cost on the server side. It is not that difficult to add
> >>> such multi-language tags. There could be also the map in Basque,
> >>> Catalan, Kurdish, Scots and other smaller (by number of speakers)
> >>> languages without any additional cost and without a civil conflict.
> >>>
> >>> I realize that mobile hardware is not enough advanced for that yet and
> >>> vector-based technology is only in an development stage.
> >>>
> >>> brgds
> >>> Oleksiy
> >>>
> >>> On 30.10.2015 12:06, Maarten Deen wrote:
> >>>> On 2015-10-30 11:53, Oleksiy Muzalyev wrote:
> >>>>> One of the advantages of the the vector-based map would be the
> >>>>> multilingualism.
> >>>>>
> >>>>> For instance at the moment the OSM map of the Middle East is
> >>>>>basically
> >>>>> useless for me as I do not know the Arabic alphabet yet. But as far
> >>>>>as
> >>>>> I understand and as I heard at the conference the vector-based map
> >>>>> would allow the choice of a language of the map itself.
> >>>>
> >>>> I do not see how that can not be solved with png-based tiles. You
> >>>> only have to render the tiles.
> >>>> The method for detecting which tileset/language to show is the same.
> >>>>
> >>>> BTW: it is still not as simple as rendering "in a different
> >>>> language". Then you start rendering a map in English and see names
> >>>> like "Cologne" or "Brussels"  show up on the map.
> >>>>
> >>>> Regards,
> >>>> Maarten
> >>>>
> >>>> _______________________________________________
> >>>> dev mailing list
> >>>> dev at openstreetmap.org
> >>>> https://lists.openstreetmap.org/listinfo/dev
> >>>
> >>>
> >>> _______________________________________________
> >>> dev mailing list
> >>> dev at openstreetmap.org <mailto:dev at openstreetmap.org>
> >>> https://lists.openstreetmap.org/listinfo/dev
> >>
> >>
> >> _______________________________________________
> >> dev mailing list
> >> dev at openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/dev
> >>
> >
> >
> >_______________________________________________
> >dev mailing list
> >dev at openstreetmap.org
> >https://lists.openstreetmap.org/listinfo/dev
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20151031/3f54603b/attachment.html>