OpenAtlas

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.

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.

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.

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.

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.

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.