Proper database schema about parkapi HOT 5 OPEN

Looks good 👍

A couple minor things:

• I'd suggest adding a table for datasources with their attribution info, source data and possibly an optional location as well? They don't necessarily have to match the pools, do they? Or will we just have pools for each datasource and additional pools with no further metadata? Would that require marking one pool as the canonical pool for a lot if one means to access the source metadata?
• Lots should have a bit more metadata like a detail URL, pricing info (just as a string), opening hours (same) and possibly more address fields like region (optional), city and country? Also I think it would make sense to add a field for additional information (possibly again using postgres' json type) to support those things we've wanted to cover in the past, but overlooked. Stuff like entrance height if something like that is available. Apps would basically just show a list of key-value pairs if anything is available. Oh and there's typos in latitude and longitude, just fyi.
• I think it would make sense to split up the timestamp for occupancies into two values, one for when the data was downloaded/fetched and one for when the data was updated (in case that information is available - which it mostly is).

from parkapi.

Or will we just have pools for each datasource and additional pools with no further metadata? Would that require marking one pool as the canonical pool for a lot if one means to access the source metadata?

A pool is a data source. Pools are not meant to be reflected in the public API (except for the current legacy one).

Lots should have a bit more metadata like a detail URL, pricing info (just as a string), opening hours (same) and possibly more address fields like region (optional), city and country? Also I think it would make sense to add a field for additional information (possibly again using postgres' json type) to support those things we've wanted to cover in the past, but overlooked.

I was thinking about that. How easy/hard is it to add additional (optional) fields later to a table? Instead of adding fields in case we might need them and adding a json field that then serves as a dump for anything we forgot I'd like to add fields as we need them and alter the database accordingly. These fields all have to be optional (otherwise old data would break).

from parkapi.

If pools are not meant to be publicly accessed, how would one see the license information?

Also I don't think it's feasible to add lot fields for every possible bit of data. There are many things to specifically add support for, but there'll always be things that are only relevant for a few lots. Having a fallback for that seems like a good solution imho.

from parkapi.

If pools are not meant to be publicly accessed, how would one see the license information?

This data would be added per lot.

from parkapi.

Ah, that makes sense 👍 But querying by pool would be possible, right?

from parkapi.