Others can correct me if I'm wrong, but I think the problem is not
really limited computing power, but it's a design thing. Update speed
has a really high priority, too high if you ask me. So regardless of
computer power available, we want the fastest update speed possible.
For the main servers, as far as I understand they have ready-made tiles
basically for the whole world. So there's always a tile ready to serve.
When a database update comes in and a tile needs updating the old tile
will continue to serve normally until the new is available. To give
casual mappers feedback quickly we like this to happen fast. However as
the web browsers cache data the mapper may see old data for a long time
anyway, so I don't really think update needs to be fast (instead the
user interface needs a mechanism to provide the mapper with progress
information of the rendering), and then we can switch algorithms to more
advanced and slower ones which focus more on cartography and less on
speed.
However (this is a bit of my guesswork, I haven't read up 100% on this)
then we have all those private small servers serving tiles. In this case
the hardware is quite simple and inexpensive and there's no practicality
in having pre-made tiles for all the world, so you need to render
on-demand. In this case it's of course of key importance that these
tiles render really quickly or else the map simply won't appear when you
browse to view it.
I think what OSM needs now is that the main style presented to end users
and mappers should be one with more expensive algorithms and a high
focus on making the best possible cartography, and also focus on
supporting all necessary features so mappers are motivated to tag the
data correctly and detailed (ie we have some need in naming groups and
areas etc previously discussed). This will be considerably slower to
render and possibly quite difficult to develop.
Then a computationally fast style could still be maintained for the
on-demand use case. If we're smart we make them look similar, so the
fast style could be used on-demand and trigger a background process with
the slow style that fills up the area in time, as the map is generally
viewed again in the same place.
On 2020-11-07 12:13, Walker Bradley wrote:
Dear all,
First off I would like to state how fascinating this conversation is. I've been working with OSM data for years, and I never understood how the rendering actually worked. It seems like the challenges are two-fold. One is computing power and the other seems to be rendering algorithms.
Computing power seems to be a constraint struggle without greater fundraising capacity, so could there be some work done on the rendering process? Could we do a specific and targeted fundraising effort to improve the renderer to make as much use of the limited computer power we have? How much would such an endeavor actually cost and how would one go about organizing that?
On Nov 7, 2020, at 10:36, Anders Torger <and...@torger.se> wrote:
Sorry, I'm no expert so I should have been more humble and not state it as a "fact". I *think* multipolygon was supposed to be a way to make single entities of complex shapes, and these groups are not really single entities, but multiple entities with single names, and thus I find it "superior" to have a specific tag for that. I'm satisfied with using a multipolygon though, and that is what I do now. This group naming is fairly common where I map that I need it now and can't wait until some unspecified time in the future when a specific group tag might be rendered.
I suppose you could turn the argument around and say that it's better to use multipolygon and not add bloat with a specific tag. And when the state is as it is, the multipolygon way is the closest to actually do what we need, I can agree with that. I'm all for results.
/Anders
On 2020-11-07 06:57, Mateusz Konieczny via Tagging wrote:
Nov 6, 2020, 23:39 by and...@torger.se:
One example is making a multipolygon instead of the semantically superior group, as multipolygon actually renders.
Why multipolygon is supposed to be semantically inferior?
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
