You are not logged in.

#1 2020-05-31 22:39:12

DWeaver
Member
Registered: 2020-05-29
Posts: 6

GSoC Indoor Tagging Support for OSM2World

Hi all

In a couple of weeks I plan to start work on OSM2World for Google Summer of Code. OSM2World currently renders in 3D many outdoor features which have been mapped in OSM, but unfortunately there is no support for indoor features as of yet. Over the next 3 months I plan to add this functionality and hope to post at least weekly updates of my progress here.

Feedback would of course be much appreciated.

OSM2World: https://wiki.openstreetmap.org/wiki/OSM2World

OSM GSoC: https://summerofcode.withgoogle.com/org … /#projects

Dan

Offline

#2 2020-06-01 08:07:07

R0bst3r
Member
Registered: 2015-04-23
Posts: 576

Re: GSoC Indoor Tagging Support for OSM2World

Looking forward to it. Sounds amazing.

Offline

#3 2020-06-16 12:25:49

DWeaver
Member
Registered: 2020-05-29
Posts: 6

Re: GSoC Indoor Tagging Support for OSM2World

Exams have finished slightly earlier than expected so I can now start work on my project. Here is a rough plan for the coming weeks:

gV1PvQM.png

As I am now starting earlier, (if all goes to plan) there should be an extra week free to add more features

Dan

Offline

#4 2020-06-22 11:22:27

DWeaver
Member
Registered: 2020-05-29
Posts: 6

Re: GSoC Indoor Tagging Support for OSM2World

Week 1

Week 1 had a bit of a slow start as I could not compile the latest version of OSM2World, but as soon as this was fixed I started work on rendering some basic walls. Most of this time was spent creating a good framework for adding later features, so hopefully this was spent well.

Rendering walls of just 2 nodes worked perfectly, but due to how walls (indoor/outdoor) are rendered, multi-node walls were a bit more of a challenge.

9phKlIl.png

The easiest fix for this was to just split multi-node walls into segments of 2 nodes. This will need to be updated later however when adding doors and windows etc.

Rooms were the next problem for the week. These consist of a wall round the edge, a ceiling and a floor, all of which were created without too much hassle.

Finally, indoor areas were the last task. Areas define just a floor, so as this functionality had already been implemented, indoor areas were quite quick to get working.

vcgiPM1.png

Bottom right: a basic room, level 0
Bottom left: a room containing a wall, level 0
Top Left: a room, level 0 and area, level 1
Top Right: a room, level 0 and a room, level 1

All objects are placed at a height corresponding to their level, this assumes that all levels of a building are of equal heights which may not be the case.

This also works for any shaped room, wall or area:

Fy173CB.png

Offline

#5 2020-06-28 12:01:44

!i!
Member
Registered: 2009-11-28
Posts: 3,307
Website

Re: GSoC Indoor Tagging Support for OSM2World

Great to hear (your) progress on OSM2World. Might inspire me to have a clother look at this indoor mapping thing.
I guess currently here we only have some pretty raw mapping like passages through malls / levels of shops / ... .
Do you think it would be possible to show also underground levels e.g. by multi level train stations etc.?


privater Account von KVLA-HRO-Mei

Offline

#6 2020-06-29 12:06:21

DWeaver
Member
Registered: 2020-05-29
Posts: 6

Re: GSoC Indoor Tagging Support for OSM2World

Week 2

Starting to pick up speed this week getting plenty of tasks done.

Hopefully the screenshots will look a little better as I am now using the default textures.

Corridors

To start off with, I implemented rendering of indoor corridors, this was relatively straight forward as corridors only consist of a floor and a ceiling which are tasks that I have already overcome.

47uNetS.png

Multilevel Rooms

Not all rooms, corridors or walls are a single level high. The tagging standard says that indoor features spanning multiple levels can be tagged in any of the following formats: level=-1;5 , level=-1-5 or level=-1--2 and as such all of these should be supported. The below screenshot is from the inside of a room tagged level=2-6, it may be a little hard to tell the scale so there is a screenshot for a single level room as well.

sT8j3Oz.png

8NVN5Lt.png

Indoor Ways Take Precedence

Something that I had not thought about was that not all walls of a room will be made of the same material. To map this, a wall placed at the same level as a room and using the same nodes could be given a different material to the room. My code from last week could just about show this as it simply rendered the wall in the same place as the room wall, but this caused some artifacts and was not particularly nice to look at. This would also not have allowed partially transparent textures as you would just see to the room wall underneath. So a slightly more intelligent system was needed.

