IsraelHikingMap / Site

Israel Hiking Map has maps, route planning, and travel information for Israel. This repository holds the files needed for running the Israel Hiking Map site and apps.
https://israelhiking.osm.org.il/
Other
76 stars 31 forks source link

Deleted POI is not in database #1971

Open HarelM opened 3 months ago

HarelM commented 3 months ago

What happened?

The following POI is not in the database: https://israelhiking.osm.org.il/poi/OSM/node_278476882 It is deleted in OSM: https://www.openstreetmap.org/node/278476882

This causes a problem in the client where this point is never deleted due to how the sync between the client and the server works.

What steps will reproduce the bug?

Still unclear, might be related to how the update process is behaving

What I expect to happen

The above POI should return a status deleted from the API, like the following: https://israelhiking.osm.org.il/poi/OSM/node_278477726 https://israelhiking.osm.org.il/api/points/OSM/node_278477726 But it doesn't

Platform

OS Name and Version

Any

Browser Name and Version

Any

Additional information

I'll add some logging to see what can cause this. In general deleted POIs should be kept in the database "forever" and the total number of deleted points should always go up. This doesn't look like the case looking at the logs.

HarelM commented 3 months ago

Phone call conversation: The way forward is probably by moving the sync part of the process to be tiled based file. This way, there's no need to sync the client with updates and there's no need to call the server with "give me points" in the screen as this will work much like other things related to map/tiles. In order to POC this, we'll need to take the offline POIs file and create tiles from it. Change the POI presentation and filtering in the UI to allow using tiles instead of indexDB.

HarelM commented 3 months ago

Interestingly enough, using querySrouceFeature, with a circle transparent layer produces the following (there's no icon and no description, and other properties that the UI is expecting, but it looks like it's feasible): Image This approach allows clustering, as the cluster is done using html from the return value of the queried source. There is a "caveat" that features that are spanning across multiple tiles will return multiple "feature" thus causing the location of the POI "head" to move when you move the map and get different tiles. I don't see this as a show stopper, and can probably be fixed using some heuristics (same as duplicate features).

HarelM commented 3 months ago

Using the converted POI.zip the following image is what we get from the POIs layer, which is very good: image I was also being able to apply the filtering on the data (after getting it from the source, there might be optimizations available, but current code is "fast enough"). There is still no offline support. There is a need to fix some moveend behavior due to how this was handled before. There are places I need to clean up existing code still. There's still a need to define the process better, as the current output still needs a bit of work in the client side, which misses the point a bit I think, as this source is very specific to this need and there should not be extra processing, I believe.

HarelM commented 3 months ago

The following is acting a bit weird: Zoom 13 I see the following POIs: image And in 12 Is see the following - which is significantly less image

HarelM commented 2 months ago

Current progress: It seems that most POIs are now presented from POI layer. We have decided to avoid the usage of polygons in the POI layer and we won't present images when offline. Still need to be done:

  1. Solve external sources (iNature, Nakeb, Jeepolog)
  2. Do a bulk update of OSM with the merge results of wikipedia data
  3. Solve offline mode - pois and maybe search
  4. Move Images allow list to client