Re: [Talk-us] Time to retire ref= on ways?
Apollinaris Schoell wrote: > fully agree we should keep this target in mind. > But first we have to resolve a long list of problems first. > there shouldn't be any time when the renderer or other data consumers will be > left with completely broken data because step2 was done before step1 > osm doesn't have any way of enforcing anything we need to be careful to kill > the dinosaur too early > > > 1) route relation tagging has to be defined, agreed and accepted widely. > currently it's a mess. > 2) rendering, garmin maps, any other major data consumer must be updated to > use relations. currently none does to my knowledge. no wonder since 1) isn't > done 1) appears to be done based on observations around the Oregon/Washington area (including relations that travel across other states). Not sure what's holding up 2), since it's clearly not 1) at this point. > 3) define a grace period after 1,2) is done and consider to delete them after > that. No need to do it because any consumer understanding relations the right > way will push down the relation ref and ignore the way ref. It's been at least a year. How much more time do you need? ;o) ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Time to retire ref= on ways?
Chris Hunter wrote: > Definitely a good idea! My only concern would be to make sure the way is > correctly included in the route relationship(s) before deleting the ref=* > tags. A valid concern, and one in which I believe human intervention is required. > Maybe a bot could do this? I'd prefer human intervention wherever possible. Forgive me for being gunshy after the low quality of the bot edits made during the GNIS and TIGER imports. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Time to retire ref= on ways?
Apollinaris Schoell wrote: > > On 8 Mar 2010, at 10:10 , Richard Welty wrote: > >> On 3/8/10 12:52 PM, Apollinaris Schoell wrote: >>> fully agree we should keep this target in mind. >>> But first we have to resolve a long list of problems first. >>> there shouldn't be any time when the renderer or other data consumers will >>> be left with completely broken data because step2 was done before step1 >>> osm doesn't have any way of enforcing anything we need to be careful to >>> kill the dinosaur too early >>> >>> >>> 1) route relation tagging has to be defined, agreed and accepted widely. >>> currently it's a mess. >>> >> agree on straightening out tagging. the ref tag on a route relation is a >> free-for-all right now, and there >> is not a clear concensus on the network tag either. on the other hand, if >> symbol is there and points at >> an appropriate svg file for a shield (which it generally does) then >> rendering may be straightforward. > > shield rendering is a wish for many for a long time. but so far no one came > up with a practical solution. also there is no consensus if this will ever go > upstream to Mapnik because it will break the unified global rendering on > osm.org But that shouldn't stop anyone to setup a US specific rendering with > shields. Richard Welte came up with the network naming scheme that should make this possible; it's already in live usage throughout much of Cascadia. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Time to retire ref= on ways?
On 8 Mar 2010, at 10:10 , Richard Welty wrote: > On 3/8/10 12:52 PM, Apollinaris Schoell wrote: >> fully agree we should keep this target in mind. >> But first we have to resolve a long list of problems first. >> there shouldn't be any time when the renderer or other data consumers will >> be left with completely broken data because step2 was done before step1 >> osm doesn't have any way of enforcing anything we need to be careful to kill >> the dinosaur too early >> >> >> 1) route relation tagging has to be defined, agreed and accepted widely. >> currently it's a mess. >> > agree on straightening out tagging. the ref tag on a route relation is a > free-for-all right now, and there > is not a clear concensus on the network tag either. on the other hand, if > symbol is there and points at > an appropriate svg file for a shield (which it generally does) then rendering > may be straightforward. shield rendering is a wish for many for a long time. but so far no one came up with a practical solution. also there is no consensus if this will ever go upstream to Mapnik because it will break the unified global rendering on osm.org But that shouldn't stop anyone to setup a US specific rendering with shields. >> 2) rendering, garmin maps, any other major data consumer must be updated to >> use relations. currently none does to my knowledge. no wonder since 1) isn't >> done >> 3) define a grace period after 1,2) is done and consider to delete them >> after that. No need to do it because any consumer understanding relations >> the right way will push down the relation ref and ignore the way ref. >> > we probably want a transitional algorithm stated for renderers. many > relations are built, > but many are still missing. a use the relation if it exists and meets a set > of requirements, > else fall back on the ref tags on the ways sort of affair. yes fallback is needed and is default in Mapnik for multipolygons vs tags on simple area polygons. Shouldn't be difficult to do the same for route relations > > richard > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Time to retire ref= on ways?
On 3/8/10 12:52 PM, Apollinaris Schoell wrote: > fully agree we should keep this target in mind. > But first we have to resolve a long list of problems first. > there shouldn't be any time when the renderer or other data consumers will be > left with completely broken data because step2 was done before step1 > osm doesn't have any way of enforcing anything we need to be careful to kill > the dinosaur too early > > > 1) route relation tagging has to be defined, agreed and accepted widely. > currently it's a mess. > agree on straightening out tagging. the ref tag on a route relation is a free-for-all right now, and there is not a clear concensus on the network tag either. on the other hand, if symbol is there and points at an appropriate svg file for a shield (which it generally does) then rendering may be straightforward. > 2) rendering, garmin maps, any other major data consumer must be updated to > use relations. currently none does to my knowledge. no wonder since 1) isn't > done > 3) define a grace period after 1,2) is done and consider to delete them after > that. No need to do it because any consumer understanding relations the right > way will push down the relation ref and ignore the way ref. > we probably want a transitional algorithm stated for renderers. many relations are built, but many are still missing. a use the relation if it exists and meets a set of requirements, else fall back on the ref tags on the ways sort of affair. richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Time to retire ref= on ways?
fully agree we should keep this target in mind. But first we have to resolve a long list of problems first. there shouldn't be any time when the renderer or other data consumers will be left with completely broken data because step2 was done before step1 osm doesn't have any way of enforcing anything we need to be careful to kill the dinosaur too early 1) route relation tagging has to be defined, agreed and accepted widely. currently it's a mess. 2) rendering, garmin maps, any other major data consumer must be updated to use relations. currently none does to my knowledge. no wonder since 1) isn't done 3) define a grace period after 1,2) is done and consider to delete them after that. No need to do it because any consumer understanding relations the right way will push down the relation ref and ignore the way ref. On 8 Mar 2010, at 2:36 , Paul Johnson wrote: > It's time to retire ref=* on highway=* ways to describe attributes > of the overlying route instead of the physical attributes of the way > itself. Using the ref= tag on ways to describe routes simply > creates more problems than it solves for many reasons. > > * The ref=* tag on a way is describing properties of a route that > is using the way, not a property of the way itself. > > * Many bridges and tunnels have signed references that would > actually be physical attributes of a way, but with the ref= tag on > ways describing the overlying route instead of the way itself, > makes it impossible to properly describe these attributes if ref= on > a way is describing the route above the way, not the way itself. > > * The ref= tag as defined for ways now includes more than the ref, > but also the network. ncn_ref, int_ref, etc were created as an > attempt to describe network references uniquely, but there aren't > *_ref keys for every possible network already in play. > > * The US has two federal highway networks, each state has it's own > highway network, and counties and cities have the option for their > own local networks. That's at minimum 52+ *_ref keys that would be > needed to describe each network uniquely...for the US alone! And > we're not even into transit or other routes that might use the way! > > * Munging the modifier=, network= and ref= tags provided by > relations into a single do-all ref= tag creates more problems than > it solves, particularly for formatting. It also creates > hard-to-answer questions for renderers and parsers. > > * Multiple routes, particularly when they are involved in multiple > networks, creates unmanageable way ref= tags. It also makes it > more difficult to describe attributes that belong to the route, > not the way itself (such as which direction it's going, whether it's > a bypass, business, toll or other sort of route, etc). > > Given that we have route relations, and have had them for some time > now, perhaps now is the time to: > > * put ref= information pertaining to the route that travels on the > way to a relation for that route. Provide facilities to search by > network and ref on relations. > > * Actively remove ref= tags describing routes from ways that have > route relations already: Let's kill this dinosaur. > > Thoughts? > > > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Time to retire ref= on ways?
Definitely a good idea! My only concern would be to make sure the way is correctly included in the route relationship(s) before deleting the ref=* tags. Maybe a bot could do this? Sent via BlackBerry from T-Mobile -Original Message- From: Zeke Farwell Date: Mon, 8 Mar 2010 11:28:00 To: Paul Johnson Cc: ; Subject: Re: [Talk-us] Time to retire ref= on ways? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Time to retire ref= on ways?
Yes! I agree 100%. Zeke On Mon, Mar 8, 2010 at 5:36 AM, Paul Johnson wrote: > It's time to retire ref=* on highway=* ways to describe attributes > of the overlying route instead of the physical attributes of the way > itself. Using the ref= tag on ways to describe routes simply > creates more problems than it solves for many reasons. > > * The ref=* tag on a way is describing properties of a route that > is using the way, not a property of the way itself. > > * Many bridges and tunnels have signed references that would > actually be physical attributes of a way, but with the ref= tag on > ways describing the overlying route instead of the way itself, > makes it impossible to properly describe these attributes if ref= on > a way is describing the route above the way, not the way itself. > > * The ref= tag as defined for ways now includes more than the ref, > but also the network. ncn_ref, int_ref, etc were created as an > attempt to describe network references uniquely, but there aren't > *_ref keys for every possible network already in play. > > * The US has two federal highway networks, each state has it's own > highway network, and counties and cities have the option for their > own local networks. That's at minimum 52+ *_ref keys that would be > needed to describe each network uniquely...for the US alone! And > we're not even into transit or other routes that might use the way! > > * Munging the modifier=, network= and ref= tags provided by > relations into a single do-all ref= tag creates more problems than > it solves, particularly for formatting. It also creates > hard-to-answer questions for renderers and parsers. > > * Multiple routes, particularly when they are involved in multiple > networks, creates unmanageable way ref= tags. It also makes it > more difficult to describe attributes that belong to the route, > not the way itself (such as which direction it's going, whether it's > a bypass, business, toll or other sort of route, etc). > > Given that we have route relations, and have had them for some time > now, perhaps now is the time to: > > * put ref= information pertaining to the route that travels on the > way to a relation for that route. Provide facilities to search by > network and ref on relations. > > * Actively remove ref= tags describing routes from ways that have > route relations already: Let's kill this dinosaur. > > Thoughts? > > > > ___ > Talk-us mailing list > Talk-us@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-us > ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Time to retire ref= on ways?
It's time to retire ref=* on highway=* ways to describe attributes of the overlying route instead of the physical attributes of the way itself. Using the ref= tag on ways to describe routes simply creates more problems than it solves for many reasons. * The ref=* tag on a way is describing properties of a route that is using the way, not a property of the way itself. * Many bridges and tunnels have signed references that would actually be physical attributes of a way, but with the ref= tag on ways describing the overlying route instead of the way itself, makes it impossible to properly describe these attributes if ref= on a way is describing the route above the way, not the way itself. * The ref= tag as defined for ways now includes more than the ref, but also the network. ncn_ref, int_ref, etc were created as an attempt to describe network references uniquely, but there aren't *_ref keys for every possible network already in play. * The US has two federal highway networks, each state has it's own highway network, and counties and cities have the option for their own local networks. That's at minimum 52+ *_ref keys that would be needed to describe each network uniquely...for the US alone! And we're not even into transit or other routes that might use the way! * Munging the modifier=, network= and ref= tags provided by relations into a single do-all ref= tag creates more problems than it solves, particularly for formatting. It also creates hard-to-answer questions for renderers and parsers. * Multiple routes, particularly when they are involved in multiple networks, creates unmanageable way ref= tags. It also makes it more difficult to describe attributes that belong to the route, not the way itself (such as which direction it's going, whether it's a bypass, business, toll or other sort of route, etc). Given that we have route relations, and have had them for some time now, perhaps now is the time to: * put ref= information pertaining to the route that travels on the way to a relation for that route. Provide facilities to search by network and ref on relations. * Actively remove ref= tags describing routes from ways that have route relations already: Let's kill this dinosaur. Thoughts? ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