Essentially, any room wall segment that is is also being used by a wall segment will not be rendered, allowing for only the wall at that location to be shown. This does mean that multilevel rooms are rendered in "strips" corresponding to each of their levels and as such multilevel room walls that are not overlapped by walls will be rendered in many strips. This is not the most efficient as they could be rendered as one large rectangle, but this could be improved at a later date.

qrlhZno.png

indoor=level

The indoor=level tag can be used for an area that outlines a whole level. This element can be given data such as the level name or height. This height data is now used to vary the height of objects placed at that level. Any level that does not have height data is given a default height based on the given height data and the height of the building, meaning the overall height of the building will not change. This can be most easily shown using the same room as above, here level 4 was given a height of 5 meters:

1caPoFA.png

Underground

Finally, support for underground levels was added. This works as you would expect, with elements tagged with a negative level being rendered under the terrain. It is a bit hard to make out was is going on in the below image but there are walls, rooms, areas and corridors all being rendered beneath the terrain (which can't be seen from below).

1n9AvaM.png

A small issue with this however is that when using srtm data the terrain runs straight through buildings. I am attempting to fix this early this week, cutting holes in the terrain for buildings with indoor data that intersect the ground.

T0cNffJ.png

Real World Example

All of the screenshots that I have used so far have been of test data so I though I would add a couple of real world examples. The screenshots below are from Aachen University (https://openlevelup.net/?l=0#18/50.77959/6.07545)

In the second image there seems to be problems with some rooms not being rendered properly, this is currently being looked into.

CUGOCdF.png

NjHGGjk.png

Offline

#7 2020-06-29 12:17:52

DWeaver
Member
Registered: 2020-05-29
Posts: 6

Re: GSoC Indoor Tagging Support for OSM2World

!i! wrote:

Great to hear (your) progress on OSM2World. Might inspire me to have a clother look at this indoor mapping thing.
I guess currently here we only have some pretty raw mapping like passages through malls / levels of shops / ... .
Do you think it would be possible to show also underground levels e.g. by multi level train stations etc.?

Yes. As underground levels are now supported this should be possible. Make sure to add the "building:levels:underground" tag to the building outline. I am not sure what will happen for things such as tube stations in London that are fully underground, so I may play around with that this week. Currently this code is not fully integrated into OSM2World yet so it will not be the easiest to use, hopefully I will make a pull request that is accepted in the near future. https://github.com/tordanik/OSM2World

Offline

#8 Yesterday 12:00:49

DWeaver
Member
Registered: 2020-05-29
Posts: 6

Re: GSoC Indoor Tagging Support for OSM2World

Week 3

This week the majority of the minimum functionality was completed, as well as testing most of the output formats. The min_level and max_level tags were also implemented, however their logic was implemented incorrectly and so I will be fixing this over the coming days. The other features added are below.

Cut holes in terrain

A problem identified last week was the fact that terrain would be rendered throughout a building. This is fine when you are only looking at the outside of buildings, however is obviously an issue when rendering indoor features. To avoid this, for any building in contact with the terrain and with indoor elements, the outline of that building will be cut from the terrain.

S40hEW2.png

Config Options

To provide rendering options to the user a config file can be provided to OSM2World. This contains key value pairs that can be used to determine how (or if) objects are rendered. More information can be found here: https://wiki.openstreetmap.org/wiki/OSM … ation_file.

In previous weeks, to view indoor elements I would have to manually prevent outer walls from being rendered in the code, and it was difficult to view individual levels. To make it easier to do these things, as well as allowing a user to do these a few config options have been implemented:

noOuterWalls - Boolean
noRoofs - Boolean
renderLevels - List of Integer
notRenderLevels - List of Integer

With non of these options a building may be rendered like this:

7HVVknV.png

noOuterWalls = true
noRoofs = true
renderLevels = 1,6,7,8,9,15

Ng5uop0.png

noOuterWalls = true
noRoofs = true
notRenderLevels = 1,2,3,4,5

61gBjmR.png

If levels are defined in both renderLevels and notRenderLevels, notRenderLevels will take precedence and that level will not be rendered. In the following example only levels 8,9 and 15 are rendered.

noOuterWalls = true
noRoofs = true
renderLevels = 1,6,7,8,9,15
notRenderLevels = 1,6,7

Ea4h02X.png

If there are any other config options that you think would be useful, I would love to hear them.

Roof Levels

Roof levels have not been rendered up until now. Due to the possible complex roof shapes is is difficult to render an object with the right shape or even determine whether an object is contained within a roof. After some discussion with my mentor, roof levels will be rendered ignoring the shape of the roof. This will allow objects to protrude from the roof, or even not be contained within the roof at all. This may be fixed at a later date.

ijdIYD3.png

Offline

Board footer

Powered by FluxBB