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

shortbread: Bring boundaries processing in line with definitions #10

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

pnorman
Copy link
Contributor

@pnorman pnorman commented Feb 19, 2024

Shortbread requires ways be part of an administrative boundary, but a boundary=disputed can influence the properties of a way that is also part of boundary=administrative.

Field name Description
disputed Boundary line is tagged with disputed=yes or member of a relation with boundary=disputed and admin_level unset or between 2 and 4

I tested this with the following OPL

n1 v1 dV c0 t i0 u T x0 y0
n2 v1 dV c0 t i0 u T x0 y1
w1 v1 dV c0 t i0 u Tdisputed=yes Nn1,n2
w2 v1 dV c0 t i0 u T Nn1,n2
w3 v1 dV c0 t i0 u Tdisputed=yes Nn1,n2
w4 v1 dV c0 t i0 u T Nn1,n2
w5 v1 dV c0 t i0 u Tdisputed=yes Nn1,n2
w6 v1 dV c0 t i0 u T Nn1,n2
w7 v1 dV c0 t i0 u Tdisputed=yes Nn1,n2
w8 v1 dV c0 t i0 u T Nn1,n2
w9 v1 dV c0 t i0 u Tdisputed=yes Nn1,n2
w10 v1 dV c0 t i0 u T Nn1,n2
w11 v1 dV c0 t i0 u Tdisputed=yes Nn1,n2
w12 v1 dV c0 t i0 u T Nn1,n2
r1 v1 dV c0 t i0 u Ttype=boundary,boundary=administrative Mw1@,w2@
r2 v1 dV c0 t i0 u Ttype=boundary,boundary=administrative,admin_level=2 Mw3@,w4@
r3 v1 dV c0 t i0 u Ttype=boundary,boundary=administrative,admin_level=3 Mw5@,w6@
r4 v1 dV c0 t i0 u Ttype=boundary,boundary=disputed Mw7@,w8@
r5 v1 dV c0 t i0 u Ttype=boundary,boundary=disputed,admin_level=2 Mw9@,w10@
r6 v1 dV c0 t i0 u Ttype=boundary,boundary=disputed,admin_level=3 Mw11@,w12@

Output from select way_id, admin_level, maritime, disputed from boundaries was

 way_id │ admin_level │ maritime │ disputed
────────┼─────────────┼──────────┼──────────
      3 │           2 │ ¤        │ t
      4 │           2 │ ¤        │ ¤
(2 rows)

@pnorman pnorman added the shortbread An issue with the supplied shortbread or shortbread_gen themes label Feb 22, 2024
@joto
Copy link
Contributor

joto commented Mar 10, 2024

Sorry, I can not figure out from your description or the code what the problem here is. Maybe the problem is the description in the shortbread definition which is rather terse and not worded unambiguously and we need to fix this first.

Also the change contains some print commands which look like they are from debugging. They should not be in the final code I think.

Can you split this PR into smaller ones somehow?

@pnorman pnorman self-assigned this Mar 14, 2024
…lues

Shortbread says 2 and 4 are the valid values of admin_level, so this
doesn't look at a relation that is only tagged with
type=boundary boundary=administrative and has no admin_level tagging.

This doesn't strictly comply with shortbread because a member of a
admin_level 3 and admin_level 4 relation should get admin_level set
to 3 but I don't believe that's the intent of the spec.
Previously a member of multiple relations would take its disputed status
from the last relation processed. For example, processing a way that is
a member of two relations, with

    type=boundary boundary=administrative admin_level=2
    type=boundary boundary=disputed admin_level=2

would lead to order-dependent results, where disputed only comes from
the last relation processed. Another issue was that a relation with

    type=boundary boundary=disputed

and no other tags would not be considered as tonumber(tags.admin_level)
is not truth-like.

Instead, what is done is to get the disputed status for the relation,
and then set it to true for the rinfos in that relation, not setting
any existing rinfos to false. They are only set false when creating the
entry in rinfos for the first time.
@pnorman
Copy link
Contributor Author

pnorman commented Mar 14, 2024

I've split it into two commits. Most of the changes are bug fixes for a clear bug where the OSM IDs of relations would change how objects are processed because order mattered.

I find the only ambiguity is handling boundary=administrative with no admin_level.

There are some parts that are silly, and anything to do with admin_level=3 is not implemented. According to the spec a way that is a member of a admin_level=3 and admin_level=4 relation needs to be in the table with admin_level=3. but if you delete the admin_level=4 relation it is not present.

Another case is that admin_level=3 boundary=disputed type=boundary is supposed to be handled the same as admin_level=2 since it is between 2 and 4.

@joto
Copy link
Contributor

joto commented Mar 14, 2024

@pnorman
Copy link
Contributor Author

pnorman commented Mar 15, 2024

I'd still like to go with this because it fixes what is a clear bug and is a reasonable interpretation of what's written. When we define it more precisely in shortbread we can change the code here to match.

@joto
Copy link
Contributor

joto commented Mar 15, 2024

Sorry, I currently don't have the bandwidth to understand all the details here. Lets concentrate on clearly defining this in the standard and then fix the implementation.

@pnorman
Copy link
Contributor Author

pnorman commented Mar 15, 2024

I'll bring the boundaries processing into my code then.

@pnorman pnorman closed this Mar 15, 2024
@joto
Copy link
Contributor

joto commented Mar 15, 2024

This still needs work here at some point, so I'll reopen this as a reminder.

@joto joto reopened this Mar 15, 2024
pnorman added a commit to pnorman/spirit that referenced this pull request Mar 20, 2024
This removes the bug where boundaries would be processed differently
depending on order of relations.

Ref osm2pgsql-dev/osm2pgsql-themepark#10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
shortbread An issue with the supplied shortbread or shortbread_gen themes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants