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

As an APP developer I would like to get through the edge method of the ODH API also the geometries of the A22 LinkStations #174

Closed
3 tasks done
rcavaliere opened this issue Oct 1, 2020 · 13 comments
Assignees

Comments

@rcavaliere
Copy link
Member

rcavaliere commented Oct 1, 2020

TODOS

  • @Piiit Adapt the schema that edges shouldn't have origin and destination mandatory, since some geometries are not connected to stations inside bdp-core/dal
  • @Piiit Allow API v2 to expose edges without origin and destination
  • @rcavaliere Import new edge data and new geometries

OLD COMMENT:

Still need to be created in the ODH core, will be available through the "edge" method as for the other LinkStations

UPDATE BY @Piiit
This means, that the edges shouldn't have origin and destination mandatory, since some geometries are not connected to stations.

I performed the following changes on prod and test:

ALTER TABLE intimev2.edge ALTER COLUMN edge_data_id SET NOT NULL;
ALTER TABLE intimev2.edge ALTER COLUMN destination_id DROP NOT NULL;
ALTER TABLE intimev2.edge ALTER COLUMN origin_id DROP NOT NULL;

This was done manually, we need Flyway for bdp-core... The issue for that is #185

@rcavaliere rcavaliere self-assigned this Oct 3, 2020
@rcavaliere
Copy link
Member Author

rcavaliere commented Oct 23, 2020

First geometries have been created, but are not currently visible on the API. Next steps:

@Piiit
Copy link
Contributor

Piiit commented Nov 23, 2020

@rcavaliere I would like to finalize this issue and the related one? Is this about the edges without start and ending stations?

@rcavaliere
Copy link
Member Author

Yes. Origin and destination shouldn't be mandatory in the edge table since in some cases we don't have them as stations in the station table

@Piiit Piiit self-assigned this Nov 23, 2020
@Piiit
Copy link
Contributor

Piiit commented Nov 26, 2020

We have two possible solutions here:

  1. Use stations directly and add a field for polyline geometries (API calls must then be made against nodes and not edges). This would involve a check and probably a change in the station data model (I told you otherwise yesterday, but after a check I've got some doubts if that would be that easy)

  2. Create tangling edges, that is edges without origin and destination stations (this is the original idea we had), althout in mathematical terms this would not be an edge anymore if we look at graph theory, where edges are pairs of nodes.

Maybe we should think from the POV of our API consumers. I do not know yet, what they would like to have here, and what is easier to understand? Maybe just define points on a map as nodes and any (connected or not-connected) polygon as edge (in the sense of a multiline and less of graph edges).

What do you think? @bertolla @rcavaliere

@rcavaliere
Copy link
Member Author

@Piiit I would go in direction 2.
I agree, maybe the term "edge" is a little bit misleading if we mix up things.
Actually the LinkStations associated to BluetoothStations can be handled as "edge", whereas LinkStations that do not have such reference should be handled as simple polygons... Maybe the solution could be foresee a separate table, equivalent to edge, named "polygon", without origin and destination reference (only a reference to the LinkStation ID of station), in which we save the geometry of such LinkStations?

@Piiit
Copy link
Contributor

Piiit commented Nov 27, 2020

@rcavaliere Please insert an edge without starting and ending stations, I hope it works ... I will test it also after the meetings today

@Piiit
Copy link
Contributor

Piiit commented Nov 27, 2020

@rcavaliere I have created an example for you... query as follows:

https://mobility.api.opendatahub.testingmachine.eu/v2/flat,edge/*?where=sbactive.eq.null

@Piiit Piiit removed their assignment Nov 27, 2020
@rcavaliere
Copy link
Member Author

I had already added in my QGIS project a geometry of an A22 LinkStation: https://cloud.opendatahub.bz.it/index.php/s/zfGLREeJAKcWQng
I already uploaded it in the core according to https://github.com/noi-techpark/bdp-elaborations/tree/master/ShapefileFeatureImporter
Here my PR: noi-techpark/bdp-elaborations@2bbcddb
Can you check with this?

@Piiit Piiit self-assigned this Nov 30, 2020
@Piiit
Copy link
Contributor

Piiit commented Dec 11, 2020

@rcavaliere I have written some flight rules for you. Now, I will put this into production, such that, we can try the shape importer with it... what do you think?

Link: https://github.com/noi-techpark/documentation/blob/master/README.md#i-want-to-create-links-between-stations

@rcavaliere
Copy link
Member Author

Perfect!!

@Piiit
Copy link
Contributor

Piiit commented Dec 17, 2020

@rcavaliere I've put all into production, please run your importer... Do you still need something from me?

@Piiit Piiit removed their assignment Dec 17, 2020
@rcavaliere
Copy link
Member Author

No, I will start with this activity, probably next week. Thanks!

@Piiit
Copy link
Contributor

Piiit commented Dec 17, 2020

top!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants