-
Notifications
You must be signed in to change notification settings - Fork 11
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
GeoJSON file or DB #26
Comments
Mobile app don't need geojson, it overhead requirements. We need very small part of information. We can generate this format dynamicly, and provide it to lib. But it's incorrect to think that we need this file and should keep it on client and server parts. |
@Vegasq agree with you. Lets implement your step-by-step plan In this case, we need two more models: class Layer :
class Polygon:
All aditional info would be stored in Organization model Also leaflet.js provides functionality to draw polygons, this could be included to django admin using django-leaflet package - https://github.com/makinacorpus/django-leaflet#leaflet-map-forms-widgets GeoJSON could be used as fixture, as alternative way to get some polygons into DB |
At all, transition from upper Layer to lower could be done in such way: If it is right way, Layers have to be ordered hierarchically. By using FK to self, maybe |
Lets postpone it. If we want to use their native tools, we will have two new binary requirements.
I think we can handle it, but in different patchset, and after discrussion about new requirements. |
- Keep working on autogestion#26
Looks like we'll stay with GeoJSON file for a while, and it have to contain: at top-level:
at polygon-level:
This values would be parsed by initiate_db comand ( |
- Keep working on autogestion#26
- Keep working on autogestion#26
- Keep working on autogestion#26
- Keep working on autogestion#26
All data is stored in Postgres |
A summary of the previous series:
There was an idea that service will consists of 2 parts - mobile app that don't need live internet connection and web-platform. First just gets claims, second shows them. GeoJSON was conceived as mediator beetwen them, it would contain a polygon id, by which web-platform would recognize which polygon was claimed. We could update GeoJSON, put it at server and in mobile app update and they would stay synced.
Main idea was to store in GeoJSON information which must be same in mobile app and web-platform. All ather atributes had to be stored in server db
If there are real benefits of kicking GeoJSON off the server, we have to know how common data would be stored in mobile app and how they would stay synchronized with server. We could not change something on server before it comes to mobile app which is offline
Or we should change the whole vision of service
The text was updated successfully, but these errors were encountered: