Hey,

Frie suggested we could write for the CorrelAid blog, if there are any learnings we'd like to share with the community :)

Especially for our project, that involved a lot of research, this could be interesting.

So, if there is something you think would be interesting to share on the blog, and/or if you'd like to give writing a blog article a try, please comment here!
This is still in brainstorming phase, feel free to share any thoughts, and then we'll see if and how we implement this. And this could be a great chance also for anyone who has never written a blog article before and would like to give it a try (you'll get support of course). You can also just share topic ideas, maybe someone else would like to write and is looking for ideas :)

Possible topics (non exhaustive):

• learnings from the systematic review -- interesting articles, approaches?
• something on the project context (approaching the bike parking topic in a big city like paris)
• something more specific on one of our deliverables
• ...

We should host the app somewhere. Either in AWS (@akashrajkn ) or GCP.

GCP seems to have a free tier which includes App Engine (which would run the app) and GCS/BigQuery (which would store the data) could probably handle our app quite well: https://cloud.google.com/free/docs/free-cloud-features#free-tier

I'm not familiar with AWS. I see it also has a free tier but i am not sure which services we need. I guess S3 for data storage, but which service would run the app?

in google docs/sheets? ideas welcome :)

Melanie asked if the maps could be updated as new data is available. I guess this would be possible to achieve by scheduling the data pipelines to connect to the various data APIs and recomputing the feature table.

Do we wanna do that? Looks like a bit of work, but it could be technically interesting. It would be a lot of playing around with whatever hosting environment we choose and also developing the connections to the raw data APIs.

• Long term bicycle planning Amsterdam: https://bikecity.amsterdam.nl/en/inspiration/long-term-bicycle-plan/

  • Interim evaluation (link) in Dutch
  • Link to pdf. Relevant section - Analysis in Chapter 2: Easy parking.

• Data - bike sheds

Benoit suggested we normalize metrics by area, since the area of each IRIS varies considerably.

What do you think?

@dietrichsimon I remember that you looked into the network of bike lanes already

We can estimate the network centrality here
https://networkx.org/documentation/

Hi, I paste this comment from slack, as it is easier to discuss open issues here:)

I think design-wise the app looks great now!
(the slightly moving map because of the labels is not an urgent problem i'd say) :stern2:

In terms of description/intro and title I'd say I can do that in the end once the functionality is finalized.

with regards to the functionality I see a few issues that impact the usability and that we should try to solve before the presentation:

• the parking spots metric should be moved to a place apart from the other metrics (maybe in the footer, above the normalize slider?)
• the normalize functionality should be disabled for parking spots
• with regards to bucketing - i feel that now that the color scheme is different it looks already less confusing. maybe there is another way of cutting off outliers, too? i would say something like this would be nice to have, but I don't know how quick this would be to implement, that's maybe not priority 1
• I think it would be useful to have the tooltips display not only the iris and selected metric, but also the number of parking spots on default, and when normalized, also the absolute number of the non-normalized metric
• There is a normalization issue when the number of parking spots is 0. e.g. in iris saint germain auxerrois 4 (see image) the number of shops is 58, parking spots 0, and normalized it is 58
• nice to have: a way to add and weigh metrics

The IRIS level model will rely on an aggregation of (potential) determinants of demand for bike parking. One big question is how the different variables should be weighted. The bike flow model could provide useful input as it estimates trips for each flow layer / activity type.

During the exploration team meeting we discussed where we could store data.
@dietrichsimon already has some preliminary exploration files that would be good to share with others but we need a solution to store the data that these files use.

One option is to use git-lfs (@operte and @Liyubov have experience with it).
I'll do a first experiment with a single dataset. If it works out fine we can then write up some instructions on how to use it (if needed) and push Simon's files into the repo.

Going through the citizen initiatives Mélanie sent and summarize them in a document on the google drive.

The citizen intiatives Mélanie sent are:

• Baromètre des villes cyclables de la Fédération française des usagers de la bicyclette (FUB)
• https://velib.philibert.info/15DerniersJours.php (usages Vélib)
• https://compteurs.parisenselle.fr/ (valorisation des données de comptage de la Ville de Paris)
• Données sur les projets d’aménagement (avec les créations de surfaces d’habitation, bureaux, activité…) : Projets d'aménagement - Institut Paris Region

As we start writing code it's important to use the same development environments, e.g. by using a package requirements manager.

For python we could just simply have a requirements.txt or something similar that would be easily installable with pip install -r requirements.txt.

@akashrajkn proposed doing this with conda's environment.yml, which would also support R packages.

Hey,

so in yesterday's meeting we talked about in which form we could create a deliverable from the parking demand index for the city.

Probably a small interactive web-app would be nice, if there are interested/experienced team members, and if it doesn't take too much time. Otherwise we could of course also do notebooks as deliverable.

We talked about implementing it in shiny (R-based, which @dietrichsimon has experience in), or with FastAPI (python based, @akashrajkn has experience).

Anyone who's interested, feel free to join the discussion :)

Hey, in one of our last meetings @ryanrakusin introduced a recently published article about a new method to assess bike infrastructure quality using open data + Paris as a case study. I think it would be great to summarize insights from this paper, and to see if and in which ways this could be interesting for us (especially because they use open, spatial data).

Here is the link:
Where to improve cycling infrastructure? Assessing bicycle suitability and bikeability with open data in the city of Paris.

I assigned @ryanrakusin because he introduced the paper, but of course everyone interested can participate:)

I have read the article and have some thoughts about it (e.g. the introduction of 30km/h limits has big impact on the results of the model. They still use data with the 50km limit). Will try to take notes in the next days. Would be interesting to discuss it further!

If there is something you think we should share with City of Paris during our next meeting, please add it to this issue :)

Some points to start with:

• Idea about collecting citizen data, possibly using infrastructure of existing app "dans ma rue" (Issue)
• WIP of our notebooks / analyses
• Interesting insights from research articles / city planning (e.g. best practices from Amsterdam, bikeability analysis for Paris, comparative table / summary of variables used by others)

This is rather for the final stage of the project (but also a good practice during development) -- documenting the code, so that other people understand how to use it :)

Could also be a good issue for beginners (for example, identify if instructions are missing or unclear in the READMEs).

I discovered https://direkt.bahn.guru/ today, which is an interactive map that shows which direct train connections exist from many train stations in Europe.

I thought this could be an interesting way to visualize which ways people take on vélibs (as we don't have start - end data from other bikes). I.e. for each start station, which end stations are targeted? And then instead of color coding the duration of the ride, like in bahn.guru, we could color code how many rides to respective end stations are taken. This could visualize common ride patterns, and maybe highlight popular destination areas.

This is another map with a similar approach: https://chronotrains-eu.vercel.app/

Might be a bit overkill, maybe just visualizing the most important start and destination stations is enough..?

What do you think?

Streaming data from single bicycles and their routes at certain days/time slots may help us to estimate the demand for bicycle parking
Assumption: high density of velib bikes implies that there would also be more "own" bikes

I think directly asking cyclists to report frustrating bike parking situations could be a promising direction to follow.

There is an app called "Dans Ma Rue" ("In my street"), developed by City of Paris, where people can report anomalies with a geotag, a category (like "trash on the street" etc), photo, and description.

I think something similar (or even exactly that, but with new categories for cycling issues) could work well for our purpose.

We could ask Mélanie about this idea, to see if something like this already exists, or if we could get in touch with the developers of Dans Ma Rue etc.

If anyone else is interested in this direction, feel free to comment!

We can't use the gdrive DVC remote anymore.

When doing dvc pull we get:

ERROR: unexpected error - <HttpError 403 when requesting https://www.googleapis.com/drive/v2/files?q=%28%2713kP6MXL5QBkYS8-aeuJ860kZf4cCS4NF%27+in+parents+or+%271wKK0w2ajY7Ik-5wvEWy5rGJXnoYMNjFz%27+in+parents%29+and+trashed%3Dfalse&maxResults=1000&corpora=drive&driveId=0APzUn7ywXlbhUk9PVA&supportsAllDrives=true&includeItemsFromAllDrives=true&alt=json returned "The attempted action requires shared drive membership.". Details: "[{'domain': 'global', 'reason': 'teamDriveMembershipRequired', 'message': 'The attempted action requires shared drive membership.'}]">

Following that link we get:

{
 "error": {
  "errors": [
   {
    "domain": "usageLimits",
    "reason": "dailyLimitExceededUnreg",
    "message": "Daily Limit for Unauthenticated Use Exceeded. Continued use requires signup.",
    "extendedHelp": "https://code.google.com/apis/console"
   }
  ],
  "code": 403,
  "message": "Daily Limit for Unauthenticated Use Exceeded. Continued use requires signup."
 }
}

This seems to be some kind of usage limit of google drive.
We can either ask Frie to check if these limitations can be increased, or move to NextCloud.

I'll pick this up after the Paris meeting.

The document with best practices around the globe is located here
https://docs.google.com/document/d/1cGJTxaCnkIz0C-YS3xAe7ZfHNFMP33DFSpkFMoxQ3QQ/edit?usp=sharing

Hey,

CorrelAid has a format called Open Online Data Meetup, where we are invited to present aspects of our project, if we'd like to share something.

What is the Open Online Data Meetup?

• an online-based meetup series which provides space to share interesting and entertaining stories from the field of data science with other people from the community
• open format: from short lightning talks to longer workshops, from technical over use-case oriented topics
• main target group are the correlaid netword and other volunteers, but can be open for NPOs etc

See their youtube channel for past events (I just saw that there is a recording of a meetup on mobility where @mpadge presented :))

So, if you think this might be interesting, if you have any ideas for content, or would like to contribute in any way, please comment here! This could be a great opportunity if you're interested in practicing how to prepare and present data science-related content to a target audience (and of course anyone will get support, especially if this is new for you).