OpenGeofiction

Realistic node density per kilometer

Posted by EMKLI on 18 October 2019 in English (English)

Working on the skerry coast around Frjalshöfn, it just happened that I imported 680.000 nodes into JOSM, spreading on a total edge length of about 4.500 km. This results in 150 nodes per kilometer, which means, one edge is 6 metres long on average. Don't worry, I deleted everything. ;-) (Just for explanation: of course, I didn't draw this by hand. I used the "how to create realistic forsest coverage" method from the wiki and then fractalized the shapes).

For an edgy coast line like a skerry coast, what node distance would be adequate? 20 metres? 50 metres?

Comment from iiEarth on 18 October 2019 at 16:36

A skerry? Like a small, rocky island? I would say a node should be at least 10-20 meters apart depending on the size. If it is slightly bigger, just do 30. 50 meters apart is a bit too much, but if you make a very edgy island, then it is fine. Your node distance can be different in different places of the island.

Hide this comment

Comment from Luciano on 18 October 2019 at 16:41

Two observations, one about method and one technical.

RE method: why not just look at some OSM data you're wanting to resemble? That will give you an idea pretty quickly about node density, etc.

RE technical: once you've uploaded 680.000 nodes to the database, going back and deleting them doesn't "fix" the problem. That's because the OSM data model used in OGF keeps a FULL HISTORY of all edits. So uploading 680.000 nodes might be thought of as 680.000 discrete "edit events." Deleting them ADDS another 680.000 "edit events" to the database, and removes nothing, for a total of 1.360.000 "edit events." Once the mistake is made, it's made. I don't mean this as criticism! - I learned this the hard way, since I have made similar mistakes myself.

One habit I try to use now: anytime I use freedraw or some other tool to produce node-dense ways, I go through each way created in JOSM and hit "Shift-y" - this "simplifies" the way on some criteria that balances node density with appropriate level of detail. On a freedrawn way, I can sometimes reduce my node density by 60% or more this way.

Hide this comment

Comment from EMKLI on 18 October 2019 at 17:06

Luciano, don't worry! Those nodes never made it to the database! ;-) I deleted everything in JOSM, right after I did my calculations. There was no upload and no deletion. Exactly because I am aware of the "problem" (i.e. totally normal process for that kind of database editing) you have described and I thought that the "realism" of 680.000 nodes does not in any way pays out for the burden this means for the database (and the rest of the commnity).

In the meantime, I have found a satisfying workflow for me. When fractalize in Inkscape, I use 4 subdivisions with a smoothness of 5. Then, after importing the object in JOSM, I simplify the line (exactly like you proposed) which just left me with 12.000 nodes for a shoreline of 550 km, so about 50 metres per node. I think this might be an acceptable compromize between smoothness and database burden.

Hide this comment

Comment from EMKLI on 19 October 2019 at 22:05

By the way, Luciano, another question concerning database performance has come to my mind. As the maximum number of nodes in a line is 2.000, does it have any advantage to partition longer lines in such a way that there are (if possible) as much as possible lines with exactly 2.000 nodes?

Hide this comment

Comment from Rhiney boi on 20 October 2019 at 18:55

To answer your question, EMKLI, yes it does, for it requires less ways on the database, taking less space. However, it is difficult to achieve such a feat, therefore not many do it, if any do it at all.

Hide this comment

Comment from AustinofOketia on 20 October 2019 at 22:46

I'm really detailed when I want to be, for example I did 5 nodes in one meter and did this for about 100 meters, but that was time consuming...

Hide this comment

Leave a comment

Parsed with Markdown

  • Headings

    # Heading
    ## Subheading

  • Unordered list

    * First item
    * Second item

  • Ordered list

    1. First item
    2. Second item

  • Link

    [Text](URL)
  • Image

    ![Alt text](URL)

Login to leave a comment