You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SF official streetline dataset (and census/tigerline to which AFAICT it is identical) includes centerlines for each direction of streets divided by medians, and then those centerlines are joined into one where the median ceases at intersections. This means that just using the direction of the street centerline to orient labels leads to weird geometries at large street intersections (such as in the default San Jose/Guerrero location.)
Maybe sanest thing is to do is generate a separate file with just the intersections, names, and orientations of streets. It should also be a lot easier to simplify this than the curbline datasets which also lead to those overly complex geometries at rounded curbs and medians.
The text was updated successfully, but these errors were encountered:
SF official streetline dataset (and census/tigerline to which AFAICT it is identical) includes centerlines for each direction of streets divided by medians, and then those centerlines are joined into one where the median ceases at intersections. This means that just using the direction of the street centerline to orient labels leads to weird geometries at large street intersections (such as in the default San Jose/Guerrero location.)
Generally in order to align the unit vectors of street labels with streets a lot more checks need to be done in the function here: https://github.com/bvmou/cityedit/blob/master/mapcouchapp/templates/editor.html#L294
Maybe sanest thing is to do is generate a separate file with just the intersections, names, and orientations of streets. It should also be a lot easier to simplify this than the curbline datasets which also lead to those overly complex geometries at rounded curbs and medians.
The text was updated successfully, but these errors were encountered: