Feature #1750
openLinking movements with line objects, e.g. roads
Description
It would be useful, if one could link a movement event with a specific street (in addition to the already existing "From" and "To" fields), to indicate that a movement followed a known, identifiable route (and not just its starting point and destination).
Updated by Alexander Watzinger over 2 years ago
- Subject changed from Linking movements with streets to Linking movements with line objects, e.g. streets
- Category set to Backend
- Status changed from New to Acknowledged
- Target version set to 7.8.0
Thank you for spotting and reporting this issue. We haven't thought of this before but of course it makes a lot of sense to be able to join e.g. a road, river or similar to a move event.
This should be possible even with our already existing model, nevertheless we will have to spend some thoughts on how to implement it in an intuitive way beside the existing one.
Updated by Alexander Watzinger over 2 years ago
- Subject changed from Linking movements with line objects, e.g. streets to Linking movements with line objects, e.g. roads
I'm not sure how to solve this. E.g. one very "cheap" solution would be to not change anything and decided that for these cases the place is entered in both, the from and to place.
So I put Stefan as watcher and added this issue on the agenda of our next developer meeting.
Updated by Alexander Watzinger over 2 years ago
- Start date changed from 2022-06-15 to 2022-06-07
- Follows Feature #1734: Forms: refactor functions added
Updated by Alexander Watzinger almost 2 years ago
- Status changed from Acknowledged to Assigned
- Assignee set to Stefan Eichert
Sadly we still haven't a solution for this. But I still would like to implement it so I took the liberty to assign this issue to Stefan, our model master mind, in the hope he has a good idea.
Thanks Stefan in advance, if you can't think of a solution either please note it here or we think about another approach.
Updated by Bernhard Koschiček-Krombholz almost 2 years ago
- Target version changed from 7.8.0 to 7.9.0
Updated by Stefan Eichert almost 2 years ago
- Status changed from Assigned to In Progress
I took a look at it in the CRM. Move works with start and destination, So the range of the movement is e53 Place, which in our case would be documented by a linestring space primitive. As a workaround one could document that both, start and end, are connected with the linestring.
The problem is, that from the linestring alone we cannot extract any direction. If we define the first vertex as start and the last as end, this would give us a direction. However, if movements would also be documented on the same route/linestring for the opposite direction, another identical linestring would be necessary with a reverse order of vertices.
In order to implement this, we need to overwork the concept of linestrings and think of ideas, how to map directions for move events.
I will think of possible solutions and get back to it once we have a feasible concept.
Updated by Alexander Watzinger almost 2 years ago
Thank you for raising this interesting points and you are absolutely right: of course it wouldn't help if the line object is "directed" because it could be traveled both ways, and/or only part of it.
What about leaving the from and start location as is but also add an "over" location which can be a place (like an in between stop) or a line object e.g. a road or river. This approach would solve most of the issues but question for you would be, if we can map this.
Updated by Stefan Eichert almost 2 years ago
Alexander Watzinger wrote:
Thank you for raising this interesting points and you are absolutely right: of course it wouldn't help if the line object is "directed" because it could be traveled both ways, and/or only part of it.
What about leaving the from and start location as is but also add an "over" location which can be a place (like an in between stop) or a line object e.g. a road or river. This approach would solve most of the issues but question for you would be, if we can map this.
This would of course work, but there is no CRM property that fits to it. We would probably need to do this outside the model.
Updated by Stefan Eichert almost 2 years ago
- Target version changed from 7.9.0 to Wishlist
After doing some research on this we came up with the following:
Within the CIDOC CRM it is not possible to map movements directed along a line/polyline geometry.
One could of course map a series of move events from one place to another. The more dense these places are, the more detailed the route would be documented.
Also one could map a movement from one place with point coordinates to another place with a line geometry and then to another place with point coordinates. This would indicate a starting point, a route and then the terminus. However an exact entry point, where the linestring was accessed and an exit point, where it was left would not be documented.
As a workaround I would suggest to map movements along a road or route etc. as described above. Either connecting a series of places/points with move events or with a start, linestring and an terminus point.
A possible solution to map movements along a line would be to map them by selecting a certain vertex on a linestring for the entry point and another vertex on the linestring for the exit point. However this needs to be implemented in the software first and requires certain spatial queries and intermediate entities in the backend to be created. Still this would be a very useful feature, especially considering visualisations of journeys etc.
Updated by Alexander Watzinger almost 2 years ago
- Status changed from In Progress to Acknowledged
- Assignee deleted (
Stefan Eichert)
Dear Stefan, thanks a lot for taking the time to looking into this and your valuable feedback.
So basically we would have to implement a function that creates two places (begin and end) which are located exactly on an existing line.
Although I too would find this feature very useful it would be way too time consuming to implement it now. We also would have to solve some implications first, e.g. how we handle all the added entry points, which would be places, but only used one time for a move event. They would "litter" the otherwise much more noteworthy existing places.
So we will keep this on the wishlist for now, sorry Nicholas, about that and I hope that Stefan's suggested workaround will work for you too.
Updated by Nicholas Melvani almost 2 years ago
Dear Both,
Many thanks for looking into this, I realize the complexities and really appreciate the effort. I will stay tuned for future developments!