Features being removed from the view without them being removed :(.

[Infiniverse]

Hi Matt,

We've got a problem with features going missing - we add them, but sometimes they disappear from the OLVectorSource without being explicitly deleted. I'm pulling my hair out trying to track down why it's happening. I'd appreciate any thoughts please - happy to put more leg work in, but I could do with a hand please?

My code is very easy - we've got a wrapper for OLVectorSource which had an add and remove method:

@Override
void addFeature(Wgs84Feature feature) {
    System.err.println("VL: ADD FEATURE: ${feature.feature.id}")
    def size = vectorSource.features.size()
    System.err.println("VL: BEFORE ADD: ${vectorSource.features.size()} ${vectorSource.features.id}")
    vectorSource.addFeature(converter.makeFeature(feature))
    System.err.println("VL: AFTER ADD: ${vectorSource.features.size()} ${vectorSource.features.id}")
    assert size == vectorSource.features.size() - 1
}

@Override
void removeFeatureById(long id) {
    System.err.println("VL: REMOVE FEATURE: ${id}")
    def size = vectorSource.features.size()
    System.err.println("VL: BEFORE REMOVE: ${vectorSource.features.size()} ${vectorSource.features.id}")
    vectorSource.removeFeatureById("${id}")
    System.err.println("VL: AFTER REMOVE: ${vectorSource.features.size()} ${vectorSource.features.id}")
    assert size == newSize = vectorSource.features.size() + 1
}

What we see periodically are features just disappear from vectorSource.features without being explicitly removed.

Below I've add '***' to make it clear, but look feature 26906 was present before and after we removed feature 26563, but it was not present immediately afterwards when we went to add feature 26708.

All we did between the remove and add was scroll the view port a bit. Is there something going on which removes features implicitly?

VL: REMOVE FEATURE: 26563
VL: BEFORE REMOVE: 54 [8266, 26600, 26601, 26597, 26592, 26599, 26598, 26580, 26567, 26563, 26538, 26539, 26537, 26543, 26544, 26545, 26546, 26547, 26541, 26700, 26707, 26705, 26706, 26711, 26713, 7897, 7898, 26690, 26691, 26692, 26693, 26694, 26695, 26696, 26698, 26697, 26699, 26665, 26686, 26687, 26688, 26689, 26685, 26684, 26802, 26801, 8797, 8799, 8798, 8794, *** 26906 ***, 26924, 8800, 8801]
VL: AFTER REMOVE: 53 [8266, 26600, 26601, 26597, 26592, 26599, 26598, 26580, 26567, 26538, 26539, 26537, 26543, 26544, 26545, 26546, 26547, 26541, 26700, 26707, 26705, 26706, 26711, 26713, 7897, 7898, 26690, 26691, 26692, 26693, 26694, 26695, 26696, 26698, 26697, 26699, 26665, 26686, 26687, 26688, 26689, 26685, 26684, 26802, 26801, 8797, 8799, 8798, 8794, *** 26906 ***, 26924, 8800, 8801]
VL: ADD FEATURE: 26708
VL: BEFORE ADD: 30 [8266, 26600, 26601, 26597, 26599, 26598, 26567, 26700, 26707, 26705, 26706, 26713, 7898, 26690, 26692, 26693, 26694, 26695, 26696, 26698, 26697, 26699, 26686, 26687, 26688, 26689, 26685, 8799, 8798, 8801]
VL: AFTER ADD: 31 [8266, 26600, 26601, 26597, 26599, 26598, 26567, 26700, 26707, 26708, 26705, 26706, 26713, 7898, 26690, 26692, 26693, 26694, 26695, 26696, 26698, 26697, 26699, 26686, 26687, 26688, 26689, 26685, 8799, 8798, 8801]

[Infiniverse]

Looking more deeply at the code it appears that features can be deleted by RPC:

OLVectorSourceServerRpc has a method called featureDeleted which appears to be called as a call back from JavaScript?, and causes a feature to be deleted.

In what circumstances would the user interface be allowed to remove a feature that the user added? That doesn't seem right?

[Infiniverse]

The origin of the deletes appears to be an RPC call of the form:

{"csrfToken":"4f8e63e7-1b43-4aad-aea6-8e3d1d98e87e", "rpc":[
  ["7","org.vaadin.addon.vol3.client.OLViewServerRpc" ,"updateCenter",[{"x":-2.438535690307617,"y":51.32691107277063}]],
  ["7","org.vaadin.addon.vol3.client.OLViewServerRpc","updateExtent",[-2.4621391296386723,51.32172173420898,-2.4149322509765625,51.332099824173014]],
  ["7","org.vaadin.addon.vol3.client.OLViewServerRpc","flush",[]],
  ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["25670"]],
  ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["74"]],
  ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["14908"]],
  ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["14913"]],
  ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["13149"]],
  ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["9119"]],
  ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["8890"]]
],"syncId":9,"clientId":9}

Perhaps it's the flush that's causing the features to be deleted. I'm reasonably certain that my code did not originate these delete requests.

[mhosio]

Hello Josef,

Yes, the deletion of the features in deed seems to originate from client side. The flush should have nothing to do with that though. It is just called to send center and extent updates to server. Have you added any interactions to the map? As far as I recall, you could initiate a feature deletion via an interaction (select / modify).

Just to be sure: are you using the latest released version of the add-on?

Regards, Matti

On Wed, Jul 13, 2016 at 8:35 AM, Dr Josef Karthauser < notifications@github.com> wrote:

The origin of the deletes appears to be an RPC call of the form:

{"csrfToken":"4f8e63e7-1b43-4aad-aea6-8e3d1d98e87e", "rpc":[ ["7","org.vaadin.addon.vol3.client.OLViewServerRpc" ,"updateCenter",[{"x":-2.438535690307617,"y":51.32691107277063}]], ["7","org.vaadin.addon.vol3.client.OLViewServerRpc","updateExtent",[-2.4621391296386723,51.32172173420898,-2.4149322509765625,51.332099824173014]], ["7","org.vaadin.addon.vol3.client.OLViewServerRpc","flush",[]], ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["25670"]], ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["74"]], ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["14908"]], ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["14913"]], ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["13149"]], ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["9119"]], ["13","org.vaadin.addon.vol3.client.source.OLVectorSourceServerRpc","featureDeleted",["8890"]]],"syncId":9,"clientId":9}

Perhaps it's the flush that's causing the features to be deleted. I'm reasonably certain that my code did not originate these delete requests.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/VOL3/v-ol3/issues/77#issuecomment-232260798, or mute the thread https://github.com/notifications/unsubscribe/AF0lp90LgKdEbLIDMgc_5CipGY30oWf7ks5qVHkWgaJpZM4JKjFw .

[Infiniverse]

Hi Matti,

I think so - we're running the released version 1.1.

We are also using interactions, but only one feature at a time with a modification interaction. In the case that I'm reporting here we are not applying any interactions, just adding and deleting features as the map is scrolled around.

I've been trying to find in the Open Layers docs what the behaviour should be, but I can't find anywhere a report of features being preemptively removed :(.

[Infiniverse]

Ok, I think I finally worked out what's going on.

We are calling vectorSource.removeFeatureById(id), but the removal isn't happening immediately, instead it's being queue to be sent asynchronously to the client.

In the mean time we are re-adding that very same feature, because perhaps it's now back on-screen.

Then the client is told to remove it, and does - but we still think that it's on-screen because we just re-added it. :(.

Does that sound plausible? If so, it sounds like we should be constructing our feature ids in a more unique way, instead of using the id of the underlying feature object from our database.

[mhosio]

In case you are adding the features from a background thread, that sounds very much plausible. Deleting a feature from the map in deed results in a rpc for the deletion back from client side. This is actually something I could fix in the upcoming release. In the mean time, you could go around this by customizing the ids for the features as you suggested. Thank you for spotting this bug.

-Matti

On Wed, Jul 13, 2016 at 2:04 PM, Dr Josef Karthauser < notifications@github.com> wrote:

Ok, I think I finally worked out what's going on.

We are calling vectorSource.removeFeatureById(id), but the removal isn't happening immediately, instead it's being queue to be sent asynchronously to the client.

In the mean time we are re-adding that very same feature, because perhaps it's now back on-screen.

Then the client is told to remove it, and does - but we still think that it's on-screen because we just re-added it. :(.

Does that sound plausible? If so, it sounds like we should be constructing our feature ids in a more unique way, instead of using the id of the underlying feature object from our database.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/VOL3/v-ol3/issues/77#issuecomment-232324394, or mute the thread https://github.com/notifications/unsubscribe/AF0lpwuTUSdW-wZzrhz2B5i3G2lsoSh1ks5qVMZIgaJpZM4JKjFw .

[Infiniverse]

Not at all. Thanks for responding. :)

Cheers, Joe

BTW, whilst I have you I reported on the forum that I couldn’t get the bing maps to work - I’d very much appreciate a hint on that if you were so inclined :). Many thanks in advance.

On 13 Jul 2016, at 13:05, Matti Hosio notifications@github.com wrote:

In case you are adding the features from a background thread, that sounds very much plausible. Deleting a feature from the map in deed results in a rpc for the deletion back from client side. This is actually something I could fix in the upcoming release. In the mean time, you could go around this by customizing the ids for the features as you suggested. Thank you for spotting this bug.

-Matti

On Wed, Jul 13, 2016 at 2:04 PM, Dr Josef Karthauser < notifications@github.com> wrote:

Ok, I think I finally worked out what's going on.

We are calling vectorSource.removeFeatureById(id), but the removal isn't happening immediately, instead it's being queue to be sent asynchronously to the client.

In the mean time we are re-adding that very same feature, because perhaps it's now back on-screen.

Then the client is told to remove it, and does - but we still think that it's on-screen because we just re-added it. :(.

Does that sound plausible? If so, it sounds like we should be constructing our feature ids in a more unique way, instead of using the id of the underlying feature object from our database.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/VOL3/v-ol3/issues/77#issuecomment-232324394, or mute the thread https://github.com/notifications/unsubscribe/AF0lpwuTUSdW-wZzrhz2B5i3G2lsoSh1ks5qVMZIgaJpZM4JKjFw .

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/VOL3/v-ol3/issues/77#issuecomment-232335407, or mute the thread https://github.com/notifications/unsubscribe/ACpRrsgqj-V2plfxOPIcnR8ounjptKXuks5qVNSggaJpZM4JKjFw.

[mhosio]

Hello Joe,

Don't have any experience on the Bingmaps so can not help you with this. Maybe @Styp can help you with this?

[Styp]

@Infiniverse drop me an email, i'll try to help you. Sorry, did not saw the message, was a little busy the last few months ;).

[Infiniverse]

Hi Martin,

Not to worry - I managed to work it out in the end. Didn’t realise that I needed a maps key to get it working.

Cheers, Joe

On 29 Aug 2016, at 07:39, Martin Stypinski notifications@github.com wrote:

@Infiniverse https://github.com/Infiniverse drop be an email, i'll try to help you. Sorry, did not saw the message, was a little busy the last few months ;).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/VOL3/v-ol3/issues/77#issuecomment-243043633, or mute the thread https://github.com/notifications/unsubscribe-auth/ACpRrkeXLOVdzsUjm0lIAiO085UUXgGOks5qkn6MgaJpZM4JKjFw.

[Styp]

awesome!