Community Portal

Make an overview of the correct NUTS2, 3 and country reference spaces for the CL cities

Created on Tuesday 13 April 2021, 07:39

Back to task list
  • ID
  • Project
  • Status
  • Priority
  • Type
    General administrative work
  • Assigned to
    Carolin Bellstedt
  • Subscribers
    Carolin Bellstedt
    Paul Hoekman

You are not logged in

Log In Register

Please join us and let's build things, together!


In order for the cities to link their data to the correct reference spaces, we need to share an overview of their respective NUTS2, 3 and country reference space names, as we have them in our system. This is needed, since the exact spelling is important for the system to make that connection.

For now, a simple table suffices, but eventually this could be nicely integrated on its own page on the Data Hub.

Discussion and updates

New task was created

Task was assigned to Carolin Bellstedt

Status change: Open → In Progress

Uij, I thought this was a quick and easy task to do, but not so fast...In a new spreadsheet, I'm building on an overview that we made previously and also included in D4.3, but there seem to be some mistakes, probably just minor, but need to discuss with Aris.

The bigger issue is for the instances where we have several reference spaces with the exact same name, e.g. Andalucía exists 3 times (2 in Spain, 1 neighbourhood in Medellín) and Sevilla 4 times. I'm not sure what kind of problems we can get from that if the cities will try to link flow data to it and if we possibly need to give the cities the ref spaces numbers instead? Paul, I will need your insights here please.

There will be no problem Carolin when the name is duplicated. Remember that when you process flows, the system will detect the name used, and show you which source document(s) contain this name. The user must then select the right document to use. So if a user sees Andalucía referenced in a document about Medellín, they will simply not pick that one, for instance. Does that make sense?

Aaaah! I'm not sure to remember, but maybe I should process some more flow spreadsheets to jog my memory. It does make sense though.
What happens if there are two or more reference spaces used? For example, I upload population data on both Sevilla and Andalucia in one spreadsheet. Will the system ask me to select the source document for each of the ref spaces, assuming their source documents aren't the same?

In the meantime, I finished the overview and checked if all ref spaces exist: We are all good for NUTS2 and 3. NUTS1 hasn't been added yet and we do have the LAU files, but they haven't been processed yet (there is a task for it however!).

Guus helped me make a cool new overview page for it here: 🙌 It can be found in the menu Cities > Overview.

Status change: In Progress → Completed

Nice with that overview page!

In terms of different reference spaces being covered in a single dataset: this would be a problem if they are not available in an original source document that lists them both! I have thought about that and there is no easy way out. However, I would think that there generally are sources that will contain both reference spaces because there will be a reason why they will be reported on simultaneously. Let's see how it goes in practice and we can take it from there.

Thanks. Pretty neat, eh?

That is a good point that there will be reason to report them at once. So if someone wanted to add all the data from the megacities publication on the different cities, they wouldn't be able to do it in one go, but instead it would need to be chopped up per city. A very rare case most likely. Let's see indeed.

Yeah megacities data could be a tricky one. But I think there is an easy fix. For this kinda cases, I can set up a system where instead of reference space name, the reference space ID is used. That way it's always unique and I can just make some small tweaks so that the system looks for the ID instead of the name.

I had thought about too that as an option before you reminded me of the path of selecting the source doc, which is more user-friendly. Good to know you have this in mind too for this special cases.