Proposed import of the indoor data offered for OSM by the Technical University of Munich (TUM)

Communities Deutschland (Germany)
, ,
1

Import Title

Hello fellow contributors, I am proposing to import parts of the indoor data offered for OSM by the Technical University of Munich (TUM).

Documentation

This is the wiki page for my import:
https://wiki.openstreetmap.org/wiki/Import/Indoor_Navigatum
This is the source dataset’s website:

Here is how this looks in the database, as discussed with all the local contributors and the local group:

License

This data is ODbL-Licenced.
Due to containing too many links for my forum account, the permission is in the wiki above.

Abstract

  • We plan to import basic indoor data for our university
  • => data which is non-critical for the university (room-ref, room/door/elevator/stair-geometries). Further restrictions on goals/non-goals are in the import proposal
  • We (Me and my co author) created the dataset, or more precisely: Will create it through a lot of sweat and tears
  • Size: roughly 400 building-parts in the greater Munich area, mostly Campus Garching-Forschungszentrum, Campus-Munich City Center, Campus-Ottobrunn and satellite campuses like TUMs 13 buildings(/-parts) on the Campus Straubing. (links in the wiki, cannot post due to forum policy)
  • data is imported into OSM via IFC to a custom python script to JOSM with a lot of manual work via in-person verification & clean-up & collation & … afterwards

More can be read in the import proposal
https://wiki.openstreetmap.org/wiki/Import/Indoor_Navigatum

PS:
This is my first proposal, and thus quite likely that we made a rookie mistake in this plan. I would love to hear feedback for any mistakes that I made

7 Likes
2

Welcome! :slight_smile:
I have no specific feedback to offer except encouragement - this seems like a really cool project and I wish you the best of luck. :heart:

2 Likes
3

Thank you for working on this, as someone involved with indoor map rendering and indoor routing getting more public buildings mapped in high quality is very much appreciated!

Slightly unfortunate timing as just two days ago we had the quarterly OSM Indoor Meetup, people there would be very interested in learning about your import toolchain as well as how you managed to actually get access to IFC data, that’s a rare feat. The next meeting is planned for 2025-06-04 18:00 CEST on BigBlueButton (OSM Indoor Meeting), would be great to have you there as well!

1 Like
4

Thanks, did not know that said meetup existed. Will try to be there

If interesting, I will be at Fossgis in a few weeks, as I heard there is an indoor meetup ^^

“Real” Indoor routing is on my roadmap for nav.tum.de, but only for next semester.

About how
I think the key ingredient is NOT wanting to import more than the basics and having a
direct benefit (routing, simpler twoway feedback, data from other orgs, UPDATED MAPS) from importing.

5

Ah, perfect, the “offline” version of the Indoor Meetup at the FOSSGIS Konferenz of course also works :slight_smile:

I agree on the approach, the hard part for indoor mapping is getting the geometry and placement of bigger structures like rooms/walls/stairs in, that’s where importing brings the most benefit. Adding smaller details and room properties etc manually is much easier then.

1 Like
6

You might want to read ODbL compatibility with itself before importing data licensed under ODbL. :wink:

7

The data is licensed under OSM’s own licence to avoid any headaches.
I don’t really see how OSM could be incompatible with itself. Allow me to explain why:

The versioning part of said post is not applicable given the waiver signed (“the ODbL” as used by OSM as defined by the link to Open Database License - OpenStreetMap Wiki)

Even if OSMs ODbL were to be incompatible with OSMs ODbL, this import would be okay as the following paragraph from the import docs is waived

consider contacting rights holder(s) for explicit permission to integrate data into OSM

Sometimes, getting permission to use data, even if the existing license might seem prohibitive, is as simple as asking the appropriate authority if they are willing to comply with the terms of the OpenStreetMap Open Database License.

The following paragraph from the getting permission wiki page exists and is the first => therefore most recommended thing => therefore the thing we did.
Our permission slip is in german and linked in Import/Indoor Navigatum - OpenStreetMap Wiki.

At the most simple, I would seek a statement like this:
“The #ORGANISATION# has no objections to geodata derived in part from #DATASET# being incorporated into the OpenStreetMap project geodata database and released under a free and open license (in footnote: ODbL)”

