Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Offer as Java library (for buildings) #171

Open
westnordost opened this issue Sep 8, 2020 · 6 comments
Open

Offer as Java library (for buildings) #171

westnordost opened this issue Sep 8, 2020 · 6 comments
Assignees

Comments

@westnordost
Copy link

(Follow up of streetcomplete/StreetComplete#1063 (comment))
It would be very useful if OSM2World would be offered as a Java library available on maven central. This way, other apps, such as StreetComplete, JOSM or Vespucci could easily show a 3D preview of a building when tagging.

As far as the interface is concerned, maybe something like this (example in kotlin)

val osm2world = Osm2World();
val tags = mapOf(
    "building" to "yes",
    "building:levels" to "5",
    "roof:levels" to "2",
    "roof:shape" to "hipped"
)
// in meters or something
val geometry = listOf(
    Point(0.0,0.0),
    Point(1.0,0.0),
    Point(1.0,1.0),
    Point(0.0,1.0)
)

// exports the building as a 3D object in OBJ format
val objString = osm2world.createOBJ(geometry, tags)
// and other formats maybe...
// or as data structure that can easily be processed into OpenGL statements when iterating through it
@tordanik tordanik self-assigned this Sep 9, 2020
@westnordost
Copy link
Author

What are your thoughts on this, @tordanik? Do you think this is realistic? Is there any better alternative than outputting it as a string (or writing it into a file) in some data format?

@tordanik
Copy link
Owner

tordanik commented Sep 12, 2020

Some thoughts:

  • I think this is realistic and I want to do it. There's some work involved, but the remaining problems are quite solvable.
  • For Android compatibility, I believe I will need to make some changes after all:
    • replace classes like java.awt.Color (shouldn't be hard – it's just a simple data carrier for RGB colors that is in the AWT package for historic reasons)
    • split off the OpenGL code into a separate module to avoid the JOGL dependency
  • Maven Central discourages dependencies from other repositories, which would affect earcut4j and osm4j. But as far as I know they do not strictly rule them out, so it would still be feasible. (Neither of these are strictly necessary to generate objs from buildings, but they would be awkward to separate from the rest of the core.)
  • The interface can look mostly like your suggestion. But if it's a general-purpose lib on Maven Central rather than a special-purpose build, I want to make it a little more generic:
    • allow more than one element to be passed in
    • have the method look closer to writeToTarget(geometries, ObjTarget(fileOrWriter)) – not sure I want to do an extra method for each output format (although there's something to be said for keeping the external interface simple and straightforward...), and the files that OSM2World produces for big inputs (rather than single buildings) can get large enough that streams/writers are preferable over keeping the entire string in memory. (To get a string, you could pass in a StringWriter.)

I think using an existing exchange format for models would be preferable over rolling our own, and OBJ is ok for that. (GLTF would be the more modern choice, but #157 is a larger task that I'm not going to get around to in the near future.)

In the simplest case, a model can just be a String, but that stops being a possibility if we need to handle additional files/resources, such as textures. If textures aren't needed and plain colors are sufficient, we can ignore these complications.

@westnordost: What's the visual appearance you're going for, do we need to look into textures etc.? Do you already know how you're going to feed the model to OpenGL – an existing library/component/...? – and which capabilities that will offer us?

@westnordost
Copy link
Author

That's great news!

Maven Central discourages dependencies from other repositories, which would affect earcut4j and osm4j

For what is osm4j used? All of it, or certain modules only?

@westnordost: What's the visual appearance you're going for, do we need to look into textures etc.? Do you already know how you're going to feed the model to OpenGL – an existing library/component/...? – and which capabilities that will offer us?

I am going to feed it to GL10 or something. The plan is to use the library just to preview the building roof's shape and orientation, so a simple shape, maybe with the roof tinted red and the rest tinted white. I can use up to GL ES 2.0 at the moment and when/if I set the minimum Android SDK version to 5.0, I can use up to GL ES 3.0.

The issue with textures in general is that since then we exit the realm of abstract shapes towards a more realistic look, much more is needed to make it look good, just texturing the surfaces is not enough: Roofs need to extend past the walls, they need a rain gutter, other details such as a chimney, the building's wall become 3-dimensional as well, with balconies, embellishments etc and other random details and variations. Since all this decoration is then mostly not based on actual data, I consider this quite the separate project which would maybe take the abstract shape data as a starting point. I recently saw a demo of a fly-through through some neighbourhood (in unity I think) supposedly based on OSM data, I think I got the link from OSM Weekly. It looked really good, but it had little to do with a simple 3d-extraction like OSM2World does anymore.

@tordanik
Copy link
Owner

Simple colored shapes are easy to do, so that's fine with me. (You're right that truly life-like visuals can't be achieved without procedural techniques, i.e. adding a lot of details that aren't actually mapped in OSM.)

For what is osm4j used? All of it, or certain modules only?

I'm using the osm4j-core, osm4j-pbf and osm4j-xml modules to read OSM data. It's then immediately converted to OSM2World's own representation of OSM data that's more convenient for me to work with. So osm4j is not necessary for your use case, seeing how you are going to pass in the geometry yourself, but atm I see no good way to split it off.

@matkoniecz
Copy link
Contributor

Once this is implemented streetcomplete/StreetComplete#1063 should be reopened (feel free to ping me if I will somehow miss it)

@Beakerboy
Copy link

I’ve started a javascript based project that might fill this niche. It uses the three-js library.

https://beakerboy.github.io/OSMBuilding/

Given a way_id, the script pulls any building parts that are within the bounding box and renders them. So far it just supports domed roof shape, and simple ways, no multi-polygons or relationships.

I’d love to borrow any code from here that creates hipped, gabled, or any other types of roofs.

I’m willing to take help from anyone who knows more about javascript or 3D graphics than I.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants