Planning a project and need help to sort a few questions

General
1

Hi all

I’m planning to do add several portuguese castles and I have a couple of questions that I’m hoping the more experienced mappers can help me sort it out :slight_smile:

  1. Can I upload a geojson (or other) with all the data instead of adding one by one?

  2. Castles are buildings (osm taginfo shows that most of castles are also tagged as buildings) but if I use lines to draw the walls, I’m getting a warning

“(…) should be a closed area based on the tag building=yes”

Any ideas how to sort this? Doesn’t seem right to use a polygon to this…

  1. Maybe I should create a relation? And aggregate walls, towers and other elements?
    Any good short “how-to create a relation”?

  2. I added two castles to try and I’m planning to use the following tag template when possible:

historic=castle
castle_type=

name= (the default name, used locally)
name:en= (the name in English)

alt_name=
alt_name:en=

historic:civilization=medieval

ruins=

building=yes

wikipedia=en:some_one

wikipedia=pt:some_one

(*Actually this doesn’t seem possible… after using wikipedia=en: I can’t seem to add wikipedia=pt: because I can’t add two wikipedia=

wikidata=

image:1=
image:1:caption=
more_info:1=
more_info:2=
more_info:3=

wikimedia_commons=File:xxx.JPG

start_date=
start_date:edtf=

end_date=
end_date:edtf=

  1. Some castles have a start date but are located on places where older archaeological findings exist. For example, a XI castle (there are royal documents for the castle in XI century) is located on the top of a hill where archaeology digs revealed findings from 3000BC. Not clear if there was humans there from 3000BC to XI. Anyway, the castle walls are from XI. Let me add that today we can see the XI walls and some walls from later centuries.
    what should be the correct approach to the start date?

Any good example how to implement the life cycle with relations? There are castles with parts from different dates.

Sry to bother with all this :slight_smile: also planning to become more autonomous :slight_smile:

2

oh and
source=
source:date=

3

All of your questions are great - no need to be autonomous!!

Quick answers now (I’m on a phone):

  1. yes, you can upload everything at once, but you may need to convert the geojson to shapefile & then upload the data using the open data plugin in JOSM.

  2. Buildings must be polygons in OSM/OHM, although you can also create them using relations. Can you share a pointer to how you’re trying to build the castles? If you want to use just a line for the wall, you may need to tag the line with barrier=wall

  3. not sure of a good how-to, but I’m sure there’s a good learn OSM resource.

Ok, gotta run. More soon!

1 Like
4

I now added 5 castles to try.

2 castles are simple areas features and 3 are relations. I’m probably doing something wrong because when using the OHM search I can only find the area-castles, I can’t find the relations .

Can someone pls check and give me some feedback? Also looking for improving the relations geometry because I have more buildings to add (churches, etc.)

Castle of Ranhados

Castle of Rebordãos

Castle of Abrantes

Castle of Algoso

Castle of Ansiães

1 Like
5

In iD, open the Map Data panel on the right side of the map and click the … button beside “Custom Map Data” to load a GeoJSON file as a reference layer. You can’t directly upload the GeoJSON features, but you can copy tags from it and trace it manually.

This thread in the OpenStreetMap forum has some tips for working with GeoJSON in JOSM:

You can enable the Open Data plugin to open additional GIS formats.

It looks like you’ve mapped the castle as a multipolygon consisting of the walls. Looking around at some forts and castles in OSM, I think it’s more common to map the building as an ordinary area (or multipolygon) and then also map the individual walls as lines connected to the building area. It isn’t quite a castle, but the ravelin of the Castillo de San Marcos in St. Augustine, Florida, is mapped as a building connected to walls that don’t wrap all the way around.

You don’t really need both. Just pick the most relevant language to go in wikipedia=*. In fact, I hope we can eventually deprecate all the Wikipedia links, and most of the Wikimedia Commons links, because a data consumer should be able to reliably infer all that information from the wikidata=* tag:

How much is known about the various structures on the site over time? In general, I would map each stage of a building’s evolution as a distinct building area, possibly connected to the others for convenience, then add all the building areas to a common chronology relation. This will be more difficult if all you know about an earlier castle is where one of the walls stood. You may have to extrapolate to some extent, or leave a gap in the chronology relation. (That is, the relation’s start_date=* can be much earlier than the first member’s start_date=*.)

I think Nominatim is unable to find this relation when you search for “Castelo de Abrantes” because it has an unclosed ring, making the geometry invalid:

A gap in the outermost ring of a multipolygon relation.
A gap in the outermost ring of a multipolygon relation.1280×960 34.3 KB

These multipolygons are also topologically invalid. The members of a multipolygon must form distinct closed rings. The rings may be nested inside each other or entirely separate, but they cannot touch. A node can never be a member of a multipolygon relation. Normally, you don’t need to add a building entrance to a relation, as long as the node is connected to the building area’s outer edge. However, in a rare case where the entrance is disconnected from the building, you’d use a building relation.

1 Like
6

Thank you for the detailed answer and patience :slight_smile :slight_smile:

I’m probably better with relation:site. That’s also the suggestion from the Tag:historic=castle

Will dive into chronology after getting a tag template right.

And I’m already playing with JOSM for future edits. The easy presets plugin is going to be useful.

After updating these 5 castles (hopefully fixing all issues) can I ask here for a review to check if all is ok?

7

Trying to fix this

1. First I tried like this:

One relation:site (name Castle of Algoso and all the other related tags: wikidata, etc) with 3 members:
1 line for the wall
1 point for entrance
1 area for tower

Still couldn’t find it using the search/nominatim…

Then I added 1 point/node at the center of the castle with historic=castle and name (and all the other related tags: wikidata, etc). Everything was findable with search/nominatim but now I had 1 point and 1 relation with same name so dropped the relation.

2. Now there’s 1 point/node at the center of the castle with historic=castle and name (and all the other related tags: wikidata, etc)

  • I’m using this point to store all the related tags: wikidata, etc
  • Dropped the relation:site
  • Defined a start date to each element

everything is findable with search/nominatim

pros/cons

  • like this I can actually define different start dates for each element which might be very useful when a castle have different construction stages.

  • like this it will be easy to replace name, sources, links etc (I just change the point with start dates and end dates).

  • all element are separated, how can I group these element? Or it’s not really necessary?
    I thought about drawing an outline but not sure how. If I draw an area it will cover all the elements.

8

Unfortunately, Nominatim doesn’t index site relations either. But don’t let Nominatim’s lack of support for a particular feature type dictate how you map something if it’s clearly the right representation. Since support for site relations is currently pretty minimal across all of the OSM ecosystem, I typically only map it in addition to some other representation, not as a replacement.

In theory, it isn’t necessary because one can query Overpass or QLever for the features of interest within a bounding box that covers this site. However, people often like to visualize features as a whole on the main site. For something like a building made of various parts, I think you might be able to achieve something nice using a building relation. The documentation doesn’t explicitly address walls, but outer is one of the most common roles for that relation type in OSM; I assume it’s for an outer wall of the building.

Perhaps a simpler approach would be to convert the historic=castle point into an area that connects to each of the nodes of the walls and tower. Although this looks similar to what you had before, it isn’t a relation of any kind:

An area that encompasses and connects to the outer walls and the tower.
An area that encompasses and connects to the outer walls and the tower.908×1264 83.1 KB

Nominatim will be able to find this area. We recently overhauled the renderer to automatically label an area at its centroid, so you don’t have to eyeball the centroid anymore. The only downside is that overlapping ways are a little inconvenient to work with in JOSM. (You have to double-click inside the area or middle-click on its edge to select it.)

1 Like
9

Using buildings relations could be great because I would start with 3D Buildings.

  • But would Nominatim index this relation?

About converting the historic=castle point into an area: wouldn’t this area be on top (covering) of the wall, entrance and tower? isn’t this bad? is there a way to “lower” this area?

10

Nominatim doesn’t index type=building, either, as far as I can tell. However, the nice thing about a building relation is that the outline member is supposed to be an ordinary building=* area with all the usual tags like name=*, which Nominatim will index.

Building areas normally shouldn’t overlap, but you can set layer=* tags to deconflict them in some edge cases where buildings overlap in vertical space. In this case, it isn’t a problem at all, because the castle is a historic=castle, not a building=castle. They can certainly overlap and connect.

1 Like
11

OK I think a 3D castles project is a doable and great idea :slight_smile:

First try: OpenHistoricalMap
Have 5 elements
1 area for outline (building=castle) + 4 building:part

I needed 4 because I actually draw the area to make the door later.

Now it looks like this in JOSM 3D plugin

Screenshot from 2024-08-02 19-30-20
Screenshot from 2024-08-02 19-30-20777×720 48.2 KB

But, in 2D (OHM) I now see this…

Screenshot from 2024-08-02 18-49-14
Screenshot from 2024-08-02 18-49-14448×648 7.01 KB

It looks like the building=castle area (needed for the 3D outline) is rendered on top of wall and tower. Any ideas?

For the walls, I decided to drop the lines and go for areas. I was expecting to see on OHM something more like this

Screenshot from 2024-08-02 19-42-16
Screenshot from 2024-08-02 19-42-16559×873 80.1 KB

btw, any plans for OHM 3D? :smiley:

1 Like
12

Yes… you’re showing us how it’s done!

Your entire project sounds fantastic. I’m so glad you’re doing this and experimenting to find out what approach works best.

For your castle, I noticed that there are a couple of shapes on the same spot:

You have Way: Castle of Algoso (200386330) with some amazing tagging here:

Monosnap Way: ‪Castle of Algoso‬ (‪200386330‬) OpenHistoricalMap 2024-08-02 18-45-19
Monosnap Way: ‪Castle of Algoso‬ (‪200386330‬) OpenHistoricalMap 2024-08-02 18-45-191920×1936 187 KB

And, in the same location, there’s another object:
Way: 200386333

Monosnap Way: 200386333 OpenHistoricalMap 2024-08-02 18-48-56
Monosnap Way: 200386333 OpenHistoricalMap 2024-08-02 18-48-561986×1580 287 KB

So, essentially, the second way is getting rendered on top of the first way. And, unless the entire courtyard enclosed by the walls is actually a building, the first shape may be off a little bit.

Have you considered making a relation for the castle of type=multipolygon and building=castle and all the other tags, with the main building structure as one member way and the wall as another member way?

1 Like
13

It seems counterintuitive to me that none of the castle can be rendered in 3D unless the whole thing is a building. The original reason for building relations was to account for buildings that include overhangs and other things that aren’t technically part of the building footprint. But your approach of mapping the walls as areas is pretty good, assuming you’ll have good enough imagery to work with for the rest of the structures in your project.

Yes, we have plans for 3D! The rendering library we use on the main site does support it, but it’s running in an emulator for compatibility with outdated code we inherited from OSM. We badly want to modernize that code. A possible shorter-term solution could involve a standalone map such as OHM embed. Either way, we’ll need some changes to the vector tiles to expose the 3D building data to the client side:

2 Likes
14

Hello!

Just wanted to chime in on this topic because I’m also interested in mapping the evolution of the built environment in Portugal and I’m very excited to find a compatriot with similar ambitions.

Following the structure of the Portugal Project on OSM Wiki, I have created a matching community project page for Portugal on OHM Wiki. Among these I already included a subpage for built heritage, which itself has a space for military architecture.

I would like to invite @nafergo to document his Castle project on this dedicated space, in order to share his experience and promote mapping best practices for the community.

Best,
Selva

4 Likes
15

This is great :slight_smile: I’ll do!

2 Likes
16

It’s coming close Relation: ‪Castelo de Algoso‬ (‪2826539‬) | OpenHistoricalMap

After getting one right I’ll write some notes for helping others.

Trying to follow Simple 3D building spec, this is where I am right now:

1 super relation type=building
This super relation has 5 members:

a) 1x relation type=multipolygon, role=outline, tagged with building=, all main tags are here

b) 4x building:part=yes, role=part

  • The main tags (photos, start date, etc) are used on type=multipolygon . Not sure if I should replicate them in super relation type=building .

  • When using JOSM to upload I get a bunch of warnings because of duplicated nodes and overlapping buildings. Is this allright? Can I fix this somehow?

  • The name is at the tower centroid but the tag is used in the type=multipolygon. Was expecting it in the middle of the courtyard. Am I doing something wrong?

  • Right now, I can see 2D castle as expected (tower is full, courtyard is open). 3D looks good (for now) at JOSM. Is there a way to check 3D in OHM?
    A simple viewer like this GitHub - Beakerboy/OSMBuilding: render an individual OSM building would be useful just to check if 3D in OHM is the same as in JOSM.

side note: JOSM is great but there are a few rough edges :slight_smile: any suggestion for node snapping?

1 Like
17

@nafergo - love these questions. They are highlighting some things that aren’t immediately obvious.

I hadn’t thought about the need for super relations for a single building, but I can see how that can be necessary. So, no real opinion on that yet, without some further thought. Seems like it should be just fine, but again, need to think further. :thinking:

The main tags probably belong on whatever you feel represents “the whole castle”. So, my first instinct is to put them on the super relation for sure. But, again, I’m not as familiar with 3-d buildings and whether the super relation is important for data modeling or just for grouping 3-d structures.