But let’s imagine for that OSM (source) were to be incompatible with OSM (target):

  • Reverting edits wouldn’t be okay because that would mean taking data from OSM and putting it back into OSM.
  • Uploading GPS tracks wouldn’t be okay either, since that’s also taking OSM data and adding it back.
  • editing likely similarly (depending on the edit, f. ex. wrongly formatted opening times)

I think it’s safe to assume OSM is compatible with itself :smiley:

8

Ah, so I found an even better source than wiki page in the import guidelines.

OSMs legal FAQ states here Licence/Licence and Legal FAQ - OpenStreetMap Foundation

Can I import data that I own the Intellectual Property in?

Yes. However, be aware that once you do so this data can then be made available freely under the ODbL terms and, where to the extent received by a user under ODbL terms, you will not be able to charge or place any other license controls over it.

Can I import other data which is also subject to the ODbL?

Yes, see the Import Guidelines for non-licence considerations.

So the process is:
can be made available under ODbL terms => no licence check nessesary

9

OSM ODbL is compatible with OSM ODbL, though you are not adding OSM ODbL data, but data from another source. ODbL requires you to attribute the usage. Where there is no issues within OSM ODbL since the attribution does not change. The data you going to import does not come form OSM, so will have a different attribution, which someone using OSM need to show to their users.

Since OSMF itself does not accept to be attributed somewhere on a hidden page, also your data would need to be attributed at the same place where OSM itself is attributed. Your waiver doesn’t include anything in this regards, as of my understanding. More or less each license requires attribution needs a waiver to only be attributed on an OSM-wiki page. At least your import page doesn’t contain the Rahmenbedingungen, mentioned in your waiver.

10

That is great, so no change necessary from my POV.
We are importing data licenced under OSM ODbL (which is compatible with OSM ODbL) as can be seen by linking to OSMs ODbL licence.

If that makes you happier, I can ask for clarification that with “for use in OSM under the ODbL-Lizenz” actually meant “for use in OSM under their licence”.

It does. Here is the section, you are quoting:

erfolgt zu den bereits ausgetauschten Rahmenbedingungen (Import/Indoor Navigatum#Tagging Plans).

Meant by this is the tagging plan is this part of the wiki Import/Indoor Navigatum - OpenStreetMap Wiki.

Specifically, the section in the green box about scope where i also explain why some things are out of scope, despite being technically possible:

  • not importing the name
  • not importing a rooms usage

Ironically, this is data which would have never been imported anyway, as the data quality here is more uncertain and likelier to be outdated.

11

Can you explicitly link to the section, where the owner of your data is waiving the attribution for the provided data? I might be blind, but can’t find such statement following your given link.

In general ODbL requires the attribution if I create a produced work.

12

Here is the position in the wiki:
https://wiki.openstreetmap.org/wiki/Import/Indoor_Navigatum#:~:text=Lieber%20Herr%20Elsinga%2C,2025!%20[REDACTED%20FOR%20PRIVACY]

13

I have no clue what you mean here.

The produced work would likely be nav.tum.de
There we attribute to © OpenMapTiles © OpenStreetMap contributors.
Does that clear up confusion?

14

TUM provided you data under ODbL. If I use that data to create a map, I need to attribute the source. Something like (C) Data by TUM.
That doesn’t change if you mix the data with OSM data. Only if you render a map you need to attribute both sources, TUM and OSM.

That is the issue, as OSM can’t guarantee the attribution of TUM.

15

But we want to provide data under OSM ODbL, not some parallel licence requiring different attribution…

My org (tum) provides data under OSM ODbL (NOT some weird TUM ODbL) proposing to import as OSM ODbL which is compatible with OSM ODbL.
=> No change in attribution requirement.
=> still © OpenStreetMap contributors as before

As noted in Proposed import of the indoor data offered for OSM by the Technical University of Munich (TUM) - #8 by CommanderStorm, importing under OSM ODbL seems to be one of the options, that OSM offers.
If said FAQ is outdated, that is fine, but I am very much confused.

TUM really isn’t concerned with ANY attribution of our own. That part is irrelevant for the university. “Just being a contributor” is fine.

The dataset being ODbL part comes from us, not the universitys legal/building department.
We thought that if the source is identical to the target, that should be the simplest.
Because where COULD be the conflict?
In all the talks with our building/legal department, it was always meant to be OSM ODbL.
I did not know that this could be the misinterpretation as some parallel licence.

As asked before:

Would a clarification that with “for use in OSM under the ODbL-Lizenz” actually meant “for use in OSM under their licence”work?

=> What kind of waiver would make you happy?

1 Like
16

There is no such thing as “OSM ODbL”. Based on your wikipage, TUM is providing data, which requires to attribute the author (author=TUM). At this point, OSM is not the author, so can’t be attributed. :wink:
Once you uploaded the data to OSM, they getting distributed by OSMF as ODbL and requires attribution of OSM as the author.

Maybe what TUM’s aim is, is providing data to OSM, which OSM is allowed to redistribute under ODbL. If so, that data either can’t be provided under a license requiring attribution or the attribution needs to be “on the OSM-wiki only” (which needs a waiver). Like you mentioned above. Your posted waiver can be understood like this, just you would need to change the wiki-page:

Data licence: ODbL-1.0
Type of licence: ODbL-1.0

to something like “To be used by OSM and redistributed under the terms of ODbL”

1 Like
17

I’ve looked at the tagging from the point of view of compatibility with Simple Indoor Tagging. Haven’t noticed any blockers. If anything, the careful deliberation about the tags to use highlights some of the deficiencies of our current documentation.

incline=up (for added clarity, all ways point upwards, can remove if wanted)

I would keep this, given the lack of a default direction for steps in OSM. Yes, a smart data consumer can infer it from the level tags on the elements connecting to the steps, but incline is a widely used key and adding it seems helpful.

Modeling something twice seems insane… If someone has a better grip on how stairs should be modelled, reaching out is appreciated. The documentation on this is quite conflicting.

I agree that the documentation is not ideal. The idea behind the stairs=yes tag was to offer a less detailed option for mapping entire staircases by adding a tag to the room. I don’t think it is necessary to draw extra indoor=area polygons around stairs in “semi-random” locations which are already mapped as linear ways.

Your import proposal does poke at issues which the OSM indoor community should really have formed and documented a consensus on. Another example of this are the “flat sections of the stair between chases”. I don’t really like highway=corridor for this, but there is no universally agreed-upon standard yet.

These gaps in the definitions are hardly your fault, though, so don’t let them stop you from proceeding with your import.

indoor=door (despite this not being on File:Indoor2.0 buildingpart.svg, which according to other docs should be a mistake)

Not a mistake, just a difference in opinion. Simple Indoor Tagging treats door=* as the primary tag for doors. The indoor=door tag is a later invention which I personally consider redundant, but as long as you set both tags, all data contributors should be able to work with your data.

We have a data donor who seems to be willing to let OSM use the data without any extra strings attached. So if you’re going to craft a custom waiver, I would not make it ODbL-only. The Contributor Terms allow us to change the license in the future, after all. Even CommanderStorm’s “for use in OSM under their licence” could be read as more accommodating in that regard.

But IANAL, and it’s unfortunate that OSM afaik doesn’t provide a standard text for these cases.

2 Likes
18

Thanks, I have updated the wiki page.

About the relicencing question:
I have asked TUMs building department if "for use in OSM under their licence" is meant by "for use in OSM under the [ODbL-Lizenz](https://wiki.openstreetmap.org/wiki/Open_Database_License)". :+1:
I will update this post, once I get a response.

3 Likes
19

TL;DR: I hate stairs. Have gone back and forth on this quite a few times. Me and the other contributor have discussed this multiple times, but have not found a particularly “satisfactory”.

Yes the choice was the way suggested by steps (highway=corridor + indoor=yes) vs SIT which states indoor=corridor is correct.
Semantically, that would not make much sense, though, as the second is an Enclosed walkway area that connects rooms. Stair-flights usually don’t contain rooms, but modelling them as rooms/polygons via indoor=corridor also has advantages for rendering…

One thing of the SIT-spec which we really strange is the following:

Stairs […] are connected to indoor=corridors via a door=* node on each floor. door=no can be used to tag a connection to a corridor when no physical door is present.

This would mean, that a stair with 2 flights per floor-change would consist of 4 doors=no per floor-change… Yes, if at the same lat/lon, they would need to be deduplicated via repeats_on, but still.

I am not convinced that this tagging makes sense for our situation, where stairs start/end in the middle of rooms.
Neither does anybody in my local area: overpass turbo
I don’t think including this makes sense…