Hi,
I'm not a fan of the current state of public parking spaces in Zürich. Most of them are missing 🙂. During my research I found a list of all public parking spaces in Zürich. They are licensed under Creative Commons CCZero . Therefore I'm interested in importing all these parking spaces, somehow.
Here is the link to the data source https://data.stadt-zuerich.ch/dataset/geo_oeffentlich_zugaengliche_strassenp...
Some data examples as GeoJSON:
,{"geometry":{"coordinates":[8.499601,47.37671],"type":"Point"},"id":"view_pp_ogd.43991","properties":{"art":"Blaue Zone","gebuehrenpflichtig":"nicht gebührenpflichtig","id1":206191.0,"objectid":43991.0,"parkdauer":60},"type":"Feature"} ,{"geometry":{"coordinates":[8.535288,47.373082],"type":"Point"},"id":"view_pp_ogd.43912","properties":{"art":"Zeitweise Taxi, zeitweise Güterumschlag","gebuehrenpflichtig":"nicht gebührenpflichtig","id1":190586.0,"objectid":43912.0,"parkdauer":null},"type":"Feature"} ,{"geometry":{"coordinates":[8.539875,47.377323],"type":"Point"},"id":"view_pp_ogd.47834","properties":{"art":"Nur für Taxi","gebuehrenpflichtig":"nicht gebührenpflichtig","id1":10275.0,"objectid":47834.0,"parkdauer":null},"type":"Feature"} ,{"geometry":{"coordinates":[8.537184,47.366241],"type":"Point"},"id":"view_pp_ogd.43915","properties":{"art":"Weiss markiert","gebuehrenpflichtig":"gebührenpflichtig","id1":185332.0,"objectid":43915.0,"parkdauer":120},"type":"Feature"} ,{"geometry":{"coordinates":[8.542311,47.381361],"type":"Point"},"id":"view_pp_ogd.47838","properties":{"art":"Nur mit Geh-Behindertenausweis","gebuehrenpflichtig":"nicht gebührenpflichtig","id1":10279.0,"objectid":47838.0,"parkdauer":null},"type":"Feature"}
My background: A programer who recently got started in OSM.
Now, there is a large amount of work to be done, things to be considered, issues to be solved and learnings to be made. Here are some points that I am thinking about:
1. There are nearly 49'000 parking spaces in this dataset. The dataset is from 2019, therefore it will contain outdated information. 2. The parking spaces are marked as points. I can see that parking spaces can be added as points and as areas. Personally I would prefer areas. Do we have any preference here? I think the map could suffer a lot if we suddenly have that many points in the map. * https://photos.app.goo.gl/L3ydi3a5gWiNbTEG9 *
1. What happens to continous parking spaces along the street? Again, I think it would be better to have them as areas. But in this example, there is an outgoing path in between them. * https://photos.app.goo.gl/oDi1GR7cJyiMDTkP7
1. Zürich has the concept of blaue Zone. Locals can park there with a residence parking card for an unlimited time. The card is bound to the zip code of the home address. So as a person living in 8055, I can park in all blaue Zone parking spaces in 8055. All blaueZone parking spaces in 8055 are marked as 8055 with a street sign. I am not aware of any edge cases. Therefore I really would like to add some label to mark these as blaueZone:8055 or similar. This should be easily possible using some zip code map. 2. Most/(all?) blaue Zone parking spaces are outdoor, therefore I would prefer to start with them. 3. I was not able to find enough information about some kind of half manual import pipeline. I would like to do it somehow like this: * I want to take the raw data * Extend it with additional information like the zip code. * Convert it into a format that can be read by some kind of OSM client. (Which format to use? I would have guessed OsmChangehttps://wiki.openstreetmap.org/wiki/OsmChange) * Split the dataset into usefull batches and process each of them like this: * Do some kind of automated conflict resolution. There is an already existing parking space? Mark it and put the data point a separate list. * Maybe let me preview each change and press "yes" or "later". * Verify each completely missing point with a satellite image, fortunately we have a high enough resolution to see such lines. Again, edge cases should be marked and put into a separate list. * https://photos.app.goo.gl/PVWrxQnmA76mg8Jp7 * * Maybe, step c should provide a standardized rectangle area instead of a point. For example 2x4 Meter. Then I could rotate the parking space in the client and maybe connect it with endpoints from other parking spaces. * Export these small batch of changes from this unknown OSM client and upload it. * Proceed with the next batch at step d. 4. I mentioned above some separate lists of edge cases. How would I continue with these? * Delete the current data and replace it? I think it would be sad if I remove areas and replace them with points. * I would need some way to query OSM for each datapoint. * It would be nice to add labels like parkdauer and "art" to existing parking spaces. Again, I would need to query OSM for each parking point, see if there is a parking area underneath it, check it's labels and build an OsmChange which contains the additon of these labels. 5. I discovered JOSM. Do you think it is the "right" client to do this? 6. Personally I do like the iD client. Sadly I can't find a way to bring a set of OsmChange's into iD and then using it's awesome conflict resolution tool. Any idea? 7. It will be many days of work to verify all changes. I would prefer to use a really really fast client which let's me fly through each change with some shortcuts.
So, that was a lot. What are your thoughts and opinions? How would you approach this problem?
Greetings Fabian
Hi Fabian
Make sure to take a look at my other two threads as well (especially the part about how to map "Blaue Zonen"):
- http://lists.openstreetmap.ch/pipermail/talk-ch/2022-June/011545.html - http://lists.openstreetmap.ch/pipermail/talk-ch/2022-June/011549.html
Regarding your suggestion: I've never done an import myself, but I know that OSM imports are complex with a lot of process involved. Be ready for many critical questions (including licensing questions). I think your questions are important to be discussed and decided before mapping starts, but it might actually be easier if you'd visualize the dataset somehow (as a reference where these parking spaces are located), and then people work on it "manually" (using satellite imagery as reference).
To simplify the process you could write JOSM Presets for the different types of parking spaces. Example from an earlier PotmCH: https://github.com/dbrgn/josm-preset-potmch With this, it would be very quick to map parking zones, probably quicker than by importing followed by checking.
Danilo
Hi Fabian
- The parking spaces are marked as points. I can see that parking spaces can be added as points and as areas. Personally I would prefer areas. Do we have any preference here? I think the map could suffer a lot if we suddenly have that many points in the map.
I would prefer areas as well.
- What happens to continous parking spaces along the street? Again, I think it would be better to have them as areas. But in this example, there is an outgoing path in between them.
I would map all contiguous parking lots as one area. Example:
https://i.imgur.com/sVNmdyK.png
Here you can see three parking zones, I would map them as three separate areas.
- Zürich has the concept of blaue Zone. Locals can park there with a residence parking card for an unlimited time. The card is bound to the zip code of the home address. So as a person living in 8055, I can park in all blaue Zone parking spaces in 8055. All blaueZone parking spaces in 8055 are marked as 8055 with a street sign. I am not aware of any edge cases. Therefore I really would like to add some label to mark these as blaueZone:8055 or similar. This should be easily possible using some zip code map.
Could "ref" be used? https://wiki.openstreetmap.org/wiki/Key:ref At the paid parking areas, I used the code written on the parking meter (which is also entered into apps like ParkingPay). Since the blue zones don't have such a code, the ZIP-Code could be used instead.
- Most/(all?) blaue Zone parking spaces are outdoor, therefore I would prefer to start with them.
These can be cross-checked on satellite imagery, so that's a good ida.
- Maybe, step c should provide a standardized rectangle area instead of a point. For example 2x4 Meter. Then I could rotate the parking space in the client and maybe connect it with endpoints from other parking spaces.
Are the surface areas standardized? If not, I would use satellite imagery as reference.
- Delete the current data and replace it? I think it would be sad if I remove areas and replace them with points.
Current data should not be deleted and re-created since you'll lose history.
- I discovered JOSM. Do you think it is the "right" client to do this?
JOSM is a great client, once you learn to use it. There are a lot of useful plugins. (I often use the "buildings_tools" Plugin that is used for drawing rectangles with the "b" key, and then delete the "building=yes" tag from the created rectangular area.)
Regarding the import itself, I already commented on that in my previous e-mail. However, I'm no authority here, so let's wait for replies from the more seasoned community members first :)
Cheers Danilo
On Sun, Jun 26, 2022 at 5:32 PM Danilo mail@dbrgn.ch wrote:
Hi Fabian
- The parking spaces are marked as points. I can see that parking
spaces can be added as points and as areas. Personally I would prefer areas. Do we have any preference here? I think the map could suffer a lot if we suddenly have that many points in the map.
I would prefer areas as well.
- What happens to continous parking spaces along the street? Again, I
think it would be better to have them as areas. But in this example, there is an outgoing path in between them.
I would map all contiguous parking lots as one area. Example:
https://i.imgur.com/sVNmdyK.png
Here you can see three parking zones, I would map them as three separate areas.
- Zürich has the concept of blaue Zone. Locals can park there with a
residence parking card for an unlimited time. The card is bound to the zip code of the home address. So as a person living in 8055, I can park in all blaue Zone parking spaces in 8055. All blaueZone parking spaces in 8055 are marked as 8055 with a street sign. I am not aware of any edge cases. Therefore I really would like to add some label to mark these as blaueZone:8055 or similar. This should be easily possible using some zip code map.
Could "ref" be used? https://wiki.openstreetmap.org/wiki/Key:ref At the paid parking areas, I used the code written on the parking meter (which is also entered into apps like ParkingPay). Since the blue zones don't have such a code, the ZIP-Code could be used instead.
Note that this is not an exact correspondence: areas close to PLZ borders have parking spots that belong to both blue zones. E.g. https://www.google.com/maps/@47.3818723,8.4984934,3a,15y,0.78h,93.16t/data=!...
- Most/(all?) blaue Zone parking spaces are outdoor, therefore I would
prefer to start with them.
These can be cross-checked on satellite imagery, so that's a good ida.
- Maybe, step c should provide a standardized rectangle area instead
of a point. For example 2x4 Meter. Then I could rotate the parking space in the client and maybe connect it with endpoints from other parking spaces.
Are the surface areas standardized? If not, I would use satellite imagery as reference.
- Delete the current data and replace it? I think it would be sad if
I remove areas and replace them with points.
Current data should not be deleted and re-created since you'll lose history.
- I discovered JOSM. Do you think it is the "right" client to do this?
JOSM is a great client, once you learn to use it. There are a lot of useful plugins. (I often use the "buildings_tools" Plugin that is used for drawing rectangles with the "b" key, and then delete the "building=yes" tag from the created rectangular area.)
Regarding the import itself, I already commented on that in my previous e-mail. However, I'm no authority here, so let's wait for replies from the more seasoned community members first :)
Cheers Danilo _______________________________________________ talk-ch mailing list talk-ch@openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch
-
Danilo -
Fabian Stillhart -
Robert Obryk