Just uploaded a new version of osm2AFSobject
Major change is the ability to use animated object models wherever a model can be specified.
There is a schema change involved so see readme.txt for details
v0.2 also contains test.xml and test.OSM to demonstrate generation features independent of any specific scenery.
/Stu
Do you think you can implement a mechanism,
I will raise the issue with the Development Manager at the next roadmap meeting 
.
Validation error: The element osm2AFS in Namespace urn: - schema has an unvalid sub-ordered element 'wayConfiguration' in Namespace urn. Expected was the list of possible elements: Nodeconfiguration in Namespace urn_osm2AFSobject - schema
OK
All way configurations must come before any node configurations until I find a way to relax the schema.
However I get an error message:
I'm afraid my Germain is not good enough to parse the error message.
Was the wayConfiguration you added after a nodeConfiguration?
I want to change it to an unordered list of configurations but but the relativePathPrefix must come first. I need to find the right schema declaration or load the config file in a different way.
it seems PylonGen doesn't always convert every power line with the given OSM data. Anyone else?
a) PylonGen has been deprecated. osm2AFSobject has equivalent functionality (and more) and is the current support stream.
b) check that the tags are correct on the power line way and pylon nodes that do not get exported.
If it still fails with osm2AFSobject send me the configuration XML and coordinates of the offending feature (by conversation)
/Stu
Is it not possible to have the objects on another drive?
This appears to be inherent in the AFS2 scenery loading mechanism.
In the core AFS2 distribution there is an objects folder at the same level as scenery that contains pilot models and a few other objects. The pilot models are are referenced in the aircraft TMC files by model name only , so there is a concept of "well known location of objects" for pilots at least.
The airport scenery objects always seem to be co-resident with the TSC file for that airport.
The [geometry] directive in the TSC will resolve a relative path so models can be packaged into folders. I extended that concept with the relativePathPrefix so the objects folder can be moved up in the folder hierarchy to be shared across different scenery packages with easier specification of the object paths in the XML.
osm2AFSobjects cannot support explicit object paths unless it is allowed by the core system.
See the osm2AFSobjects User Guide for more discussion on relative paths.
Currently objects are clipped at the bounding box defined in the OSM file
Adding a boundingbox override in the XML is not difficult but there may still be performance issues on very large files.
I have always used a tiled approach to cultivation.
For each 01x0.1 degree tile I generate a powershell script of the form
Set-ExecutionPolicy Bypass -scope Process -Force
$client = new-object System.Net.WebClient
$client.DownloadFile("https://overpass-api.de/api/map?bbox=6.9,46.3,7.0,46.4","F:\scenery\cultivation\work\6.95_46.35\6.95_46.35.OSM")
I have not tried Geofabrik. I need to look at the implications of very large OSM files.
How far can the schema be extended by the user:
The schema (osm2AFSobject.xsd) is fixed as delivered in the release. The schema is what drives the parsing logic for the XML configuration files. If the schema changes the parsing code needs to change. As long as all configuration files comply with the schema (pass validation) they will be parsed and processed correctly (barring any bugs in the code 
)
If you want different pylon types for different aerial ways you need to copy and paste the ski lift way configuration example and substitute selection criteria and model names for the new type of aerial way.
For new object class (ie cooling towers) it depends if they are represented by a circumference way or single node.
Whatever the case it would be like the way or node configuration examples for storage_tank with selection criteria of "man_made" and "cooling_tower" (or whatever tag is in the OSM file.)
Have a look at the algorithm described in the User Guide. Everything depends on defining criteria to select nodes or ways of interest and model matching criteria to select a model name to export for the feature..
/Stu
I thought it was possible just to have the "pylons" of all cableway, gondola, chairlift, t-bar and so on.... with some kind of simplified "standart" models..... like it works with Electricity Pylons in Pylogen.exe.
The power pylons are quite consistently tagged. Some other object types have a variety of tags.
That is the downside of an extensible crowd sourced system.
I did not implement the orCriteria because I did not know if there were use cases that would require it.
I was not sure anyone would want the same model displayed for features that had different tags.
it is possible with v0.1 to cut and paste a way or node configuration and substitute different selection criteria.
I wanted to understand the requirements before adding any complexity in the selection criteria schema.
Everyone should understand that v0.1 was released as beta to determine if my understanding of the requirements
captures the range of other peoples requirements.
Requirements=>design=>implementation=>test=>release
/Stu
The selection criteria can be any tag you want.
If for example some aerial ways are tagged with manufacturer make or model information and you have a 3D model for that type of equipment you can use that tag to apply the correct model only to the aerial ways of that type.
but few aerialways and stations are present in the final .tsc
check the tags on the ways for those lifts . make sure your criteria will select them.
if they are different you need to create a new way configuration for the different selections.
There is no orCriteria to allow this or this selection
There is no right or wrong answer for relative paths.
It all depends on how you want to place your scenery files in the run time folder structure.
The osm2AFSobject User Guide describes a folder structure that places the objects folder at the same level as scenery in the extra user folder structure.
This mirrors the folder layout in core AFS2 distribution. The relative path prefix in the example.XML was tested against that folder structure.
If you want some other scenery organization you will need to adjust the relative path prefix and potentially the model name strings in the XML to match your layout. It is configurable because everybody has a different idea on how things should be organized.
/Stu
If you can hold on for a few days I'll put together a quick command line application
No problem. I wrote something to patch it up.
You may still want a stand alone patch utility if others have the same issue
/Stu
I found, that I had to change the value="wind_turbine" to "wind" to get a match with wind generators in northern germany.
that is why it is driven by XML
the variation in OSM is hard to predict
When I try to add animation parameters into the term, I get an error message that this node is write protected.
I had not contemplated animation for the default model.
I will need to modify the schema to allow this and verify that the animation context is propagated correctly.
what did you provide as the second argument to PylonGen?
you specified an absolute path
the relative path prefix would be blank if the objects folder is in the same folder as the TSC
..\ if objects folder is in the parent folder
..\..\ if objects folder is in the grandparent folder
ans so on
There is no example.tsc only example.XML
osm2AFSobject will process map.osm with example.XML out of the box but AFS2 will not load the objects unless you adjust the
relativePathPrefix so that the paths in the generated [string8][geometry] elements in the TSC file match your scenery folder hierarchy.
If you put the model TMB and TTX files in the same folder as your TSC then you do not need relative path prefix and the path names in the XML would just
the TMB file name .
If you want to package the model files in separate folders or want to share the models across multiple scenery packages you need the relative paths.
Look at the section in the User Guide on relative paths
The relative path and deployment environment is really the same as PylonGen except that the relative path prefix is defined in the XML rather than as a command line argument and the models are bundled in an objects folder.
there is no example.tsc
Out of the box you can run the example.xml
running in the folder where you extracted the zip file with the command
osm2AFSobject.exe .\myFile.osm .\example.xml
should produce osmObjects.tsc with entries for any power pylons, aerial ways, storage tanks or windmill features in myFile.osm
osmObjects.tsc can be renamed to anything you choose when deployed to the scenery folders
I am not sure where the confusion lies.
/Stu
PS you would need to adjust relativePathPrefix in example.xml to match what your scenery deployment folder structure.
Sorry for the confusion
example.xml IS the config file
the osm2AFSobject.exe.config is something generated by Visual Studio
I did not test if it was safe to delete it.
PS
I tried running with osm2AFSobject.exe.config as configuration file and I am surprised there were no validation errors.
I will have to look at that.
Hi Nick
When I installed V1.0.1 and ran it the first time it patched up the folder names for the current working folder.
The problem is that I have a second working folder for another scenery area and I can't get it to patch the folder names for the second working folder.
thanks
/Stu
