P3D v5 LineToPoint questions

[Clutch Cargo]

Diving more into vector data at this time (don't worry, I'm sure I'll be buggin' ya later Arno back on water detection, ha!), and got a couple of questions while I explore.

1. Does scenProc have the "smarts" to detect when there is an intersection of two lines? Thinking I would luv to a a light poll at intersections or other type objects maybe like light signals. Out in remote areas maybe only at intersections. If not, could you consider to add this capability?

2. We can determine what type of vegetation to be placed based on such things as population, land cover and elevation. Very powerful. Can scenProc do the same with LineToPoint? I'm thinking adjusting light distances based on population... less people, less lights. Things like that. Gonna experiment now but thought I would ask here in the meantime. Again, if not possible consider adding this option?

Thinking something like:
LineToPoint|fclass="motorway" AND popValue="over2000"|SINGLE|150|0|50|String;TYPE|GOLDLIGHT|HDG

(or maybe it would have to be done at later step or a new step?)

Thanks Arno

 

[Clutch Cargo]

oh-oh... looks like Arno has gone MIA

 

[arno]

oh-oh... looks like Arno has gone MIA

It was more MOV (missing on vacation)

Diving more into vector data at this time (don't worry, I'm sure I'll be buggin' ya later Arno back on water detection, ha!), and got a couple of questions while I explore.

Improving the water detection is also still on my todo list, I found some interesting papers about that, but haven't had the time to learn and try these different machine learning approaches.

1. Does scenProc have the "smarts" to detect when there is an intersection of two lines? Thinking I would luv to a a light poll at intersections or other type objects maybe like light signals. Out in remote areas maybe only at intersections. If not, could you consider to add this capability?

At the moment scenProc does not have this. Often GIS data is processed so that lines don't intersect. For example in OSM there is always a vertex at such an intersection. But if you have a good use case for it I guess a step can always to added to find the locations where more than 2 lines connect or so.

2. We can determine what type of vegetation to be placed based on such things as population, land cover and elevation. Very powerful. Can scenProc do the same with LineToPoint? I'm thinking adjusting light distances based on population... less people, less lights. Things like that. Gonna experiment now but thought I would ask here in the meantime. Again, if not possible consider adding this option?

Yes, you can do that, but not directly in the LineToPoint step. What I would do is sample the population density data (usually a raster) and add the value as an attribute to the generated points. Then you can use that attribute to only place lights when the density is over a certain value. Or you could even decide to draw less lights. The LineToPoint step can add a special modulus attribute (FMOD) that can help you to skip every other point for example.

 

[Clutch Cargo]

Reply to your replay #1:
At the moment scenProc does not have this. Often GIS data is processed so that lines don't intersect. For example in OSM there is always a vertex at such an intersection. But if you have a good use case for it I guess a step can always to added to find the locations where more than 2 lines connect or so.
If I understand you correctly, though OSM lines may appear to cross over each other they lines actually stop and a vertex is placed, then the line continues? If that is the case I should be able to use the Step LineToPoint in VERTEX mode? I think I tried that but I will try again to make sure. Then again are we talking about two different road types or the same? I am hoping it could work across multiple road types crossings.

Let me present my need "case" for the jury...

One thing that drives me nuts is seeing countless street lights out in the middle of nowhere like what P3D does with their default lighting option. Think of up a remote mountain road or on a long, lonely road in the desert, or in my latest case out in farmlands/ crop areas or even multi-lane highways or freeways in the USA (what I believe you guys call motorways) that are not near a city or town. One thing I noticed when I observe remote areas when I travel is they tend to place lights at even remote (relatively), intersections for safety, especially at night.

So I am seeking more control over these type areas when it comes to lighting but could easily be used for other "line objects" like telephone poles and signal lights... basically PointToLine objects. Many times, I am using the same OSM road type so I would need even a 2nd variable to add control. I am thinking something like a "population shapefile" and/or a "Land Coverage" shapefile. I use both and that way I could have that same road type add lots of lights in the cities and then spread out the points over less populated areas or a designated land type (maybe both at times). Maybe even the capability to add a light at intersections AND with custom spacing based on values.

In short, the idea is to gain more control over the same road types. please-Oh Please-OH PLEASE!

Reply to your replay #2:
Yes, you can do that, but not directly in the LineToPoint step. What I would do is sample the population density data (usually a raster) and add the value as an attribute to the generated points. Then you can use that attribute to only place lights when the density is over a certain value. Or you could even decide to draw less lights. The LineToPoint step can add a special modulus attribute (FMOD) that can help you to skip every other point for example.

Nice to know this option is already there. I will try this again as I thought I tried something similar using my population map (which is actually a shapefile of all populations by designated areas). Maybe did not write the step(s) correctly.

ah... glad to hear about new ideas for water. Those pesky shadows are a killer for me.

 

[arno]

Hi,

If I understand you correctly, though OSM lines may appear to cross over each other they lines actually stop and a vertex is placed, then the line continues? If that is the case I should be able to use the Step LineToPoint in VERTEX mode? I think I tried that but I will try again to make sure. Then again are we talking about two different road types or the same? I am hoping it could work across multiple road types crossings.

Yes, as far as I know OSM data makes sure that lines stop at intersections and have a vertex there.

I am not sure if using LineToPoint in VERTEX mode really helps you, as that will give you a point at any vertex and not just the ones that are an intersection. So I think still some logic or extra step is needed to identify which vertices are the intersection of different roads/road types.

One thing that drives me nuts is seeing countless street lights out in the middle of nowhere like what P3D does with their default lighting option. Think of up a remote mountain road or on a long, lonely road in the desert, or in my latest case out in farmlands/ crop areas or even multi-lane highways or freeways in the USA (what I believe you guys call motorways) that are not near a city or town. One thing I noticed when I observe remote areas when I travel is they tend to place lights at even remote (relatively), intersections for safety, especially at night.

So I am seeking more control over these type areas when it comes to lighting but could easily be used for other "line objects" like telephone poles and signal lights... basically PointToLine objects. Many times, I am using the same OSM road type so I would need even a 2nd variable to add control. I am thinking something like a "population shapefile" and/or a "Land Coverage" shapefile. I use both and that way I could have that same road type add lots of lights in the cities and then spread out the points over less populated areas or a designated land type (maybe both at times). Maybe even the capability to add a light at intersections AND with custom spacing based on values.

I understand what you are saying and that sounds like a logic thing to try to do.

If you are looking for intersections of different road types another approach you can try is the LineToPolygon step to buffer around the two roads and then use the BooleanFeatures step to make the INTERSECTION of the buffer polygons from the two types. You could then use these polygons to filter out points that are outside them.

But if you have an idea for a new step that makes it more efficient to process I can look at that as well.

Nice to know this option is already there. I will try this again as I thought I tried something similar using my population map (which is actually a shapefile of all populations by designated areas). Maybe did not write the step(s) correctly.

I think it would also work with a vector population map, then you would not use the AddAttributeSampleRaster step. If you have some categories of population density you want to check you can use the AddAttributeIfInside step to add an attribute to those points that are in an area with sufficient density (and the others you could remove with the RemoveFeatures step to speed up processing).

 

[Clutch Cargo]

Couple of other fun goodies to discuss using light poles as my example:

I was able to get my script working properly regarding changing the distance between light poles using a population map as my variable! But I noticed the arm of the pole ( the part of the pole that sticks out holding the light bulb) will face in all sorts of directions. Sometimes several poles in a row are facing correctly towards the road, then changes abruptly 90 or 180 degrees. I am not changing the HDG in my script leaving all default. How can I get them to all poles facing towards the roads?

Arno, you are certainly correct about lines creating vertexes when they cross another line. You said:

If you are looking for intersections of different road types another approach you can try is the LineToPolygon step to buffer around the two roads and then use the BooleanFeatures step to make the INTERSECTION of the buffer polygons from the two types. You could then use these polygons to filter out points that are outside them.

That is an interesting idea. I already buffer roads to knock out vegetation from them. I will have to try this. I thought my step idea above would work too but then the issue arises "what if two different road types intersect?" Which road would have the priority to place the light else two lights would be created at the same location.

 

[arno]

Hi, could it be those light points come from different lines? Else i would not understand the heading to change suddenly. For example if two segments go in opposite direction, the heading would change by 180 degrees.

 

[Clutch Cargo]

So lines have directions? I kinda thought so. I mean there are so many vertexes on a line/road could that be that cause the direction to change? Would it be possible to have maybe an attribute or step added that says have the object's heading point towards the line? Assuming 0 degrees is the proper heading to face towards the line. But the option to change the heading like I think you do?

 

[arno]

The LineToPoint step does assign the heading attribute for each point based on the direction of the line segment that the point is on. So I don't see why a special step would be needed for that. A heading of 0 would not align it to the line, the would align it to true north.

 

[Clutch Cargo]

So if LineToPoint already sort of has this option, it is pointing towards the direction of the line, not towards the line. Here's a test screenshot. This shot is showing two OSM motorway lines.

Here is my steps for this result:

AddAttributeIfInside|fclass="motorway"|popValue="over2000"|String;popValue|over2000
LineToPoint|fclass="motorway" AND popValue="over2000"|SINGLE|50|10|50|String;TYPE|LIGHTPOLE|HDG
PointToPolygon|TYPE="LIGHTPOLE"|8;8|HDG|String;TYPE|LIGHTPOLE
CreateAGNLibObject|TYPE="LIGHTPOLE"|{0017a263-464f-14fd-f77f-2996fed44864}

Based on what you said, shouldn't the poles all be facing the same direction? or at least the same direction for each road? Otherwise, that means that the lines are switching direct right in the middle of the line? If so there would be no way to get them all facing correctly. But if they were facing TOWARDS the line it would not matter what direction the line is.

 

[arno]

Hi,

All lights on the same line should have similar directions. Your script also look fine, i guess i should double check there are no bugs in there.

If the direction is along the line or away from it also depends on the orientation of the model. There is a heading offset in some steps to correct for this.

 

[Clutch Cargo]

As a followup, I did another test like in the above image. This time I had poles at ever 50 meters but no offset and the all started at 0 just to see if I could cut down any variables. Again, the headings of the poles appeared sporadic, facing in all different directions. Can you check?

 

[arno]

Hi,

I have a test script that places agn objects in a circle. But if I look at the created AGN file I think the same issue is there, so let me check:

 

[Clutch Cargo]

Ah.... looks interesting. If its helpful I can always upload my little test scenario/script.

 

[arno]

The bug was actually in the CreateAgnLibObj step, but I have it fixed now. So the next development release will have this fixed.

 

[Clutch Cargo]

I tested your latest update and it did indeed get all lightpoles to follow the line correctly. Nice. However, this still introduces an issue. As you can see with the image below, the poles to the left of the aircraft are facing properly. I changed my HDG value to 180 for this to align correctly to the road. But the motorway just happens to run East to West. If the road changes direction the poles will become mis-aligned to the road. Look at the poles to the right of the aircraft. That circular onramp causes the poles to face in the wrong direction, hence my request to have an Attibute in the PointToPolygon that forces the HDG of the pole to always face the road (line). Possible?

I also tried using the step HeadingFromNearestLIne, thinking if I interject that maybe it will turn the heading of the light pole to match the nearest line (in this case it would be motorway or motorway link. THe name of the step sure sounds like what I want but not matter what value I tried the poles would not change direction or follow the circle of the road,

 

[Clutch Cargo]

I did some testing on creating lights/poles at intersections using your idea of buffered roads with some promising results:

Might be hard to see but below the left wing of the aircraft a pole was created based on the intersection of two different road types and with little population. This could work, however the poles would always be in the center of the intersection (in the road). Would it be possible to add an offset attribute to PointToPolygon like you have with your LineToPoint step? Again, HDG will also be an issue like in the above mentioned post.

FYI, To give you an idea, these were the steps:

ImportOGR|B:\CA\Section_63\Population\Section_63_POP.shp|*|*|NOREPROJ
ImportOGR|B:\CA\Section_63\Road Buffers\CA_BX46_roadbuff.shp|*|*|NOREPROJ
SplitGrid|LOD13|
BooleanFeatures|INTERSECTION|type="residential" AND popValue="over200"|type="secondary" AND popValue="over200"|1
PolygonToPoint|type="residential" AND popValue="over200"|CENTER|0.0;0.0|0.0;0.0|String;Type|INTERSECT|hdg
PointToPolygon|Type="INTERSECT"|8;8|90|String;TYPE|LIGHTPOLE (need maybe an offset attribute here?)

 

[arno]

I tested your latest update and it did indeed get all lightpoles to follow the line correctly. Nice. However, this still introduces an issue. As you can see with the image below, the poles to the left of the aircraft are facing properly. I changed my HDG value to 180 for this to align correctly to the road. But the motorway just happens to run East to West. If the road changes direction the poles will become mis-aligned to the road. Look at the poles to the right of the aircraft. That circular onramp causes the poles to face in the wrong direction, hence my request to have an Attibute in the PointToPolygon that forces the HDG of the pole to always face the road (line). Possible?

It's a bit hard in your picture to see what the orientation of the light poles is. Maybe you can show the objects in Annotator that should make it more clear.

The LineToPoint step does always set the heading attribute of the point to the direction of the line it was created from. So I am not sure why you ask for an extra attribute.

I also tried using the step HeadingFromNearestLIne, thinking if I interject that maybe it will turn the heading of the light pole to match the nearest line (in this case it would be motorway or motorway link. THe name of the step sure sounds like what I want but not matter what value I tried the poles would not change direction or follow the circle of the road,

That's indeed what that step does. But it is more meant for feature that have no heading. For example if you want to align a patrol station object to the nearest road.

Might be hard to see but below the left wing of the aircraft a pole was created based on the intersection of two different road types and with little population. This could work, however the poles would always be in the center of the intersection (in the road). Would it be possible to add an offset attribute to PointToPolygon like you have with your LineToPoint step? Again, HDG will also be an issue like in the above mentioned post.

Could you not create the light points with an offset in LineToPoint? And then only use the polygons to filter out those points not near an intersection? That would make more sense to me.

 

[Clutch Cargo]

I will attempt to show you my examples in Annotator, but I've never used it . I see it needs either an xml or bln file to display but I am exporting agn's and I see scenProc can KEEPXML but that is for a bgl file. So I am a bit lost in getting it into Annotator. Found one tutorial on it by Luiz way back in 2007. Any quick tips to get my scenProc exports into Annotator?

 

[arno]

You need to load the XML autogen definition that are part of the SDK. After that you can load your bgl and see the autogen.