MapBasic: How to extract line direction?
MapBasic
Does anyone know the MapBasic function for extracting line direction?
The only thing I have been able to find is:
LAYER_INFO_ARROWS Logical value; TRUE if layer displays direction
arrows on linear objects.
I am trying to find streets that have mismatched line directions
compared to their address ranges. Not sure if I can automat it yet but
I would like to know what kind of information can be extracted about
line direction. I might just try looking for where from ToNode =
ToNode but that creates all sorts of questions like how do I get it to
check all streets? How do I comparte FromLeft, ToLeft and FromRight
ToRight address ranges with line direction?. If anyone has any
experience or advice on how to make sure address ranges and line
direction are going in the right direction and same direction it would
be greatly appreciated. I have a feeling I am taking on more than I
can chew! TIA.
Uffe Kousgaard
the line. If you believe "from" < "to" you can test for that quite
easily with SQL.
Otherwise direction on its own has no real meaning. What is the
direction of a long curved line?
Regards
Uffe Kousgaard
Bill Thoen
> Otherwise direction on its own has no real meaning. What is the
> direction of a long curved line?
>
> MapBasic wrote:
>>
>> Does anyone know the MapBasic function for extracting line direction?
If you want to get the line's direction in terms of which way the line
was drawn, then the MapBasic function you want is objectGeography(). The
point returned by OBJ_LINE_BEGX and OBJ_LINE_BEGY, is the start of your
line and the end point is returned when you use OBJ_LINE_ENDX,
OBJ_LINE_ENDY. That's for LINE objects. For polylines, use ObjectNodeX
and ObjectNodeY. The first point is the start of your line and the point
that is at position ObjectInfo(objStreet, OBJ_INFO_NPOLYGONS+N ) where N
is the Nth section of your polyline and is at the end of your pline.
Then it sounds like you have a classic a data set of streets, loosely
adhering to an Arc-Node topography model and that puts another layer of
information in the mix. First off, a street data set often contains
points, lines, plines and sometimes regions. So plan on filtering out
the points and regions and converting lines to one-segment plines so
that you feed the inner parts of your program the same type of data
element every time.
Then, for each pline there are several possibilities. If the little
tinpot god of street data is smiling on you, each street pline will have
an address range of odd address numbers on the left with the lowest
number in the fromLeft attribute and associated with the physical first
point going to the highest odd-numbered address number, which is in the
toLeft attribute. The even address numbers work in a similar fashion for
the right side of the street. Of course, in practice it's often the
other way 'round.
The starting point of your street segment is the 'From' node and the
last point on the segment is the "To" node. These nodes are connectors
to the street segments and from a database point of view if you build a
set of nodes, one for each place where lines come together, and maintain
your lines set's from and to, right and left attributes you can apply
SQL commands to that sort of data structure quite easily making a lot of
otherwise hard things quite easy to do.
Anyway, back to the streets. What you want to do is then check every
street and compare every physical pline orientation with what the
topology attributes say and if they don't agree, then either physically
flip the pline direction by rewriting the objects with all their points
or add another attribute that indicates which way the street is
digitized in relation to which way the data area oriented. If you're
going to do any fastest/shortest path type operations, starting with a
CLEAN street network is essential and often a lot of work. If you have
to do a lot of this, then it's cheaper and you get better results if
you just buy a routing package like Routeware or if your budget has
been eaten by rats, and you're a do-it-yourselfer, download an open
source one like pgRouting.
HTH,
- Bill Thoen
MapBasic
don't think I have angered him either. My table structure is:
Street_Name, FromLeft, ToLeft, FromRight, ToRight, Type, Direction,
RoadClass, FromNode, ToNode,fr_x, fr_y, to_x, to_y
That is all well and good but this data came from a vendor and
although 75% is fine there is at least 25% that is off. With over
1million records that is a lot of streets to check and correct.
Address ranges going in the wrong direction, address ranges on the
wrong side of the street, streets changing direction midway through
blocks, overlapping address ranges, all the usual stuff you get from a
vendor who tells you everything is perfect and you can just stick it
into your CAD as is! I will look into Routeware and pgRouting, thanks
for that tip. Will see if the rat ate our budget!
Bill Thoen
> Thanks Bill! The Tinpot Street File God isn't smiling on me but I
> don't think I have angered him either. My table structure is:
>
> Street_Name, FromLeft, ToLeft, FromRight, ToRight, Type, Direction,
> RoadClass, FromNode, ToNode,fr_x, fr_y, to_x, to_y
>
> That is all well and good but this data came from a vendor and
> although 75% is fine there is at least 25% that is off. With over
> 1million records that is a lot of streets to check and correct.
> Address ranges going in the wrong direction, address ranges on the
> wrong side of the street, streets changing direction midway through
> blocks, overlapping address ranges, all the usual stuff you get from a
> vendor who tells you everything is perfect and you can just stick it
> into your CAD as is! I will look into Routeware and pgRouting, thanks
> for that tip. Will see if the rat ate our budget!
>
typical $99 lightly-cooked TIGER data set, but some of those problems
are just the way it is. Address numbers /are /wacky in some places. The
parity will switch on you, the numbers will have gaps in the sequences,
and even go backwards, etc. And in some cases, that's the real world.
Also, even though they have "rules" (more like guidelines, actually)
that "left hand side is odd, right hand side is even" or "northwest
trending roads have odd addresses on the most southerly side," etc. I've
found that in any county, you can always find exceptions to the local
rules. So I don't try to fix problems with address numbers. I wrote a
street cleaning program that will flag those situations as potential
trouble spots, but unless you can go there physically or you can get a
GOOD local map, you'll never know for sure what it should be. Human
beings decide where they want to put the numbers and corner property
owners decide if their address is going to be 101 Greenleaf St. or 1099
Waste Haulage Rd., and nobody cares how much trouble they make for the
humble GIS analyst. Sort of makes you feel like you're the geologist in
the landing party on a Star Trek episode (guess who's always the first
to encounter the Metal-Munching Moon Mice and thus be written out of
the script?)
But things like lines crossing (even legitimate situations like
overpasses) or endpoints not quite connecting, or physical line
direction not agreeing with the direction attribute, all need to be
addressed (no pun intended.) And if you're working with millions of
records, be conservative about making automatic changes, because there's
a surprise lurking behind every 10,000th record like a rake lying in the
long grass, tines up, just waiting for you to tread on it so it can whip
up its handle and kiss you at high speed.
As an example of the obvious automatic fix not being so simple, I once
had a fire station near a limited access highway turn in some amazing
response times until I plotted the routes the fire trucks were taking
and saw that they were jumping off a nearby overpass onto the highway
below because the street lines crossed and my automated street cleaner
program had made that overpass into a four-way intersection.
If you can get it, I'd recommend RouteWare <http://routeware.dk/>. It's
very good with MapInfo data and also comes with a toolbox to help you
fix a lot of these street network problems, too. I use the MapBasic API
version of it for E911 response planning to do things like estimating
response times and testing the response model with alternate station
sites if we're doing a new facility study. You can also get a
ready-to-run version with an extensive GUI front end if you don't want
to build your own apps, but I had to write my own routines because we
were trying out some experimental stuff that wasn't going to be on any
menu yet, and having a ready-to-go API library for MapBasic was ideal
for what I needed.
- Bill Thoen
Spencer Simpson
Guys,
It's unreasonable for /any/ process using a street network to rely on the
physical orientation of a road segment for anything.
In places where the direction is important, such processes should always
take both the forward and reverse cases into account.
The physical orientation is the least of your worries, since the Tinpot God
of Street Files is powerless when faced with the Gremlins and Demons of
Street Naming and Numbering. They spit on our puny GIS concerns and laugh,
and cause buildings to burn down before the Fire Department gets there.
Even the most basic of street numbering assumptions are untenable.
You want odd addresses on one side of the street and evens are on the other?
Forget it. For one thing, that's mostly an Anglophone practice (I remember
a discussion with a guy from Puerto Rico back in a 90's MI partner
conference who got very frustrated trying to make people understand this).
Even here on the US East Coast, we have towns that insist on putting odds
and evens on the same side of the street. Not to mention trailer parks and
military bases that dispense with such niceties.
________________________________
Spencer
Bill Thoen
> Guys,
>
> It's unreasonable for /any/ process using a street network to rely on the
> physical orientation of a road segment for anything.
>
> In places where the direction is important, such processes should always
> take both the forward and reverse cases into account.
>
> The physical orientation is the least of your worries, since the Tinpot God
> of Street Files is powerless when faced with the Gremlins and Demons of
> Street Naming and Numbering. They spit on our puny GIS concerns and laugh,
> and cause buildings to burn down before the Fire Department gets there.
>
Have to disagree with you on the importance of physical orientation. I
think it's very important that the physical orientation of your map
features align with the logical orientation. It's one of the first
things that needs to be verified and standardized if you're planning on
doing any directed graph operations with your street network. It's
critical that data in your database be standardized to a set of rules so
you can rely on it to produce unambiguous results. Otherwise, every time
you access the logical layer of information (TO and FROM nodes) you'd
have to check to make sure that the first digitized point in an object
is the same point that's referenced by the TO node. It's a real PITA
too, but unless you carry the TO and FROM node coordinates in your
database, you'll need to get the logical and physical parts of your
street records in synch.
Also, there's more than one way to fix the topological ambiguity, and it
sort of depends on what you want to do with your streets.
- Bill Thoen
Spencer Simpson
I think we're talking past each other here.
I would classify Bill's concern as a /physical/ data integrity issue. It's
OK for processes to assume physical data integrity. But I was referring to
something else, the business processes (geocoding, routing, and the like)
that use the data.
Such processes should never assume, for example, that:
- address numbers increase in the from/to orientation
- a one-way street's allowed traffic direction is from the "from end" to the
"to" end
- odd addresses are always on the "left"
OK, the line between "physical" and "logical" can get a little blurry,
because "logical" is an overworked word, asked to mean different things in
different contexts.
In the case of street networks, you have consider the "network" part as a
separate, more basic thing (i.e. there are other types of networks than
street networks), and the "street" part as something the network supports,
along with some extra "street" attributes.
A street network is an /undirected/ graph (i.e. you can drive in both
directions on most streets). But the underlying network data model (i.e.
"from" nodes and "to" nodes) is inherently directed.
So, a network segment has a logical direction, as does any graphic object
associated with it. But the street segment that the network segment supports
does not.
You can think of the end coordinates of a network segment's graphic object
as "denormalized" values that are copied for convenience from the point
object of the node at that end into the segment's line object (the node
number being a "foreign key" into the table representing network's nodes).
Denormalized values should match the values they're copied from.
It's asking too much to assign a "logical" direction to a street segment,
and demand that street segment attributes (as separated from the underlying
network attributes) follow that direction.
Yes, the "from left" address should be the address at the from end on the
left side of the underlying network segment. It's another weird kind of
"foreign key".
The actual street segment has no "left". Stand in the middle of the street
you live on and tell me which is the "left" side. Now turn around.
When you match an address to the "left" side of a street segment, then
assign it a point off to the "left" of the underlying network segment, its
"left"ness goes away. It's just a point. You can store an "L" in one of
the point's attributes, but that's just another kind of denormalized value,
there for convenience so you don't have to go back and recalculate it.
There are many different uses for street networks, and different processes
might gain a performance benefit by rearranging street attributes and
reorienting network segments to fit various assumptions. You then wind up
with multiple copies of the same data lying around, each optimized for a
different process.
HTH
________________________________
Spencer
-----Original Message-----
From: mapi...@googlegroups.com [mailto:mapi...@googlegroups.com] On
Behalf Of Bill Thoen
Sent: Wednesday, February 17, 2010 9:18 PM
To: mapi...@googlegroups.com
Subject: Re: [MI-L] Re: MapBasic: How to extract line direction?
- Bill Thoen
--
You received this message because you are subscribed to the Google Groups
"MapInfo-L" group.
To post to this group, send email to mapi...@googlegroups.com.
To unsubscribe from this group, send email to
mapinfo-l+...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mapinfo-l?hl=en.
Mats Elfström
I see Spencer's point and agree with him. Road attributes should be independent from the arbitrary order of the points and nodes that defines them. For instance, one-way streets can be reversed at any time by the local authorities. Should the coordinates be reversed then as well? And what if that conflicts with the house numbering scheme?
It is only a coincidence that some nations or cities use a predictable method of numbering houses, and we cannot rely on that.
In sweden, we are building an address location register that puts absolute coordinates on every location address, with no odd/even or left/right scheme, but pointing to the gate or entrance in question.
Regards, Mats.E
--
______________________________________________
Mats Elfström, Väpplingvägen 21, SE-227 38 LUND, Sweden
tel: +46 46 145959 / mob: +46 70 595 39 35
alt e-mail: mats.e...@telia.com
Bill Thoen
> Hi!
>
> I see Spencer's point and agree with him. Road attributes should be
> independent from the arbitrary order of the points and nodes that
> defines them. For instance, one-way streets can be reversed at any
> time by the local authorities. Should the coordinates be reversed then
> as well? And what if that conflicts with the house numbering scheme?
> It is only a coincidence that some nations or cities use a predictable
> method of numbering houses, and we cannot rely on that.
> In sweden, we are building an address location register that puts
> absolute coordinates on every location address, with no odd/even or
> left/right scheme, but pointing to the gate or entrance in question.
using vague terms to describe things that really need some
qualification. I agree that a definition of "left" without a frame of
reference is ambiguous, but when I say the "left" side of a street, I'm
using an operational definition which is basically "Stand on the From
node and look down the street. The left side is the one on your left."
It's as arbitrary as the definition of the mathematical operator '+' but
once defined and used consistently, its range of behavior is
predictable, and you can get useful information from it if you use it as
defined.
You're both quite right that there is no inherent bond between the data
attributes of a street network and the underlying physical lines and
polylines. But there is if you rely on getting your endpoint information
from the physical line endpoints. So arrange the data so you don't have
to rely on them.
That's why I thought that Spencer's point about the connecting nodes
being something separate from the lines is spot on. In fact, when I
start to organize a raw street database, the first thing I do is make a
layer of connector nodes and then anchor the street lines to them. I
treat them as a separate table and include the necessary data links to
tie lines to nodes and a reverse index to to ties nodes back to lines.
That step also frees your database model from any dependence on the
physical map features. For doing routing, you now don't need the street
data or its shape points (vertices) at all, except for producing a
visual display. If your data defines a To and a From "cost" (i.e.
fastest, shortest, most scenic, etc.) for each direction in a connection
and your connections include references to the To and From nodes (so
you can differentiate direction), you can implement a shortest
path/least cost algorithm almost using nothing but SQL queries.
In the long run I think we'll all be going to a absolute location data
base for address geocoding. In the USA we're already doing that in our
emergency response databases that each county is supposed to implement.
Every residence, business or public building (or in rural areas, a
driveway entrance) gets an entry with its actual coordinate location,
along with address and some other information. So the problems of
interpreting an address from a network of digitized streets is one of
those GIS problems that will fade away pretty soon.
- Bill
Mats Elfström
I don't disagree with Bill either, and the attached document may be of some interest to this group and this thread. It's part of the specifications for our national road database in Sweden (NVDB).
Just like Bill describes, the data base is built by nodes and links. A node must be connected to at least one link, and a link must be connected to two nodes, a start point and an end point. The latter two defines the direction of the link. Links and nodes are treated in separate tables and can in principle have only a logical connection.
Read more at http://www22.vv.se/nvdb2_templates/templates/SingleColumn____36999.aspx
Some more information is available in English there, even if the most is in Swedish only.
Regards, Mats.E
--
You received this message because you are subscribed to the Google Groups "MapInfo-L" group.
To post to this group, send email to mapi...@googlegroups.com.
To unsubscribe from this group, send email to mapinfo-l+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mapinfo-l?hl=en.
Bill Thoen
Hi all!Hi Mats,
... the attached document may be of some interest to this group and this thread. It's part of the specifications for our national road database in Sweden (NVDB).
Thanks for this PDF document. It's an interesting read, and clarified some concepts for me that I've always thought needed to be addressed with road data. Your road people have some interesting ideas and solutions to problems that I wish our road people would consider. For example, the idea of including date boundaries on data elements is good and one that can be applied to other datasets too (it's a good answer to how you deal with "rolling data," i.e. handling the situation where database elements are continuously changing.)
Also good is the concept of multiple representations for different classes of roadway at different scales and how to conflate them. This problem doesn't get enough attention in GIS database circles, but with roads it's particularly important because while it's obvious at small scales that you use just one centerline to map a road, at large scales, seeing individual traffic lanes, bicycle lanes and pedestrian crossings and other important details of intersections --especially complicated ones or those with a history of being dangerous-- matters more. Now I wish I could read what's in "VägMod – översiktlig informationsmodell ” and some of the other docs your transportation agency maintains, because I'm sure I'd learn some new things from them.
-- - Bill Thoen GISnet - www.gisnet.com 303-786-9961