GNOME Bugzilla – Bug 734628
ChamplainTile signal "render-complete" doesn't use data type of the rendered callback.
Last modified: 2018-05-22 12:58:10 UTC
I am caching POIs as in bug #731587. https://bugzilla.gnome.org/review?bug=731587&attachment=282181 But I am unable to pass the data (second parameter) to the emit function If I do, "tile.emit('render-complete', this.data, this.data.length, false);" It throws """ (gnome-maps:12007): GLib-GObject-CRITICAL **: g_value_unset: assertion 'G_IS_VALUE (value)' failed (gnome-maps:12007): Gjs-WARNING **: JS ERROR: Error: Cannot convert non-null JS value to G_POINTER """ The render-complete signal assumes second argument to be of type pointer, but it may not be the case, for example, a list of POIs is a JSON String that needs to be cached. Only passing "null" as second argument works, which is very hacky and potentially unsafe. "tile.emit('render-complete', null, this.data.length, false);" So, I think that "render-complete" should use the data type of the argument that is passed to it. It may as well be a GJS bug, as it may not be able to convert String to gpointer. But, I wanted to get opinion from here first. Can, it be made to take data-type of argument. ?? Please guide me, as how to approach it, as it is very crucial for the POI rendering and maps.
Well, I think you've just found one place where libchamplain isn't fully introspectable (there are a few more of them) so bindings don't work correctly for them. This however requires API change so it won't happen in the 0.12.x release. However, in my opinion (and it's quite possible I don't understand what you are trying to achieve so I may be wrong), misusing libchamplain cache for storing POI information isn't a good approach. libchamplain cache is tile-based so if you store some POIs which appear within the given tile at certain zoom level, they won't be available at other zoom levels. I'd suggest implementing your own cache - it can be something very simple, all you need is some key-value database (which can also be implemented just using files and directories).
(In reply to comment #1) > Well, I think you've just found one place where libchamplain isn't fully > introspectable (there are a few more of them) so bindings don't work correctly > for them. This however requires API change so it won't happen in the 0.12.x > release. > > However, in my opinion (and it's quite possible I don't understand what you are > trying to achieve so I may be wrong), misusing libchamplain cache for storing > POI information isn't a good approach. libchamplain cache is tile-based so if > you store some POIs which appear within the given tile at certain zoom level, > they won't be available at other zoom levels. True. > > I'd suggest implementing your own cache - it can be something very simple, all > you need is some key-value database (which can also be implemented just using > files and directories). I also suggested the same to implement my own caching, but Jonas insisted that we stick to libchamplain for that. I am able to achieve it but in a very hacky manner. I would require inputs from Jonas and Mattias whether I should implement my own caching.
(In reply to comment #1) > However, in my opinion (and it's quite possible I don't understand what you are > trying to achieve so I may be wrong), misusing libchamplain cache for storing > POI information isn't a good approach. libchamplain cache is tile-based so if > you store some POIs which appear within the given tile at certain zoom level, > they won't be available at other zoom levels. The idea is to actually treat the POI's as (vector) tiles, so that we have the possibility of filtering out different types of POI's on differerent zoom levels. From there it seems obvious to just re-use the tile cache in Champlain. I haven't been able to follow Rishi's work as much as I have wanted to say if this means having to do really weird hacks. If so we probably need to re-think our approach.
Well, for me it felt like the right thing to do to use the champlain overlay-source framework for overlaying POIs on the map at certain zoom levels. And the cache was a bonus. We could still implement our own caching within in the framework of the overlay source tho, if we wanted. But the approach was that we rendered the poi data, stored in the cache, as a tile of sorts. And cached that.
Hi Jonas & Mattias, thanks for your feedback. The problem is that map sources/caches are tile-based so what you get from it is just a square bitmap tile which is then placed on the panning map. If you put a POI marker into the tile directly, it gets clipped on the border of the tile (if you remember Jonas, the same happened in the map-wrapping implementation). So this is not what you want. If you decided to just draw the POI marker, you'd have to split it into (in the worst case) 4 parts and draw the parts on the neighboring tiles - not only this is too much work but also the marker won't be interactive. In my opinion, if you want to place something interactive on top of the map, you should use layers. If I understand the problem correctly, you may want to implement a custom layer which, depending on the zoom level, filters-out some POIs and add some custom caching.
Thanks for your comment Jiri! Do you think a custom layer that places POI-markers on itself depending on the zoom-level is to prefer over some object/code that listens for zoom-level changes and places/removes POI-markers.
... and places/removes POI-markers on a plain champlain-markerlayer.
I guess it's about the same from practical point of view. I mentioned this because I actually think it would be nice to have some generalized form of such a layer directly in libchamplain so others can use it too (seems like a quite common use case to me).
Yeah, that might make sense. Atm, we get the POI information from the Overpass API (http://wiki.openstreetmap.org/wiki/Overpass_API) and the icons representing the POIs is from the maki icon set (currently installed by geocode-glib but will probably switch to gnome-maps).
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libchamplain/issues/24.