POST
|
Well, if it were that easy... 😉 Unfortunately I don't have any such attribute, and the data I have is in 'as is' state. So the only reasonable way of aggregating the data is a spatial one I think. One way I tried was to assign such an 'building-id' attribute to the walls by spatial joining it to building footprints, but that also failed. The problem here is that you can't use multipatch in spatial join, you have to make a footprint feature class out of it. But when doing so, totally vertical walls are 'footprinted' into their 2D 'envelope', so their footprints-envelopes often intersect two or three building footprints from the other feature class. BTW vertical walls seem to cause troubles in eg. spliting the multipatches into square grid in DI. I also thought of making polygons, which boundaries wold be roads' center lines (so in theory all the buildings should lay inside one and only one such a polygon) and aggregating them based on that. That might be some kind of solution, but still it does not solve the troubles with MeshMerger, I described.
... View more
03-11-2013
03:45 AM
|
0
|
0
|
706
|
POST
|
Hello, I'm in a situation where I have a source MultiPatch feature class (3d models of a city) in which every wall is represented as a different feature (object). I'm trying to make something usefull out of it, ie. aggregate features into buildings or 'buildings fitting in a square grid'. I've tried 'ordinary' ArcGIS tools for merging 3D features, but with no acceptable results. 'Multipatch to collada' tool generates a single collada file for every object in the source multipatch which means thousands distinct collada files, everyone with one triangle in it. If I want to Union 3D the source multipatch, I have to enclose it first. But enclosing (Enclose Multipatch) the source multipatch gives all kinds of strange effects - missing walls, some polygons connected, that should not be connected etc. (I guess it's because of quite a high detail of the source models). So I've tried to switch to Data Interoperability extension. What I managed to do here is to aggregate (Aggregate Transformer) all the features in the multipatch into one feature (potentially I guess I can merge source multipatch features into separate features based on their belonging to a square grid, or some different suitable criteria). Unfortunately it does not 'clean up' the mesh, so I get a 'polygon soup' which exported to KML (my target format)/Collada gives me a collada file with one object in it, which is composed of thousands of sub-objects - the original features (walls). I could open it in a 3rd party 3D editing application to clean it up, but if the file is too big or has too rich structure (hundreds of thousands of the sub-objects) and it freezes all the applications I've tried. The interesting transformer which according to documentation does what I want to do - MeshMerger - seems to do nothing for me. I've tried several different inputs and it always writes 0 features out of x features read. When I insert inspector point before the MeshMerger I can see all the 3D city in the Viewer, but I can't merge it and output to any format (obj, multipatch, kml, collada). The only workarounds I've found are: - manual one - importing the source multipatch (the one with thousands of objects) into CityEngine, manually merging it from there and exporting as kml/multipatch - aggregating the multipatch into single feature in Data Interoperability and writing it to obj format, which gives me a single, reasonably sized object which can be edited in 3D editing software for removing duplicated vertices etc. Any help that gives more explanation in the matter of MeshMerger transformer than the rather superficial documentation: http://docs.safe.com/fme/html/FME_Transformers/FMETransformers.htm#Transformers/meshmerger.htm wold be appreciated. Best regards, Lech
... View more
03-04-2013
01:24 AM
|
0
|
3
|
2708
|
POST
|
via rest is managed esriGeometryPoint, esriGeometryMultipoint, esriGeometryPolyline and esriGeometryPolygon. see: http://resources.arcgis.com/en/help/rest/apiref/geometry.html Simply put: it's not possible to query multipatch geometry through REST, right? Thanks for clearing that up. Best wishes, Lech
... View more
01-07-2013
09:58 PM
|
0
|
0
|
347
|
POST
|
Hello, my colleague asked me to help him in resolving his trouble with querying multipatch feature class through REST service. I tried to search the documentation but found nothing, so I ask here. When querying such a service we keep getting "Invalid or missing input parameters." message. We've got 'Return Z' enabled. Query definition we use is as simple as 'OBJECTID = 1'. I noticed that we get results when we disable 'Return Geometry', but the geometry is something important for us. Is it possible to query multipatch for geometry through REST at all? Thanks in advance for replies. Lech
... View more
01-07-2013
02:42 AM
|
0
|
2
|
850
|
POST
|
It depends on the final effect you want to achieve. In my opinion it's much better to work on single models, and then import them to ArcGIS with replace model option for single building footprints. This way you will have a multipatch layer with every building as a separate feature. Then you can select single buildings or use the layer for analytical purposes (provided that the multipatch models are closed geometry) eg. selecting all the buildings that are intersecting with some other multipatch (eg. radius of some kind of phenomenon). You can also have per-building attributes stored in the layer. If you have one feature for all the multipatch you can't, as far as I know, divide it to single buildings (AFAIK multipart to single part does not work) and you can have attributes defined only for all the layer (the only feature in the layer). But if you want to have all the buildings in one model, you should be able to union the extruded footprints into one feature and then export them as one object into collada. And as a sidenote the only 3D formats that support georeferencing are to my best knowledge: VRML, OpenFlight and collada (version 1.5 - ArcGIS uses 1.4 specification), so the best way to maintain your georeferencing data is by means of GIS layers (building footprints, point shapefiles, multipatches). You can replace certain objects in those layers with your externally edited models (by means of symbolising features with 3D symbols, or by replacing features in multipatch layers with your models).
... View more
08-27-2012
11:19 PM
|
0
|
0
|
597
|
POST
|
I'm exploring ways of converting 3D GIS data from ArcGIS to kml/kmz format for GoogleEarth and I keep running into all kinds of troubles. From what I understand there are three ways of exporting to kml: 1. Multipatch to collada - it creates a collada file as well as a kml with the spatial reference of the model. There are three problems here. The first is the shader/material that gets created for every part of the exported model. It is simply shadeless which does not look good at all. You can see it on the first model on the first attached image. The second problem is that the multipatch is split into a few separate models (eg. floor, roof, walls.. the more complex the model the more parts get created). It duplicates vertices and gives them normals with directions different than it would be on a single-part model (it may be, I don't know if it is in fact, a problem, cause some problems with lightning). I can open the collada model in some kind of 3rd party 3D graphics editor then remove the materials (or change them to shaded ones) and join all the geometries into one model. But why isn't it done during the export process? The last but not least problem is that collada models georeferenced by the kml file created by Multipatch to collada tool have... offseted rotation. You can see it on the second attached image (compared to the same multipatch exported with Layer To KML). 2. Layer To KML - it gives me some strange flickering triangles here and there and some of the triangles that were present on the multipatch it was created from are missing. I tried doing it with models of different origins (different companies providing models of 3D cities, simple extruded polygons and it's still a problem). It also creates a Multi Geometry kml from which only the first element can be edited in GoogleEarth so you can't do the cleaning up in it. 3. The ArcGlobe - ArcMap Map to KML way (described here. I can't provide an image, because the kmls generated that way keep crashing my GoogleEarth... Am I doing it all wrong? [ATTACH=CONFIG]17246[/ATTACH] Fig. 1 Starting from the left: model obtained by Multipatch to collada, model obtained with Layer To KML, 2D vector layer extruded inside Google Earth. [ATTACH=CONFIG]17247[/ATTACH] Fig. 2 Comparison of two models - the darker one was exported with Layer To KML, and the lighter with Multipatch to collada. Notice that the models are not aligned (rotation) correctly.
... View more
08-27-2012
05:43 AM
|
1
|
0
|
1548
|
POST
|
Thank you for all the answers. I guess that clears up some things for me. I have now the possibility to test 10.1 environment so I'll definitely look into the Enclose Mulitipatch tool.
... View more
08-20-2012
12:39 AM
|
0
|
0
|
812
|
POST
|
There is also the possibility that when making splits CityEngine uses n-gones to deal with apparently open edges and triangulates them during export to some external format, but I can't check it because I have only the trial version which comes with all the export options blocked. As my company is interested in CityEngine to ArcGIS workflow I'd appreciate if someone confirmed or disproved my doubts about closeness or non-closeness of multipatches (made using split operator) exported to ArcGIS.
... View more
08-12-2012
11:25 PM
|
0
|
0
|
812
|
POST
|
Ultimately it'd be so nice to be able to select a wall manually and then say right I'd like to use this code on this wall but that code on the others but I don't believe this is possible... This was what I was thinking (btw. that was the intention of starting this topic. If you could pass a path to fasade-specific rule file as a building attribute and if you could also pass the index of the wall to use the rule as an other attribute then it would be it. The base rule file would need to be a bit compilcated but I don't see any other way. And so far I haven't been able to do it this way...
... View more
08-12-2012
11:11 PM
|
0
|
0
|
493
|
POST
|
If I understand you correctly you mean the situation shown on an attached image [ATTACH=CONFIG]16764[/ATTACH] Red and green horizontal edges are coplanar but they are not connected. It that's what troubles you, then I'll tell you that it troubles me a bit too. That's just not good topology of the model. For the purpose of visualisations I guess it's ok when it looks ok. But if you want to process the model further in some other 3D graphics program, especially if it involves some automatic processing, I'm affraid it can be a problem. I suspect it can also be a problem if you export the model to a multipatch (for ArcGIS) and you want to use it with some of ArcGIS tools which require the multipatches to be closed-geometry. I guess the model with open edges isn't closed, am I right? I can't confirm if there realy is a problem here, because the trial version I have installed doesn't allow for any kind of export. One of solutions I tried is to use offset operator insted of extensive use of split. This way you have a kind of equivalnet of extrude and scale operation from traditional 3D graphics. One problem is that you can only set one offset value which will be applied to all the edges of a face. I tried using shapeO operator which allows for defining offset for every edge of a face separately ie. separately for front edge, for left edge etc., but for some reason I can't get it to work with faces different than lots' shapefiles. The second picture shows the use of offset operator for tiling windows. [ATTACH=CONFIG]16765[/ATTACH] Ofcourse this doesn't solve the problem with connecting eg. a front fasade with sides of the building and its roof without the open edges...
... View more
08-08-2012
05:15 AM
|
0
|
0
|
812
|
Title | Kudos | Posted |
---|---|---|
1 | 08-27-2012 05:43 AM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:23 AM
|