You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As discussed in #12 not all use cases require all metadata for locations and it has a high storage cost. There are some use cases though, like generating complete augmented diffs, that require all metadata. Keeping all metadata within OSMExpress as opposed to some external store is one option that reduces operational complexity at the cost of significant extra storage. It would be useful to hear what other use cases for all metadata might exist.
Summary of a brief discussion I had with @bdon regarding potential implementations:
Are we sure we need username in addition to uid? Username, as a variable length string field, would be the most painful to add.
This could be implemented as a "complete metadata" option, although in that case all other commands would need to know if the database was created in complete or slim (without location metadata) mode. In complete mode the locations table is not used and the nodes table would contain location, tags and metadata. In Slim mode the locations table is used and the nodes table only stores tags. We'd need to ensure that complete mode code does not impact performance of slim mode.
This task doesn't depend on #1, but may be simpler or use less storage space if it is addressed first.
The text was updated successfully, but these errors were encountered:
As discussed in #12 not all use cases require all metadata for locations and it has a high storage cost. There are some use cases though, like generating complete augmented diffs, that require all metadata. Keeping all metadata within OSMExpress as opposed to some external store is one option that reduces operational complexity at the cost of significant extra storage. It would be useful to hear what other use cases for all metadata might exist.
Summary of a brief discussion I had with @bdon regarding potential implementations:
Are we sure we need username in addition to uid? Username, as a variable length string field, would be the most painful to add.
This could be implemented as a "complete metadata" option, although in that case all other commands would need to know if the database was created in complete or slim (without location metadata) mode. In complete mode the locations table is not used and the nodes table would contain location, tags and metadata. In Slim mode the locations table is used and the nodes table only stores tags. We'd need to ensure that complete mode code does not impact performance of slim mode.
This task doesn't depend on #1, but may be simpler or use less storage space if it is addressed first.
The text was updated successfully, but these errors were encountered: