Re: [Talk-us] Requesting to remove stoplines in San Jose
Hi, I've seen the new stoplines in San Jose as well, and the reason they're not useful as-is IMO is because they're not connected to the main road that has the stop line; it's just a floating disconnected way. If they were connected to the road, then it would be more useful to data users, but in their current state, for it to be of use, data users would have to do some additional processing on their end to find out what way it intersects to see where it applies. On 09/19/2017 08:00 AM, Greg Morgan wrote: > On Mon, Sep 18, 2017 at 6:39 PM, Vivek Bansal <3viv...@gmail.com > <mailto:3viv...@gmail.com>> wrote: > > Hey, I noticed pfliers has added lots of unconnected ways w/ > `highway=stopline` all over San Jose. It’s really been cluttering > up our workflows in iD, and now it’s triggering JOSM’s validator > as we’re adding sidewalks. Can we remove them in one big > mechanical edit? Even if the concept is good, they’d have to be > remapped in order to be useful anyways. Maybe they should be a > node along the centerline. Or instead they should be a road_marking. > > This also affects Phoenix, Arizona. > > Here is a link to pfliers history: > https://www.openstreetmap.org/user/pflier/history#map=6/38.882/-117.411 > <https://www.openstreetmap.org/user/pflier/history#map=6/38.882/-117.411> > > Here is pfliers proposal: > http://wiki.openstreetmap.org/wiki/Proposed_features/stop_line > <http://wiki.openstreetmap.org/wiki/Proposed_features/stop_line> > > -3vivekb > > I noticed the new tagging in Phoenix. I sent the Keep Right > maintainer a request that excludes highway=stopline from > "intersections without junctions" checking. I do not believe the sky > is falling. I don't see how these stoplines would have to be > remapped. When we look at the data, all the Phoenix stoplines are > mapped by traffic lights. I am not sure how stoplines would impact > your workflow. Ignore the Josm validation recommendations for these > stoplines. I haven't put a request into Josm maintainers but it is > certainly something that you can do. > > The proposal has something to do with autonomous cars. The stoplines > may just be perfect for the Phoenix area. > http://www.azcentral.com/story/money/business/tech/2017/06/23/arizona-getting-ahead-autonomous-vehicle-industry-stepping-aside-waymo-uber-intel-chevy-bolt/405436001/ > > https://www.keepright.at/report_map.php?zoom=15=33.51322=-112.06043=B0T=0%2C130%2C191%2C192%2C193%2C194%2C195%2C196%2C197%2C198_ign=0_tmpign=0 > > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-us -- Saikrishna Arcot signature.asc Description: OpenPGP digital signature ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Updating tagging of public transport
Part of the problem between the tagging schemes and the rendering is that it's a chicken-and-egg problem; a new tagging scheme is created, but rendering support isn't there yet (partly because it's a somewhat complex structure), so people might not use that scheme. However, if there were many instances of using the newer scheme, then it would be justified for the renderers to add support for that scheme. (On the rendering topic, though, I can confirm that OSM's transport map does support the newer scheme, as does Öpnvkarte, OpenStreetBrowser, OsmAnd, so it's not lacking.) A slightly bigger issue I see is that there are two formats for tagging transportation routes, which will not only require data consumers to code for both formats, but will also make it harder to link a bus route tagged using the newer format be connected to another bus route using the older format. I feel that this should be resolved quickly. On Saturday, November 29, 2014 02:02:01 stevea wrote: it is not clear if the new way is actually better, at least the current data stats show that mappers still prefer the old method, at least for bus stops, as it is simpler (you need just one tag highway=bus_stop instead of two: public_transport=platform and bus=yes, for the same information content), and the new style cannot be rendered on the main map, because of the lack of the bus-key (the rendering db only knows that there is some kind of stop, but it cannot determine if it is a tram stop, a bus stop or whatelse). I wouldn't re-tag, ie. won't remove tags, but you can add the public_transport=* tags if you want to support also this scheme. Is what I hear Martin saying here is that tagging with an old style because it renders AND tagging with a newer syntax that doesn't is OK? (As in, doing two things at once, even if they achieve different, but good and worthy goals, is right?) If so, part of what it says is that syntax is rather distantly connected to rendering. Read that again, as I think it is important. It is about what might be called OSM's transmission. Not everybody understands the full process of how changes in syntax (e.g. voted upon tagging) turn into what we see mapped. There are human consensus processes there, there are coding processes there (including bug fixes, actual writing of render code..) there is quite much more than just that there. It is a complicated moving set of parts. It is let's map bus routes, OK, let's describe better syntax for bus routes, OK (but we don't render that today). Now what? That's a real hit the brakes and think about how to do it better, so discuss moment. As we recognize distance between what people want to see represented in the map (how they tag) with the syntax of doing so (actual tags that get into OSM's data) can we better discuss this? We can and should, I say. Deep, I know. My point is that a person wanting to understand how to influence this is very much helped by understanding it (as much of it as possible, as much of it as we can describe as what we intend...) in the first place. How might one see such moving parts of OSM and how they a) work today? and b) work better in the future as we intend them? It goes deeper than public transport tagging, but that is a good example through this transmission. Look, I know: some of us work on our transmission, and they must. A lot more of us -- and there are many -- are only quite vaguely aware of how it works, or how we might best induce positive change into its workings. We can do better. Good discussion so far, but it seems we are only scratching this surface. SteveA California -- Saikrishna Arcot signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Directional suffixes on roads: yes or no?
Hi Jack, I've been doing an import of addresses and buildings in Fulton County since March (time is limited on my hands, but I'm making progress). Atlanta is, for the most part, done, and I'm currently working in SW Fulton County. Georgia's GIS system has the suffixes in their addresses, so I think it would be beneficial to have the street name with suffix in the main name tag. Howdy, I have a question about how much effort should be put into adding directional suffixes to road names. Many counties around Atlanta have adopted directional suffixes for roads, both in incorporated areas as well as outside city limits. Usually all areas in the county use the same system, with directions denoted NE, SE, NW and SW from some standard point, although some cities tend to ignore the suffixes. Also, signage is inconsistent--some street signs bear the suffix while others on the same street don't. In most cases, the suffix is immaterial, and most people don't use it anyway. Use of it or not won't affect directions most of the time, although I know of a few specific cases where knowing the suffix can be important in finding the right location (is your house 100 Concord Road Southeast or Southwest?). The majority of the Tiger data doesn't include the suffix. So, how much should I worry about the missing suffixes? Should they be included in the main name= tag? Or one of the other *name tags with the unsuffixed name in the name= tag. Because most people don't use the suffix, on some roads I've put the with-suffix name in the name= tag and the unsuffixed one in the short_name= tag, but I'm wondering if I should continue to bother. -jack -- Typos courtesy of fancy auto-spell technology. -- Saikrishna Arcot signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Updating tagging of public transport
Hi all, Not sure if this is the right list or the tagging list is better, but I see some bus and subway routes in the Atlanta area that use the older version of tagging public transport routes. Should these be updated to use the newer version of tagging? -- Saikrishna Arcot signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Teaching with OSM examples (for H.S. STEM class)
Here's a wiki page[1] on the use of OSM in education. There's also a website called LearnOSM[2] which is a general-purpose introduction to OSM. On Thursday, July 24, 2014 03:59:35 PM TC Haddad wrote: Hi all, A friend has asked about resources for a high school teacher who is interested in using OSM in a S.T.E.M. class next fall. In particular examples of how others have used OSM in curriculum would be useful. Any good leads they can follow? Tanya -- Saikrishna Arcot [1] http://wiki.openstreetmap.org/wiki/Education [2] http://learnosm.org/en/ signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USGS Orthoimagery
In this case, should the caching server, the direct (WMS) server, or both be recommended? -- Saikrishna Arcot On Monday, July 07, 2014 01:54:48 PM Ian Dees wrote: Note that the OSM US server tiles and caches the USGS NAIP and High Res Orthos and more information can be found here: http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/United_States/Servers/Imagery[1] ...but the upstream USGS server that used to host this imagery seems to be broken (it's throwing 500's). I'm working on finding someone to talk to about that, but until then we'll have to find something else. On Mon, Jul 7, 2014 at 1:34 PM, Bryan Housel br...@7thposition.com[2] wrote: The project for the common imagery sources is here: https://github.com/osmlab/editor-imagery-index[3] You could enter an issue there to include this source so that it will be available in the various OSM editors. Before including it in the index, they will want to ensure that the source is properly licensed and has a bounding polygon around where the imagery is valid. On Jul 6, 2014, at 9:28 AM, Saikrishna Arcot saiarcot...@gmail.com[4] wrote: Hi all, I noticed that there is a wiki page on the USGS High Resolution Orthoimagery[5], but that the link is outdated. The new resource to use is likely one of these[6] folders. I've looked at the 1-foot imagery, and this seems to be sharper or equal quality than the Bing imagery in at least two areas. In addition, according to this[7] page, only Canada and the border data is marked as View only; all other counties are public domain. Is there any reason this imagery can't be used in OSM, and perhaps even be added as one of the pre-existing imagery sources in JOSM? -- Saikrishna Arcot___Talk-us mailing list Talk-us@openstreetmap.org[8] https://lists.openstreetmap.org/listinfo/talk-us[9] Talk-us@openstreetmap.org[8] https://lists.openstreetmap.org/listinfo/talk-us[9] [1] http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/United_States/Servers/Imagery [2] mailto:br...@7thposition.com [3] https://github.com/osmlab/editor-imagery-index [4] mailto:saiarcot...@gmail.com [5] https://wiki.openstreetmap.org/wiki/USGS_High_Resolution_Orthoimagery [6] http://isse.cr.usgs.gov/ArcGIS/rest/services/Orthoimagery [7] http://cumulus.cr.usgs.gov/listofortho.php [8] mailto:Talk-us@openstreetmap.org [9] https://lists.openstreetmap.org/listinfo/talk-us signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] USGS Orthoimagery
Hi all, I noticed that there is a wiki page on the USGS High Resolution Orthoimagery[1], but that the link is outdated. The new resource to use is likely one of these[2] folders. I've looked at the 1-foot imagery, and this seems to be sharper or equal quality than the Bing imagery in at least two areas. In addition, according to this[3] page, only Canada and the border data is marked as View only; all other counties are public domain. Is there any reason this imagery can't be used in OSM, and perhaps even be added as one of the pre-existing imagery sources in JOSM? -- Saikrishna Arcot [1] https://wiki.openstreetmap.org/wiki/USGS_High_Resolution_Orthoimagery [2] http://isse.cr.usgs.gov/ArcGIS/rest/services/Orthoimagery [3] http://cumulus.cr.usgs.gov/listofortho.php signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] USGS Orthoimagery
Unfortunately, the high-resolution imagery isn't available everywhere in the US yet, and Bing is better than the NAIP. -- Saikrishna Arcot On Sunday, July 06, 2014 08:28:27 AM Saikrishna Arcot wrote: Hi all, I noticed that there is a wiki page on the USGS High Resolution Orthoimagery[1], but that the link is outdated. The new resource to use is likely one of these[2] folders. I've looked at the 1-foot imagery, and this seems to be sharper or equal quality than the Bing imagery in at least two areas. In addition, according to this[3] page, only Canada and the border data is marked as View only; all other counties are public domain. Is there any reason this imagery can't be used in OSM, and perhaps even be added as one of the pre-existing imagery sources in JOSM? -- Saikrishna Arcot [1] https://wiki.openstreetmap.org/wiki/USGS_High_Resolution_Orthoimagery [2] http://isse.cr.usgs.gov/ArcGIS/rest/services/Orthoimagery [3] http://cumulus.cr.usgs.gov/listofortho.php signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Marking of turn:lanes in the cases of an implied right turn
Hi all, I'm working on adding turn:lanes to roads at traffic lights, and am also working on adding support for reading turn:lanes in OsmAnd (Android). I'm wondering on how to mark turn:lanes in the case of an implied right turn. For example, let's say that you're approaching a traffic light and there are four lanes heading in your direction. The left-most (1st) lane is indicated as a left-only lane. The second, third, and fourth lanes are unmarked (therefore, it would be none for these lanes). This would mean that the second and third lanes are straight-only, and the fourth lane is straight and right (let's assume a right-turn is allowed here). In this scenario, would this be marked as left|none|none|none or left|none|none|through;right, and if it's the former, would data consumers have to infer from the turn restrictions and see that a right turn is allowed there? -- Saikrishna Arcot signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Nominatim in CDP
On Wednesday, June 11, 2014 01:19:10 PM Clifford Snow wrote: I think that Ian is correct that Nominatim is failing to find the address because of the CDP boundary. But does that make Nominatim wrong or the admin boundary? My expectation is that Nominatim would use the CDP (or the city region it's located in) if there is no addr:city, and either 1. would allow either the CDP and addr:city when addr:city is present, or 2. use only the addr:city if it is present. The first option would account for the case where the addr:city is incorrect (for whatever reason), but someone searching for the address could either use addr:city or the CDP name. -- Saikrishna Arcot signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Sidewalks as footpaths
Duplication of data, possibly? Regarding the detection of the nearest street, the risk here is at the intersection, where the sidewalk might be attributed to the other street. -- Saikrishna Arcot On Thursday, May 08, 2014 07:02:16 PM Paul Johnson wrote: I'm trying to work out how using name=* on the sidewalks isn't the easiest, most obvious answer. On Thu, May 8, 2014 at 6:09 PM, Clifford Snow cliff...@snowandsnow.us[1] wrote: On Thu, May 8, 2014 at 1:55 PM, Chris Lawrence lordsu...@gmail.com[2] wrote: Audio routing (so you can put your phone in your pocket and listen toheadphones) and audio/braille descriptions for the disabled would bethe most obvious use cases for names. In fact, I'd imagine thedisabled are a likely important audience for OSM since Google doesn'tgo out of its way to provide non-visual interfaces to Google Maps asfar as I know. Good point. Other than using relations, I wonder if a search for the nearest street would provide a clue to the router? Not as exact as having either a named way or a relationship. Clifford -- @osm_seattle osm_seattle.snowandsnow.us[3] OpenStreetMap: Maps with a human touch Talk-us@openstreetmap.org[4] https://lists.openstreetmap.org/listinfo/talk-us[5] [1] mailto:cliff...@snowandsnow.us [2] mailto:lordsu...@gmail.com [3] http://osm_seattle.snowandsnow.us [4] mailto:Talk-us@openstreetmap.org [5] https://lists.openstreetmap.org/listinfo/talk-us signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Roads closed for maintenance/construction
Hi all, Is there a specific tag for roads that have already been constructed, but are closed either for maintenance or construction of something else? On my university campus, a short stretch of a road has been closed for the construction of a new steam pipe under the road. I'm currently using highway=contruction and construction=tertiary (the road in question is a tertiary road). -- Saikrishna Arcot signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] OSM Inspector and streets with E/N/S/W in their name
I vote for keeping this check in place (i.e. an exact match of the street name), because there are some places (in California, I think) where the prefix/suffix changes from North to West as you are driving down the road, and I believe it's important that we distinguish between the two. -- Saikrishna Arcot On Tuesday, April 29, 2014 09:05:41 PM Frederik Ramm wrote: I wonder: Is OSMI correct in flagging this for correction, or is this something that nobody really cares about and that should not be highlighted? I.e. should we, in OSMI, drop the E/N/S/W prefix of street names before trying to find a match? signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] building=house vs building=detached
Hi all, What the difference between building=house and building=detached? My understanding is that a house that has two addresses (and two familes) would be considered as building=house, whereas if there is only one address and one family, then it is building=detached. -- Saikrishna Arcot signature.asc Description: This is a digitally signed message part. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Why we really don't get new users
JOSM also has a plugin that provides a UI for entering opening_hours. That being said, this UI is in JOSM, but new users are probably going to use iD since it's easy to use and is right there (quick availability). -- Saikrishna Arcot On Monday, March 17, 2014 01:20:12 PM Ian Dees wrote: Such a thing already mostly exists in the preset system. iD has a fairly extensive and growing set of presets that I encourage you to try (it follows the example you give). JOSM also has a preset system, but it's not nearly as obvious or as complete (at least for the mapping I do). You access it by hitting F3 on your keyboard when mapping. On Mon, Mar 17, 2014 at 1:17 PM, o...@charles.derkarl.org[1] wrote: Talk-us@openstreetmap.org[2] https://lists.openstreetmap.org/listinfo/talk-us[3] [1] mailto:o...@charles.derkarl.org [2] mailto:Talk-us@openstreetmap.org [3] https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports-us] Address Data Import for Fulton County, Georgia
Serge, On 01/07/2014 05:08 PM, Serge Wroclawski wrote: Saikrishna, I understand your enthusiasm for wanting to have address points for Fulton County, Georgia, but before you start uploading, we need to examine a few issues: 1. What is the license for this data? I was unable to download the data that was linked to from the wiki page. You have a statement saying that's it's OSM compatible, but the specifics are important- and in this case the county seems to require registration. They can do so, but then you (or someone else) need to legally be able to host the data- we don't want to require OSMers to sign up to evaluate this data. The data is in the public domain. I've edited the wiki page to specify this. I can upload the data elsewhere and make it available for download. 2. Address Points The second concern I have is that this is just a plain raw address dataset. We've discussed those before and I think it's safe to say that they're somewhat controversial. They're better than nothing, but often very difficult to work with, and when we have building footprints, there's going to be enormous work to conflate them. It would be much better if the conflation step was done before upload. Do you think it's possible to get building footprint data from the government? I think I saw another data set that had building footprint data, but I need to see what the data looks like and if the licensing is fine. 3. The Conversion There are tags in the dataset which do not make any sense, such as STATUS=A and FILEVER, none of the tags have been lowercased, none of the addresses have been name expanded. All of this needs to be cleaned up and corrected before the data could be added to OSM. Those tags are in the dataset itself; those exact tags won't be present in OSM. The tags that will be used in OSM, as outlined in the Conversion section, are addr:housenumber, addr:street, and possibly addr:city. The casing and the name expansion will be done in the conversion program. 4. There's no mention in your wiki page about updates and any update process I was initially under the impression that the addresses didn't have an ID that could be used in updates. Looking at the data again, there is an immutable GEO_OID field that represents a unique, internal ID. This, perhaps, could be used for updates. That being said, I was told that later versions of the address data are under different licenses and so might not be possible to import into OSM. (As it is, this is the latest version on the clearinghouse website). You have a good start here, but you have a lot to do before the import is ready to officially propose. - Serge Saikrishna Arcot ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports-us] Address Data Import for Fulton County, Georgia
Regarding the public domain licensing, the PDF file provided with the data states Freely use, copy and distribute as long as credit is given. On the metadata information on the download page, it states that there are no access constraints, but the use constraint just states that there may be errors in the data and Fulton County is not responsible for such errors (exact wording is DATA Disclaimer: Fulton County makes known to user, and user acknowledges notice by Fulton County that this Data contains known errors and inconsistencies. Fulton County in no way ensures, represents or warrants the accuracy and/or reliabilibity for any purpose.). My custom application source code is up at https://github.com/saiarcot895/osm-fulton-address, which is linked to on the wiki page. Currently, the application takes in a BBox and uses the Overpass API to download address info and streets, but I'm considering just getting the full extract for that area. In addition, the application takes into account all existing /valid/ addresses (has an addr:street and the addr:street matches the street name) and skips importing those addresses, expands abbreviations in the street name, and corrects the casing to match those in OSM. At the moment, the position of the address data point isn't checked for reasonableness, but I'm planning on including that in the application itself. I wasn't aware that ogr2osm could filter the tags at that stage itself. In this case, I'll create a translations file to filter the tags and create a new converted OSM file. Regarding updates, I initially didn't plan on having this be updated with newer versions of the data, since at that time, I wasn't aware that there was a usable ID. Now, if there is an ID tag in the final OSM data, address updates /may/ be possible depending on whether a new ID is created for any address change (Carl?). What may be easier is just to import any new addresses that are not already in OSM. Regarding the street name mismatches, this data is from 2005 (although I suspect there may be some updates from 2008, since some of the dates in the data are from 2008), and if I read correctly, the TIGER data here is from 2006. Therefore, it is more likely that the street names in OSM are correct. That being said, there is, I believe, at least one street in existing OSM data that is not fully expanded. For this road, it might be easier to fix this outside of the import. Regarding the conflation issue, the main issue I see is address nodes being added on top of existing buildings. For this, I could add in code to determine if the node is inside a building and, if so, merge the address data, although it looks like the addressmerge tool already does this. If an existing node, way (building), or relation already has an address that is being imported, then the address will be skipped from the import. For the upload process itself, I'm considering using either the Task Manager or Google spreadsheet. I intend to have only the addition of addresses as part of the import process and won't be fixing anything else. Saikrishna Arcot On 01/07/2014 09:03 PM, Jason Remillard wrote: Hi Saikrishna, I agree with Serge, we need to be 100% sure the license situation is straight. Often the data providers say the data is in the public domain, but in fact, isn't. Some workflow suggestions - In general, you should try to script the workflow from start to finish. You will be running it many, many times while debugging the import. The splitting, conversion to OSM, and possibly conflation to OSM. Many of us on the list would like to look at the code to help with the QA. - ogr2osm allows you to specify an python file on the command line that can be used to translate the shape file columns to osm tags. I would look to get things as close as possible with it first. If needed, then do the rest with the QT program. - You should take a look at the addressmerge, https://github.com/pnorman/addressmerge . Paul's code works without buildings, it could be a good match. - Subscribe to the ny city address import on git hub, review the many issues they needed to work through. I would also pick a tile from the ny city import and run the import yourself. You don't need to do it the same way, but I think it would be useful to be familiar with what they are doing. - If you have code to detect differences between the address street name and the OSM name, you should pull them out and resolve the differences by hand. Rather than just skipping them. It might be an opportunity to improve OSM street names. Things that need to be done that are missing from your wiiki - how the uploading is going to happen. If multiple people are going to do it, they need to be coordinated. Task manager, google spread sheet, wiki, etc. - QA on the data (proper removal of street abbreviations, positional accuracy). - Are you going to fix other things when uploading. - You should try to contact any local
Re: [Talk-us] Separate relations for each direction of US State highways.
I, personally, am in favor of using the colon rather than the semicolon, for the reasons Martijn outlined a few emails back. Saikrishna Arcot On Thu 19 Dec 2013 03:23:53 AM IST, James Mast wrote: I have no problems going with either : or ; for the separator for unsigned segments of highways in the role area. What does everybody else think? As this shouldn't be decided by just two people. We do still need the consensuses of [talk-us] before any mass changing of relations happen. Later tonight if I have time I'll do up an example route for this (US-19 Truck here in Pittsburgh) so everybody can see this in action at least and then we can link an example to the wiki page. The reason I selected the route above is because not only is it a short route, it does have it's middle segment hidden while on Interstates. Plus I have tons of experience with it having traveled it a lot in my life. -James ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Importing addresses from TIGER
Ah, ok. I wasn't aware that Nominatim uses the address ranges as a fallback. I typically use the data exports offline in OsmAnd, and so don't see the address ranges from the TIGER data. Does the Public Domain status mean that they can be used and imported into OpenStreetMap? I might start soon on adding addresses in Atlanta. Saikrishna Arcot On Thu 12 Dec 2013 11:50:25 AM EST, Ian Dees wrote: On Thu, Dec 12, 2013 at 10:39 AM, Saikrishna Arcot saiarcot...@gmail.com mailto:saiarcot...@gmail.com wrote: Hi all, I believe TIGER has some data on addresses; more specifically, it has address ranges for each block (roughly). Currently, the US has limited address info in OSM. Some cities have many businesses and POIs with address data, so the data in the region might be comparable with other mapping services. Is it possible to have a bot/script that matches up TIGER roads with OSM roads and then add in address ranges? That way, there is at least /some/ info about addresses in OSM. The default OSM geocoder (nominatim) uses TIGER address ranges as a fallback when it can't find data in OSM, so we're already using TIGER data. It might be interesting to convert the address ranges to address nodes and then let local mappers line them up with houses, but that wouldn't be very precise. Another option is to spend time to collect address data from local municipalities and work on methodically importing them. I started this process and have collected a couple hundred address datasets here: https://docs.google.com/spreadsheet/ccc?key=0AsVnlPsfrhUIdEVZTzVFalFYYnlvTkc0R05wcUpsWVE -Ian ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Importing addresses from TIGER
Thank you Carl. The earliest I'll have time to do any importing is on Sunday. Regardless, I'll have to contact imports first to get an all-clear. Saikrishna Arcot On Thu 12 Dec 2013 06:18:22 PM EST, Carl Anderson wrote: Frederik, I believe that Mike N.'s quote was about importing TIGER data. Saikrishna's quote was about the data Ian Dees spreadsheet for the City of Atlanta (Fulton County). A different dataset entirely. Saikrishna, If you want to import the Fulton County/City of Atlanta address points I am willing to help. C. On Thu, Dec 12, 2013 at 6:06 PM, Frederik Ramm frede...@remote.org wrote: Hi, On 12.12.2013 18:04, Saikrishna Arcot wrote: Does the Public Domain status mean that they can be used and imported into OpenStreetMap? I might start soon on adding addresses in Atlanta. They *could* legally be imported but, quoting from this very thread: Mike N.: They are not acceptable for import into OSM for quality reasons. Ian Dees: you still most definitely need to go through the import process. Where the import process means that you'll have to make a plan and discuss that - you can't just go ahead and import. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Importing addresses from TIGER
Ah, ok. I'll be on the other side of the world on Sunday (actually, starting Saturday) and won't be back until January 6, so I doubt we can have a direct conversation till then. I will be available through email. Saikrishna Arcot On Thu 12 Dec 2013 08:08:51 PM EST, Carl Anderson wrote: Saikrishna, There is a process that will need to be followed. It starts with creating a wiki page for the import and describing how the import is intended to go. If you have time on Sunday we can get started on the plan. C. On Dec 12, 2013 7:59 PM, Saikrishna Arcot saiarcot...@gmail.com mailto:saiarcot...@gmail.com wrote: Thank you Carl. The earliest I'll have time to do any importing is on Sunday. Regardless, I'll have to contact imports first to get an all-clear. Saikrishna Arcot On Thu 12 Dec 2013 06:18:22 PM EST, Carl Anderson wrote: Frederik, I believe that Mike N.'s quote was about importing TIGER data. Saikrishna's quote was about the data Ian Dees spreadsheet for the City of Atlanta (Fulton County). A different dataset entirely. Saikrishna, If you want to import the Fulton County/City of Atlanta address points I am willing to help. C. On Thu, Dec 12, 2013 at 6:06 PM, Frederik Ramm frede...@remote.org mailto:frede...@remote.org wrote: Hi, On 12.12.2013 18:04, Saikrishna Arcot wrote: Does the Public Domain status mean that they can be used and imported into OpenStreetMap? I might start soon on adding addresses in Atlanta. They *could* legally be imported but, quoting from this very thread: Mike N.: They are not acceptable for import into OSM for quality reasons. Ian Dees: you still most definitely need to go through the import process. Where the import process means that you'll have to make a plan and discuss that - you can't just go ahead and import. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org mailto:frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-us mailing list Talk-us@openstreetmap.org mailto:Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org mailto:Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [josm-dev] Relation editor support for north/south and east/west similar to forward/backward
The same applies for I-35 in the DFW area; I-35E runs through Dallas while I-35W runs through Fort Worth. Saikrishna Arcot On Wed 27 Nov 2013 03:56:51 PM EST, Richard Welty wrote: On 11/27/13 2:46 PM, John F. Eldredge wrote: You also have compass-point letters used to distinguish between branches of the same route. For example, US 31 runs north/south. A portion of it branches off as US 31W, which runs roughly parallel, some miles westward of US 31, and eventually merges back into it. in the Hudson Valley of NY, we have US 9/US 9W, which behave similarly; 9 is on the east side of the river south of Albany, and 9W is on the west side. (on top of that, NYS has a thicket of state routes which are spurs and loops off of 9/9W, e.g. NY 9A, 9B, ... 9H, 9J... mapping in NY is fun. whee!) richard ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Freeway directions
Just to add, three-digit routes tend to be either regional or be loop-shaped, where the designated direction changes. Saikrishna Arcot On Thu 17 Oct 2013 03:40:07 PM EDT, Ian Dees wrote: On Thu, Oct 17, 2013 at 2:31 PM, Martijn van Exel m...@rtijn.org mailto:m...@rtijn.org wrote: Yea, I realized that as well. There's even a section of I-80 / I-580 in Berkeley, CA where the directionality of I-80 and I-580 is opposite... http://goo.gl/maps/XROab (The actual compass direction is more like N/S on that stretch.) I don't know if there's a definitive reference for the 'official' directionality of the freeways? I'm sure someone will pipe up with more authoritative answers, but as far as I know interstates can only be east/west or north/south. North/south roads are odd numbered and east/west are even. ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Complex intersection mapping
Just to check, in the case of number 3, if a traffic signal was present at the above direction, would there have to be two traffic signal for the up-and-down two-way road? Saikrishna Arcot On Tue 15 Oct 2013 03:14:13 PM EDT, Tod Fitch wrote: People will map as they see fit and, as pointed out elsewhere in this thread, it is not possible to correct all instances of all variations. That said, the wiki is replete with guidance on preferred tagging for various features so it is not out of line to work toward a preferred method of mapping complex intersections. The data consumers will, of course, need to handle as many of the non-preferred variations as they can. That said, it seems to me that the tagging of intersections where a way splits into dual carriage ways at an intersection can be broken into three general approaches. Please forgive the ASCII art: 1. Splitting/combining the way before the intersection. -+ 2. Splitting/combining the way in the intersection. == 3. Splitting/combining the way after the intersection. ==+= (Before and after based in this case on approaching the intersection from the dual carriageway.) In my mapping I have generally followed number 2 as it just seemed natural to me. But one thing that has been bothering me since I started adding traffic signals is the requirement of putting a traffic_signal:direction=* tag on bidirectional ways leading into an intersection. The syntax and semantics of that seems awkward to me. And I see proposals for putting things like yield (give way) and stop signs into relations to show which travel directions the sign applies to which is a similar problem with a different proposed solution. I doubt that we'd be able to do away with all need for the traffic signal direction tagging or for turn restriction style relations for stop and yield signs, but if we have a convention that ways are split outside of an intersection (number 3 above) it would reduce the need for those types of additional tagging as the traffic control sign or sign would be on a one way carriage way. Tod -- Sent from my mobile device. Please excuse my brevity. stevea stevea...@softworkers.com wrote: I just want to emphasize that there are (at least) two separate but related issues here: 1) Whether the before or after style is preferred or more correct, 2) What a routing algorithm (potentially yet-to-be-coded or now-actually coded) does with either or both. Regarding 1), it appears that we have proponents for both styles. In OSM, I submit that's just gonna happen. While consensus is a beautiful thing, it is not always perfectly achievable. I don't believe it (entirely) reasonable to, say, have a bot go through thousands of intersections and make them one flavor or another, simply to make a routing algorithm more happy or easier/faster to complete. Maybe a case could be made for that, but I'd like to hear it. (I think of it as a BIG maybe). Regarding 2), be smart about (algorithmically handle) both flavors of intersections. Or even more. Th is is a tip of the iceberg problem that likely requires more research and a classification into more than simply two flavors of intersections. I think it possible that given the universe of possibilities, there are smart and clever ways to apply a routing algorithm: this is just geometry and computer science after all (points, vertices, and an executive that rides along the geometry which probes around, backs out, and yields results). Research the entirety of the problem domain, invest (substantially, if necessary) in the algorithm to handle most/all cases, and all can be well. While it is fine to discuss better methods (note that is plural) of creating complex intersection geometry, I find it stifling to do so in the context of for a particular routing algorithm. That leans heavily towards coding for the routing algorithm, and I think we've learned that such coding make the underlyin g data not all they can be (i.e. well-formed and as correct as we are able to observe and enter them). I seem to be echoing what Minh said near the end of his reply: handle both. (or more). Good discussion. SteveA California Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Complex intersection mapping
To expand on the point of having both methods used, starting with the multiple intersection points method, what if all four intersection points were under a relation of a group of intersections, and the number of lanes on each way was marked? That way, routing algorithms could convert from the visually-friendly method to the individual lane and single intersection point method. Saikrishna Arcot On Mon 14 Oct 2013 05:28:28 PM EDT, Martin Koppenhoefer wrote: 2013/10/14 stevea stevea...@softworkers.com mailto:stevea...@softworkers.com Hi Martijn: one thing wrong I do see at this particular intersection are extraneous nodes with highway=crossing tags: two extra ones on the (northerly) east-west ped-path and one extra one each of the (westerly and easterly) north-south ped-paths. A fairly minor error in the context of your larger question. +1, and another thing: the street coming from the right should not be expanded to a dual carriageway at the point where your colleague has done it, but rather at the latest possible point (i.e. at the first insection with the N-S-road) if doing it this way. cheers, Martin ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
