Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Change parcels from LDS schema to the BDE schema #183

Open
billgeo opened this issue Sep 7, 2016 · 13 comments
Open

Change parcels from LDS schema to the BDE schema #183

billgeo opened this issue Sep 7, 2016 · 13 comments

Comments

@billgeo
Copy link
Contributor

billgeo commented Sep 7, 2016

Switch the map back to getting all it's data from BDE schema.

TWG will decide this on Friday.

@billgeo billgeo self-assigned this Sep 7, 2016
@palmerj
Copy link

palmerj commented Sep 7, 2016

Can you please specify what the map requirements are in QGIS? Does it need the LDS primary parcels layers because it has title references and the appellation string?

@billgeo
Copy link
Contributor Author

billgeo commented Sep 7, 2016

Just spoke with Simon about this. He has a few map layers which he is going to investigate switching to the BDE schema or LDS WFS.

  1. primary parcel spatial extents
  2. pending parcel spatial extents
  3. parcel labels showing title numbers

@palmerj
Copy link

palmerj commented Sep 7, 2016

Is there a requirement to have the data in sync with the AIMS database parcels (e.g crs_parcel)

@billgeo
Copy link
Contributor Author

billgeo commented Sep 7, 2016

This is the filter that you need to use to get primary current and primary pending

Current

    SELECT *
    FROM bde.crs_parcel ap
    WHERE ST_GeometryType(ap.shape) IN ('ST_MultiPolygon', 'ST_Polygon')
    AND ap.status = 'CURR'
    AND ap.toc_code = 'PRIM';

Pending

    SELECT *
    FROM bde.crs_parcel ap
    WHERE ST_GeometryType(ap.shape) IN ('ST_MultiPolygon', 'ST_Polygon')
    AND ap.status = 'PEND'
    AND ap.toc_code = 'PRIM';

@linzbjones
Copy link

TWG @palmerj is there anything that you are expecting changed in the UI as a consequence of your changes?

@palmerj
Copy link

palmerj commented Sep 12, 2016

Note completely sure on the UI within the plugin because I've never seen it!

But one issue could be the context parcels layer in QGIS. Simon tried to swap this out for a derived query to retain the appellation but had performance and correctness issues. See my comment here: #184

@billgeo
Copy link
Contributor Author

billgeo commented Sep 27, 2016

In answer to @linzbjones question. No. This is all backend stuff and AIMS API and UI should work exactly the same.

@billgeo
Copy link
Contributor Author

billgeo commented Sep 27, 2016

@SPlanzer to close once he's swapped the UI over to "bde" schema tables.

@billgeo billgeo removed their assignment Sep 27, 2016
@billgeo
Copy link
Contributor Author

billgeo commented Oct 19, 2016

@SPlanzer, as discussed. Look at all options to get the appellation for the map display, including temporary workarounds and put here so we can decide on acitosn

@billgeo
Copy link
Contributor Author

billgeo commented Oct 20, 2016

HI @SPlanzer, we are having a TWG at 3pm today. Are you able to add this info before then please?

@SPlanzer
Copy link

The spatial parcels have been migrated from the LDS data to BDE.

However, the addressing team have a requirement to have these parcels labelled with there corresponding appellation - THIS IS STILL OUTSTANDING

Several options have been explored to label these parcels.

  • utilising the LDS WFS feed has been considered
    • However, data would be up to a week out of date. It is my understanding this does not suffice
  • The UI selecting a database view
    • This triggers a view to be compiled when the plugin loads. It causes the plugin to take > 10 min to load.
    • It is possible this could be optimised but would still mean the plugin will not load in an acceptable time
  • A materialised view has been compiled and a trigger created to refresh the materialised view when the bde.crs_parcels table is altered.
    • This porives the AIMS UI users with the up to date labels they require without causing any latency.
    • This has been tested and shown to work, however, testing still needs to be undertaken with the overnight bde_loader running to ensure the triggering of the materialised view refresh does not conflict with the bde_loader.
    • The addressing team has expressed they can go live with the proviso that this solution would be further tested over the coming weeks and rolled out shortly after go live
    • this solution is branched

@palmerj
Copy link

palmerj commented Oct 21, 2016

I would say another option is to rewrite the appelation pl/pgsql function to sql. That would allow good performance on a non-materialised view.

@billgeo
Copy link
Contributor Author

billgeo commented Oct 21, 2016

TWG: Addressing team has workarounds for this and can live without this function for 3 weeks.

@SPlanzer SPlanzer removed their assignment Oct 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

4 participants