Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Not merge addresses to polygons? #15

Closed
lxbarth opened this Issue · 19 comments

8 participants

@lxbarth
Owner

Colin Reilly told me DoITT has tried to place address points as close as possible to the actual entrance to a building.

Right now we're merging addresses into buildings where possible, losing any address location information.

Should we stop merging addresses into buildings?

screen shot 2013-10-10 at 4 31 44 pm

@emacsen
Owner

address on way is pretty normal. If you are worried about losing data, we could tag them as entrances (http://wiki.openstreetmap.org/wiki/Entrance)

In the case of multiple entrances, we could entrance=yes to the node, if that's consistent.

But I'm open to discussion.

@ebrelsford
Owner

I'd be worried about losing useful data, so maybe entrance is the way to go.

@emacsen
Owner

Eric, this is why I suggest that if we are storing the nodes, we store them as entrances=yes

I'd be worried about losing data in other ways. This also lets people add service entrances more easily

@ebrelsford
Owner

Yes, just agreeing with you @emacsen

@ebarry
Owner

+1 sounds good.

@lxbarth
Owner

Yeah, let's not merge the addresses in. Reexporting.

@lxbarth
Owner

Reexported, this is what our OSM districts look like right now:

screen shot 2013-10-12 at 10 45 49 am

@lxbarth lxbarth closed this
@pnorman
Owner

A change like this needs to go back to imports@ for consultation, if you want to do imports before that you need to do them as you consulted on.

@pnorman pnorman reopened this
@lxbarth
Owner

Note the status quo now is:

  • addresses are always represented as nodes (never as attributes on buildings)
  • addresses are not tagged as entrances

This way we preserve location information.

@pnorman
Owner

addresses are always represented as nodes (never as attributes on buildings)

Well, the resulting files shouldn't be imported right now if this is true

@lxbarth
Owner

I'll write this up for the imports list.

For now the import is paused http://tasks.openstreetmap.us/job/2

@jremillard

Just putting everything in separate nodes is not wrong, but it might not be as precise as what is really in the data.

In the screen shot, some of the address points are right in the middle of the building. Some of them are clearly entrances, lined up on the edges of the building outline. If you 100% knew if the address point was also an entrance, it would be cool to merge the address point into a node shared by the building, and mark it as an entrance.

Is there something in the source data that indicates that the address point is a door or not?

@stevegc

The PAD file from NYC Dept of City Planning is the definitive source relating addresses to buildings (BINs) as well as tax parcels (BBLs). http://www.nyc.gov/html/dcp/html/bytes/applbyte.shtml#pad The PAD file is not georeferenced (like the address point file from DoITT), but it provides all the addresses that correspond to each building. Just fyi.

@colinreilly

The DoITT address points were originally based on PAD with additional field verification and a shift in purpose. PAD includes many theoretical addresses whereas the address points focus on what exists in reality. For example, using BIN 1079043 below is what each data set includes. This should illustrate the difference.
PAD has 41-65 Maiden Ln; 85-99 & 101-105 William St, and 50-68 John St. These represent the rages assigned to each street frontage by the borough president. DoITT Address points have 59 Maiden Ln and 60 & 66 John St. These are the only addresses used for that building. Both are correct they just serve different purposes.

Placement is near the entrance where possible (ie, entrance is visible from available imagery as we do not have staff for field work). As such I would not denote them as entrances.

Exporting to shapefile truncates field names to 8 characters. In the data the house number attributes are as follows:

HOUSE_NUMBER - Represents the numberic portion of the address. Also represents the low portion of a range - see hyphen type for explanation.
HOUSE_NUMBER_SUFFIX - Characters and fractions appended to the house number. Often used for infill addresses.
HOUSE_NUMBER_RANGE - High number for Queens-style and building ranges.
HYPHEN_TYPE - R= building range, Q= Queens (hyphenated); X = range of queens style (building range composed of hyphenated addresses; N= no hyphen; U = unit (not used).

@colinreilly

HYPHEN_TYPE = X are under review.

I have staff working on improving the metadata. Next export to open data will have more complete metadata.

@pnorman
Owner

PAD includes many theoretical addresses whereas the address points focus on what exists in reality.

We probably don't want to go from buildings to PAD then, although you could use the PAD file to find misformatted addresses in OSM

@emacsen
Owner

Colin,

Thank you very much for your input. Without it, we're working purely with speculation.

I think that once we're refining the data (probably in a year anyway- since this import will take a long time), we can examine these address points on single address buildings as entrances, or at least present them as an option.

I think Paul has said it all regarding the current situation.

@lxbarth
Owner

This is a tough question, but let's go with broad convention in OSM for now, especially as we can't say that the location of an address is the entrance of the building in all cases. We've updated scripts and we're merging addresses to buildings where possible.

@lxbarth lxbarth closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.