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.

Sign up for GitHub

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

Jump to bottom

landuse_kind not always present on buildings #1226

Closed
nvkelso opened this issue Apr 27, 2017 · 9 comments
Closed

landuse_kind not always present on buildings #1226

nvkelso opened this issue Apr 27, 2017 · 9 comments
Assignees
@zerebubuth
Labels
bug loe medium qa complete
Milestone
v1.5.0

Comments

@nvkelso
Copy link
Member

nvkelso commented Apr 27, 2017

  • What did you see?
    Reported via support, the buildings at LAX Airport in Los Angeles mostly have the expected landuse_kind properties, but not always, and even the same building can include or not include the property at different zooms.

  • What did you expect to see?
    All buildings on the airport landuse polygon should get landuse_kind consistently.

  • What map location are you having problems with?

  • Screenshot?

zoom 14 has the main international terminal without, while terminal 2 includes it:

screen shot 2017-04-26 at 20 44 03

screen shot 2017-04-26 at 20 43 40

While zoom 14 didn't include the property, now zoom 16 does on nearby United building:
screen shot 2017-04-26 at 20 44 12
@nvkelso nvkelso added the bug label Apr 27, 2017
@nvkelso
Copy link
Member Author

nvkelso commented Apr 27, 2017 •
edited
Loading

We think this is because the centroid for the building is calculated on a larger clip than the landuse polygon (buildings include overlap into adjoining tiles, landuse doesn't). They both need to be based on the same clip for this calculation, and then the later step to clip features to exact format tile bounds would need to have current behavior to keep the buildings extra bits, but clip landuse to tile extent.

@nvkelso nvkelso added this to the v1.4.0 milestone Apr 27, 2017
@zerebubuth
Copy link
Member

Not the centroid, but the landuse polygon must overlap at least 80% of the building area. The effect is the same, though.

@nvkelso
Copy link
Member Author

nvkelso commented May 17, 2017

Also affects building features especially in relations, here in New York city (red has it, grey doesn't):

screen shot 2017-05-16 at 5 29 33 pm

/cc @sensescape

@nvkelso
Copy link
Member Author

nvkelso commented Jun 27, 2017

Related: #1142 Should we clip buildings completely to tile boundaries?

@nvkelso
Copy link
Member Author

nvkelso commented Jul 27, 2017

Subtask of #1348.

@nvkelso nvkelso mentioned this issue Jul 27, 2017
Closed
@nvkelso nvkelso mentioned this issue Sep 18, 2017
Closed
@nvkelso
Copy link
Member Author

nvkelso commented Sep 18, 2017

This looks to be the root cause of tangrams/tangram-es#1653 building flicker z-fighting in Cinnabar on ES (also kinda observable on JS).

@nvkelso
Copy link
Member Author

nvkelso commented Sep 20, 2017 •
edited
Loading

Discussion from today's Tile sync meeting:

  • Related StackOverlow question
  • To make the intercut 99% accurate instead of 95% we’d need to buffer 3x3 landuse and buildings.
  • Do we do the 3x3 for all layers, for all zooms? Probably not as early work around that made zooms 8 and 12 buffering landuse was very slow…
  • This could all go away if we refactor how we calculate the intercut with RAWR tiles (modulo zoom 10 tile boundaries)

Deferring action on this issue until after basic RAWR tiles are in production.

@nvkelso nvkelso mentioned this issue Dec 1, 2017
Merged
zerebubuth pushed a commit that referenced this issue Dec 5, 2017
Add test for #1226.
7cc4d1b 
This checks that buildings which cross tile boundaries are more likely to be assigned the correct landuse kind. The issue was that, before the change from query-per-layer to query-per-table, we were clipping the landuse to the tile but the building to a 3x3 tile area. This meant that large buildings had much less overlap with landuse polygons, and some would not be assigned a `landuse_kind`.

Now we clip all inputs (except water) to the tile, which solves this problem, but means that the same building in adjacent tiles could be assigned different `landuse_kind`s.

Additionally, it looks like `kind: building_part`s weren't being assigned a `landuse_kind`, although the test now passes, so something we changed has fixed that too.
@nvkelso
Copy link
Member Author

nvkelso commented Apr 30, 2018

Looks like building_part features (#1226 (comment)) still aren't getting the landuse_kind correctly, but the airport examples are so "good enough", with followup in new issue.

@nvkelso nvkelso mentioned this issue Apr 30, 2018
Open
@nvkelso
Copy link
Member Author

nvkelso commented Apr 30, 2018 •
edited
Loading

Verified on prod, filed new issue #1495 for building_part followup.

@nvkelso nvkelso closed this as completed Apr 30, 2018
@ghost ghost removed the send to prod label Apr 30, 2018
@nvkelso nvkelso mentioned this issue Jun 20, 2019
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@zerebubuth zerebubuth

Labels
bug loe medium qa complete
Projects
None yet
Milestone
v1.5.0
Development

No branches or pull requests
2 participants
@zerebubuth @nvkelso