Sorry messed up with interface, my reply was to Paul Norman but I didn't
get his message so replied to a wrong email.
I mentionned Permanent id because OSM anyway failed to implement it or
didn't want to have it with sequential id.
Best Regards,
Victor
On Sun, 25 Nov 2018 at 16:13, Tomas
Yes, I threw the idea slightly unprepared to create a discussion. May be it
shouldn't be that revolutionary as using 30 bits for geo-location index but *16
bits *wouldn't change much.
As I see, we are talking *density vs geo-index.* I understand, your point
that most of (or some) software is
If you agree that tile id is assigned only upon creation, then you don't
have to remove the history for moved or existing nodes.
Also, Google S2 gives much more standard globe locality index, if you need
a look up table.
You can try getting a pull request with the change through railsport and
Could you ealborate more on why you mention permanent id here? I see your
idea, but do not understand how it is connected to permanent id problem.
There were some tests done regarding permanent id in Lithuania, but those
were regarding places of interest.
If this has something in common, I could
On 2018-11-25 5:50 AM, Victor Shcherb wrote:
What do you think?
It would be terrible for most software that I am aware of that can
process the full planet. Current assumptions about density would be
broken, vastly inflating memory usage and slowing down processing.
The benefits aren't
Hi All,
As we know OSM id for nodes exceeded long time ago 2^32 and keep growing on
the other hand the ids itself are pretty useless because they don't
represent history good enough and also they couldn't implement principle of
Permanent ID (https://wiki.openstreetmap.org/wiki/Permanent_ID).
I
6 matches
Mail list logo
