Open ChaoticEvilDM opened 7 months ago
This will also be necessary since the distance shown is not necessarily the one being weight in by Djikstra. Future options should include a custom factor, e.g. a x1.3 if the route goes up mountains to ensure that the perils of traveling are correctly represented.
We should have a proper discussion on how to handle these objects sooner then later as the database in use right now is designed for geoinformation but not much else. This is a situation where the datamodel should be thought up up front to prevent a copious amount of work being lost when the format finally changes.
This includes an api for modding, especially in terms of access to weight data.
Based on the suggested Box solution and following the PLC concept, a path definition looks like this
{
"Path": {
"ID": 'Value'
"Length:": 'Value'
"Reference": {
"PointA": 'Value'
"PointB": 'Value'
}
"parent"= [ "path.ID" ]
"linked"= [ "path.ID", "path.ID" ]
"child"= [ "path.ID", "path.ID", "path.ID", "path.ID" ]
}
}
}
Points are currently extracted from the moveTo section from the line function within inkscape generated HTMLs. While this was fine for the original purpose of the software, calculating how long it'll take to move from A to B, the current state requires a more modern approach.
I suggest saving points and pathes as JSON objects inside a NoSQL Database. The reason for this, is the flexibility that will allow future information being stored into points that is not necessarily shared among all of them.
Example point:
Example path: