Hi Mike,
that's a good idea to tackle the fake id problem.
I didn't have time to test it but after a short look over the committed
patch I think there are a few things to be improved:
First of all small stylistic things: fields should start with lower case
letters. So OriginalId in Element should be originalId.
It would be good if you add (javadoc) comments to your source code :-)
It seems that the ways created by Multipolygon relations use the
relation id as original id. I am not sure if that's the best choice.
It's not easy to decide which id should be chosen when ways are merged.
When using the relation id it should be clear in the output that this id
is the relation id and not a way id. Otherwise users will search for
completely wrong ways.
WanMil
HI Gerd, thanks for that – I was scratching my head trying to think of a
way that would use less memory. If using the tags, each tag would have
used more than 8 bytes, although they would have only been on faked
elements. The tag iterators would also have processed them (unless
special code was included to exclude them). I did wonder whether we
could store both the original Id and the fake Id in the 64 bit number
with perhaps 40 bits for the OSM Id and 24 bits for the fake Id, but
this might not be enough space (taking into account the future).
Mike
*From:*Gerd Petermann [mailto:[email protected]]
*Sent:* 19 January 2015 20:29
*To:* [email protected]
*Subject:* Re: [mkgmap-dev] echo improvements for elements with fake ids
Hi Mike,
I've committed the patch as is. The memory impact is not that big as
we have typically less than 500.000 instances of Element in one tile,
so 8 more bytes * 500.000 ~ 4MB more heap.
Gerd
From: [email protected] <mailto:[email protected]>
To: [email protected] <mailto:[email protected]>
Date: Mon, 19 Jan 2015 11:55:00 +0000
Subject: [mkgmap-dev] echo improvements for elements with fake ids
The attached patch improves the echo and echotags messages by including the
id of the original element when a fake id is generated by mkgmap, thus
enabling you to find it in OSM.
Please try, and commit if you are happy with the change.
Regards,
Mike
_______________________________________________ mkgmap-dev mailing list
[email protected] <mailto:[email protected]>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
