Joerd data #22
Joerd data #22
Conversation
nilsnolde
left a comment
nilsnolde
left a comment
There was a problem hiding this comment.
A more general review:
Let's first focus on the providers. The sources package makes sense. You can generalize this more even. Each provider should have the same basic structure, i.e. there should be a Base class which each provider inherits from, you can call that Provider.py with a ProviderBase class. You can make that an abstract class, see here if you want some inspiration. And read up a little about abstract classes and methods. It's object-oriented, which Python doesn't really do, so this is more of a hack, but it's an important principle. One abstract method would be download which every subclass has to implement. Then you can define private methods for each provider class to make the download happen.
If you first do that, we can see how we implement the merging and the rest.
I think it's good that you treat SRTM and GMTED as one table in settings.yml and just pull in GMTED when the area demands it. Maybe we can call the table terrestrial instead of srtm.
| "DB:\t{db_name}\n" | ||
| "Table:\t{table_name}\n" | ||
| "Table1:\t{table_name_srtm}\n" | ||
| "Table2:\t{table_name_composite}\n" |
There was a problem hiding this comment.
What if there is no composite table?
nilsnolde
left a comment
nilsnolde
left a comment
There was a problem hiding this comment.
@isikl after struggling again to make this work in a fresh setup (my fault..), I couldn't get this to work. Mostly because the SETTINGS are used wrongly in most places, e.g.
File "/deploy/app/openelevationservice/server/db_import/models.py", line 14, in <module>
if SETTINGS['provider_parameters']['tables']['terrestrial']:
KeyError: 'tables'
If you have a look where SETTINGS is used you'll see various places with non-valid keys according to the ops_settings_sample.yml.
Can you please check and amend?
|
Should be fixed now. |
2 participants
No description provided.