Add additional fields for parking lots

[leonardehrenfried]

In #175 we discussed adding more fields to the parking lot schema.

This is my first attempt to do this but I acknowledge that this doesn't completely match with the list @kiliankoe provided.

This PR is just the first attempt and I'm happy to rework it as needed. Lets discuss!

[leonardehrenfried]

One obvious problem is that the lot_type would have to be changed for all of the current parsers and perhaps the clients use the current values.

[jklmnn]

I like the new lot_type but maybe we can change it to lot_type_v2 or something similar since I'd like to keep backwards compatibility, especially since this API will definitely have a successor (whenever this will happen).

[leonardehrenfried]

Would it not make sense to have a separate endpoint for v2 of the API? This would of course mean a bit of refactoring.

[leonardehrenfried]

This would however allow us to change the times to use proper ISO 8601 with an offset (2020-07-08T15:21:08+02:00) rather than the current timezoneless type which implies UTC.

[jklmnn]

Would it not make sense to have a separate endpoint for v2 of the API? This would of course mean a bit of refactoring.

Yes this makes sense and there's already #140 to address this issue.

The documentation you want to change however addresses the current version (but it isn't up to date tbh). I don't want to mix the outdated version 1 documentation with features for a (yet undefined) version 2 API. Calling it 1.1 would also imply backwards compatibility.

[kiliankoe]

I am very much against adding something like lot_type_v2 and I also don't see any merit in providing backwards compatibility. The old format is not well designed and it makes much more sense to apply any lessons learned and add/rename any fields that make sense for a new spec.

Let's create a new spec instead of modifying the old (and as @jklmnn stated outdated) one. Maybe even move that into its own repo to version it apart from the crawler/API?

[hbruch]

I agree that we should not add a lot_type_v2. On the other hand, we'd like to add the new attributes url, opening_hours, fee_hours rather soon, while a new v2 api would require a bit of thinking, discussion, and work.

I'd suggest to remove lot_type from this PR and add the backward compatible new attributes url, opening_hours, fee_hours. WDYT?

[jklmnn]

I'd suggest to remove lot_type from this PR and add the backward compatible new attributes url, opening_hours, fee_hours. WDYT?

This would work for me.

[leonardehrenfried]

I have amended this PR to remove the field lot_type from the schema. It will remain unspecified.

However I'm seeing a problem on Travis, which appears to be happening when the Python requirements are installed: https://travis-ci.com/github/mfdz/ParkAPI/jobs/366048314

Do you have an idea what the issue is?

[jklmnn]

Do you have an idea what the issue is?

This is going to be fixed in #217. Please rebase your branch onto the new master once it is merged.

[leonardehrenfried]

I've rebased and CI is green. Thanks!

[kiliankoe]

LGTM 👍