You’re doing nothing wrong with the label! The label position is working as designed, as long as you have not set an explicit label point. Without a label node, the label algorithm tries to draw the largest circle “inside” the bounds of the castle shape and automatically adds the label at the center of that circle. So… it tries to draw it inside the “gray” areas of the castle structure & the biggest circle it can draw is in the tower.

Monosnap Relation: ‪Castle of Algoso‬ (‪2826539‬) OpenHistoricalMap 2024-08-05 13-46-21
Monosnap Relation: ‪Castle of Algoso‬ (‪2826539‬) OpenHistoricalMap 2024-08-05 13-46-211036×1406 93.3 KB

Luckily, you can put the label whereever you want. Just put a node where you’d like the label to be, tag it appropriately with a name=Castelo De Algoso and then add that node to the relation with a role of label.

We don’t have a 3d viewer integrated into OHM and conversely, I don’t believe any standalone 3d viewers have integrated OHM as an endpoint. But… any system that’s designed to use OSM data should (emphasis on “should”) be able to use OHM data. The obvious difference would be that we would need to time-enable those viewers. Is there a 3d building / OSM viewer you’re most familiar with?

The Beakerboy/OSMBuilding repository looks like we’d need to modify the code in a few places or put in a request to be able to use alternative API endpoints.

For JOSM, there should be a variety of snapping options. See the docs on how this works. The key thing to know is that the cursor changes when JOSM is ready to snap to a node - you’ll see a little red arrow pointing at a node underneath the crosshairs.

Draw – JOSM 2024-08-05 14-20-26
Draw – JOSM 2024-08-05 14-20-261724×624 105 KB

For the validation errors, like nodes at the same location, you can just right-click on those validations and select “Fix”. For overlapping ways, there are often valid reasons for having overlapping ways. I’d just go into JOSM->settings->validation options and turn off that check.

1 Like
18

OSMBuilding now supports OHM via a URL parameter. Here’s the Castelo de Algoso:

A building and walls in 3D.
A building and walls in 3D.2540×1636 108 KB

1 Like