Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Not merge addresses to polygons? #15

lxbarth opened this Issue Oct 10, 2013 · 19 comments


None yet
8 participants

lxbarth commented Oct 10, 2013

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 commented Oct 10, 2013

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 commented Oct 10, 2013

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

emacsen commented Oct 10, 2013

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 commented Oct 10, 2013

Yes, just agreeing with you @emacsen


ebarry commented Oct 10, 2013

+1 sounds good.


lxbarth commented Oct 12, 2013

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


lxbarth commented Oct 12, 2013

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 Oct 12, 2013


pnorman commented Oct 12, 2013

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 Oct 12, 2013


lxbarth commented Oct 12, 2013

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 commented Oct 12, 2013

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 commented Oct 12, 2013

I'll write this up for the imports list.

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

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 commented Oct 15, 2013

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.

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).

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 commented Oct 17, 2013

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 commented Oct 17, 2013


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 commented Oct 22, 2013

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 Oct 22, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment