@jklmnn suggested that we remove city IDs alltogether and reference them by their real name only. Not quite sure how we'd deal with duplicates, but due to the current metadata format we'd run into this problem anyways. But otherwise it would make things much easier.

Any suggestions?

http://www.pls-luzern.ch/de/

To be notified if the format of a page changes as soon as possible. A big plus would be slack integration 🎉

It'd also be nice to periodically automatically update the test fixtures in this repo as well.

From the README:

"forecast":"true|false",

JSON sports native bool support. Use it!

Specifically for Lübeck, where the total would return 0 for almost any lot at night...

https://www.rosenheim.de/stadt-buerger/verkehr/parken.html

https://www.bregenz.gv.at/sicherheit-verkehr/verkehr-und-parken/parkleitsystem.html

The example script should be runable by the server. Not that some meaningful data come out of it, but that the server not crashes like now but came up with an json error. By the way, the example should contains all important objects and vars (maybe with blind or no data, but syntactic right)

Übersicht: http://www.bonn.de/umwelt_gesundheit_planen_bauen_wohnen/verkehrs_infos/14767/index.html?lang=de

Parkplätze in Bonn:
http://www.bcp-bonn.de/bcp/index.php?id=87
Keine Ahnung wie das jemals klappen soll >.<

Park and Ride:
http://www.swb-busundbahn.de/bus-und-bahn/service/park-ride.html
Hier ist das Format allerdings ganz ok

https://twitter.com/tursics/status/611411296664354816

Opening the database connection on every request is probably a bit slow.

http://www.koeln.de/apps/parken/

https://twitter.com/tursics/status/611411296664354816

the vars
data_url = ""
data_source = ""
city_name = ""
file_name = ""
detail_url = ""
are a little bit redundant. Please make more clear by name whats the use for every single var or set an comment

Otherwise the time last downloaded and time last updated can differ by several hours, which is kinda weird...

http://www.konstanz.de/tourismus/01759/01765/index.html

Can't assign @lucaswo, but he's on it :D

Autodetect available cities instead of writing them into an array.

http://www.ingolstadt.mobi/parkplatzauskunft.cfm

http://parken.heidelberg.de

http://www5.stadt-muenster.de/parkhaeuser/

Kontakt mit OpenDataMoers? Generell auch für alle anderen Städte empfehlenswert...

https://twitter.com/tursics/status/611411296664354816

http://www.dresden.de/freie-parkplaetze/

http://www.kwl-luebeck.de/parken/aktuelle-parkplatzbelegung/

http://vmz.karlsruhe.de/entry-tba_Parkleitsystem/

Data is displayed when a lot is selected

http://geoweb1.digistadtdo.de/OWSServiceProxy/client/parken.jsp

Opened this issue to collect some stuff about the database.

I'm planning to write a database connector that connects to a PostgreSQL db. In this it'll throw data with id, timestamp_updated, timestamp_downloaded, city and data attributes. data contains a JSON dump of the data that the scraper acquires (Postgres is pretty damn nice!).

The scraper is then run periodically and talks to the db connector. Before the db connector saves stuff in the database, it first verifies if it looks ok (#6). If it doesn't, it'd probably be best to notify us about it. A slack bot would be pretty damn sweet!

in sample_city.py should write down, how to handle missing data fields.
should comented the lines out, delete it or should the data set to false, null, ..?

http://www.oldenburg.de/microsites/verkehr/parken/parkplaetzeparkleitsystem/parkplaetze.html

Transform to current API as described at http://jkliemann.de/parkendd/dev.html

Specifically:

• Specify data as generically as possible in the city files (only config files would be too perfect, but probably not possible), so that they can easily be added without writing a python file that handles all the scraping and returns a finished dict
• Write a separate scraper that handles all the scraping and getting data in the correct format for all cities, so it won't be possible to have surprisingly differing output
• Dynamically import city files from the scraper
• Handle a database that scraper and server can talk to

For the time being the server will probably talk to the scraper directly, but the scraper should be able to run on it's own soon and store stuff into a database (I'm really liking the idea of just throwing the json into a mongodb instance - clear out #4 first though!), which the server then queries for current data. That way the scraper can run periodically (as easily as via cron) and the server only touches the previously saved data (usually the most current data) without them getting in each others way.

https://www.pythonanywhere.com/forums/topic/694/

See https://gist.github.com/ibeex/3257877 for more info on how to implement this.

Instead of saving the geolocations inside of scraping-city.py should they stored in a seperate file to enable easy updating besides the automatic update while scraping a new parking-spot.

the new file should lay besides the scrape-city.py in /cities and should have the suffix .geo.
Like this:
..cities/
dresden.py
dresden.geo
Luebeck.py
Luebeck.geo

and the content should be like this:
{
"Altmarkt": { "lat": 51.05031, "lon": 13.73754 },
"An der Frauenkirche": { "lat": 51.05165, "lon": 13.7439}
}

For later improvements we can change to geojson so github can render this file by it self on a map:
https://help.github.com/articles/mapping-geojson-files-on-github/

Currently existent, but incomplete.

If anyone finds a way to gather the coordinates from here (there's some stuff happening in kwl_maps.js and elsewhere there, but I can't find the data), please add it to Luebeck.geojson.
Or from anywhere else of course...

http://verkehrslage.stuttgart.de/ivl/app.html?map=ilvLos&layers=Raster,LOS,&overlay=default&extents=3512167,5403934,3514138,5405312

Include @balzer82's forecast data. Maybe a route something like /city/forecast/daterange? CSV would still probably be the best option for this I guess.

{
  "address": "Ferdinandplatz",
  "coords": {
    "lat": 51.04645,
    "lng": 13.73988
  },
  "forecast": false,
  "free": 8259,
  "id": "dresdenferdinandplatz",
  "lot_type": "Parkplatz",
  "name": "Ferdinandplatz",
  "region": "Prager Strasse",
  "state": "open",
  "total": 140
}

Just got this in Dresden... 8259 free spaces would be nice, but probably aren't correct.

http://www.freiburg.de/pb/,Lde/231355.html

Shouldn't we just go on with Python 3 and stay clean there?

https://www.stadt-zuerich.ch/portal/de/index/ogd/daten/parkleitsystem.html#description1

http://www.pls-sg.ch/parkraeume/

It might not be a bad idea to check the imprints of all sites we're scraping here for any clauses that might prohibit such a thing and if so contact the relevant departments if it's all good.

It might also be a good idea to include a link to the original page, a name or a copyright notice (or all of the above?) in the JSON output.

http://www.parkleitsystem-basel.ch/stadtplan.php

@lucaswo currently has some R code to calculate this. It should be incorporated... somehow?

Data for Marktstätte and Döbele is not being found - why?