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

Gaps between buildings #19

Open
RobJN opened this issue May 12, 2014 · 7 comments
Open

Gaps between buildings #19

RobJN opened this issue May 12, 2014 · 7 comments

Comments

@RobJN
Copy link
Contributor

RobJN commented May 12, 2014

The vectorizer traces around the inside of the building wall. As such on a terraced street you end up with a small gap between all buildings. I am after some ideas of how to fix this:

  • is it something that can be added to this tool (e.g. some sort of small Buffer but without overlapping); or
  • would it be best to process this outside of the tool?
@hjanetzek
Copy link

Why are you not using the outlines for the final geometry? Just an idea - I havent actually looked into or tried the implementation yet:
Vectorize the outlines (potrace.sourceforge.net does a good job at this). Split lines at all intersections. Use the split lines for a contrained triangulation. Then assign the triangles to the building 'blob' with the greastest overlap. Might work :)

@mgiraldo
Copy link
Contributor

@RobJN fits in the tool indeed!

ideally, the vectorizer would ensure adjacency of buildings (within a certain threshold) but I had little time and ability for this. I have found some work on this area [1] but no implemented code.

[1] http://www.sciencedirect.com/science/article/pii/S0097849311000033

On May 12, 2014, at 16:32, RobJN notifications@github.com wrote:

The vectorizer traces around the inside of the building wall. As such on a terraced street you end up with a small gap between all buildings. I am after some ideas of how to fix this:

is it something that can be added to this tool (e.g. some sort of small Buffer but without overlapping); or
would it be best to process this outside of the tool?

Reply to this email directly or view it on GitHub.

@mgiraldo
Copy link
Contributor

@hjanetzek that's a different approach to the same problem (from lines vs from fills). we did the latter approach. the line approach could be interesting to pursue.

On May 12, 2014, at 16:49, Hannes Janetzek notifications@github.com wrote:

Why are not using the outlines for the final geometry? Just an idea - I havent actually looked into or tried the implementation yet:
Vectorize the outlines (potrace.sourceforge.net does a good job at this). Split lines at all intersections. Use the split lines for a contrained triangulation. Then assign the triangles to the building 'blob' with the greastest overlap. Might work :)


Reply to this email directly or view it on GitHub.

@RobJN
Copy link
Contributor Author

RobJN commented May 25, 2014

I've posted a question on StackExchange about this at http://gis.stackexchange.com/questions/97909/how-to-extract-vectors-from-a-map (which includes a link to my example files in Google Drive).

No suggestions so far, but I just stumbled across the Strava Slide work of @paulmach which I've had open in a tab since State of the Map US 2014. Perhaps we could see if we could use that (substituting GPS data for pixel "blackness" in the unprocessed geotif). This would bring the terrace buildings together in most cases - any remaining small gaps would just be "slivers" that can be solved using existing GIS tools. I'll contact Paul in the morning.

http://labs.strava.com/slide/

p.s. I've now got a PDF copy of that research paper. They suffer the same problem of gaps between buildings and attempt to solve it by assessing points pairwise. If they are sufficiently close then they are both moved to the midpoint between then (thus snapping the corner of the building together). They note that this would need further developing to deal with 4 buildings that share a corner (i.e. a cross "+" in the original map).

@RobJN RobJN closed this as completed May 25, 2014
@RobJN RobJN reopened this May 25, 2014
@mgiraldo
Copy link
Contributor

I leafed through the paper but since I didn't see any code I decided to ignore it... interesting to see they still did not manage to solve all of it... it is a hard problem indeed

@mgiraldo
Copy link
Contributor

Re: Strava

I think this assumes we know the convergence line (the green line in the example). This line could be inferred from the black lines in the original map. A quick search for such a process resulted in this paper. Could be an option. Worth thinking about...

@RobJN
Copy link
Contributor Author

RobJN commented May 28, 2014

Re: Strava

Well the green line is the line at the bottom of the valley in the "surface" plot [1]. It's what the Slide tool outputs. Strava are currently using their GPS data to create the surface plots, but I think we could use pixel "blackness" in the original map scan.

So essentially we create initial building polygons using the NYPL tool. Create a surface plot based on pixel blackness, and then use Strava's tool to "slide" the building polygon down the valley of the surface plot. Finally we load it into the crowd sourcing website to verify and correct any errors.

Thanks for the link - I'll take a look.

[1] http://labs.strava.com/slide/surface-small.jpg

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

No branches or pull requests

3 participants