search

ngageoint / hootenanny-ui

Hootenanny UI is a submodule of the Hootennany vector conflation project.
ISC License
28 stars 7 forks source link

Call web service which invokes core reading of OSM API DB data from ME when a hoot HOT task is launched #683

Closed bwitham closed 7 years ago

bwitham commented 8 years ago

Depends on ngageoint/hootenanny-ui#679

related to https://github.com/ngageoint/hootenanny/issues/1016

brianhatchl commented 8 years ago

@bwitham For this ticket, did you envision that the reading of OSM API DB data and writing of Hoot map dataset would occur as a separate step first before conflation, so the user has a chance to see the OSM API data on the map overlaid with the secondary data?

bwitham commented 8 years ago

Yeah, that's what I was thinking. After that all display requests would go to the hoot api db and the next interaction with the osm api db wouldn't be until it was time to save the changeset containing the conflation output.

brianhatchl commented 8 years ago

Okay. So we'll need a new services resource for that similar to FileUploadResource only IngestFromApiDbResource that takes the bbox we want hoot to ingest. Or was there another existing code path that you thought could be used?

bwitham commented 8 years ago

I think we do need a new resource class like that. The existing services logic ingests from the osm api db after the conflate button is clicked.

Configuration for that in the ConflationResource happens here:

https://github.com/ngageoint/hootenanny/blob/develop/hoot-services/src/main/java/hoot/services/controllers/job/ConflationResource.java#L160

That info gets passed by the services into makeconflate here to read a bounded set of osmapi db data into the hootapi db:

https://github.com/ngageoint/hootenanny/blob/develop/scripts/makeconflate#L46

So, I think that logic needs to come out of ConflationResource and then something very close to it goes into this new resource. On the other end, the logic that the services have to write data back to the osmapi db from the services (in the export resource and scripts/osm2ogrscript) hopefully shouldn't have to be changed too much.

bwitham commented 8 years ago

This issue is the services side of this functionality: https://github.com/ngageoint/hootenanny/issues/1016

brianhatchl commented 8 years ago

Got it, thanks. I think initially I will try to get the conflation using task grid working the "old way". The OSM_API_DB layer will be used and the data will be read from the api db as part of the conflation job.

This way, we could consider the autoconflate strategy I described below.

Do we want the launch conflation task url to configure and autostart that conflation? Should conflation params be set as task manager project properties so users cannot adjust them?

With this approach, the first thing the user will see when launching a Hoot conflation task is the conflated output in review mode.

bwitham commented 8 years ago

Got it. I see what you're saying. I hadn't thought about auto-conflating it from the start. That's definitely an easier path to start out on, since the code to do that should mostly be in there.

I was thinking maybe someone would want to see data beforehand, unconflated in certain situation to see what they were getting themselves into before conflation. We can ask if that's a desirable feature in the long run and make the auto-conflate optional if so, but if not, then we don't need to worry about that option.

brianhatchl commented 7 years ago

In the holy grail iD 2.x branch, OSM API data can be added to the map along with Hoot datasets, so this ticket has been OBE.