I think it would be good to have a testbed for it that could then evolve
towards replacing the current stack, but as it is quite a complex and
ambitious project there should be some sort of roadmap for it, what are
the goals and how they should be reached.
Some more thoughts from the top of my head (rather from a project
perspective than from a technical viewpoint):
I'm not sure if this is exclusively something for the stylesheet team
(what is it anyway, contributors to osm-carto? maintainers?) as the
vector tiles need to be specified and styled, which is a bit more than
what is done today since vector tiles form a rather separate re-usable
component. The vector tile specification will also not only affect one
style but several styles in the long run. Actually, this would be two
projects in one.
Then there would be the need for some infrastructure, some test
rendering stack, which does not need to be super fast but should have
global coverage.
I think it is not possible to port osm-carto and keep the port in sync
with the current style. So it has to be clear from the beginning that
this would be a new style (which does not need to be really different
visually) but nevertheless being separate from osm-carto.
The specification of goals is rather important as using up a lot of
volunteer effort and having no real outcome would not be good. I know it
is hard to make promises, that's why it would be good for the project to
be backed (at least partly) by some kind of grant.
The more time people from the "stylesheet team" would spent on this
project, the less time there would be for improving osm-carto, which
could use still some improvements.
If this starts as a grassroots project it would need one or two
dedicated people to bootstrap it. From there on a team could take it
further as was done with osm-carto. Otherwise, this should be backed by
the OSMF. There should be discussion if the OSMF wants it, until when
they want it and what can be done to support it e.g. if the OSMF could
provide the infrastructure, donations or could (help) apply for a grant
to do it.
Above thoughts are for newly specifying the vector tiles for the OSM
stack and styling them by using the Kartotherian platform. If you are
talking about porting osm-carto to an existing vector tile source or
about helping with improving the already existing vector tiles and style
this would of course be a lot less effort.
nebulon42
Am 2015-10-31 um 19:43 schrieb Yuri Astrakhan:
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.sta...@heidelberg-mobil.com
<mailto:benjamin.sta...@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
<wendo...@uni-paderborn.de <mailto:wendo...@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@openstreetmap.org <mailto:dev@openstreetmap.org>
>>>> https://lists.openstreetmap.org/listinfo/dev
>>>
>>>
>>> _______________________________________________
>>> dev mailing list
>>> dev@openstreetmap.org <mailto:dev@openstreetmap.org>
<mailto:dev@openstreetmap.org <mailto:dev@openstreetmap.org>>
>>> https://lists.openstreetmap.org/listinfo/dev
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@openstreetmap.org <mailto:dev@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/dev
>>
>
>
>_______________________________________________
>dev mailing list
>dev@openstreetmap.org <mailto:dev@openstreetmap.org>
>https://lists.openstreetmap.org/listinfo/dev
_______________________________________________
dev mailing list
dev@openstreetmap.org <mailto:dev@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/dev
_______________________________________________
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
_______________________________________________
dev mailing list
dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev
