Giter Club home page Giter Club logo

libcitygml's People

Contributors

adi64 avatar asemmo avatar csteuer avatar ddeka2910 avatar harutakamatsumoto avatar janno42 avatar jklimke avatar kimjuyoung93 avatar maz-1 avatar mlavik1 avatar mpursche avatar mtola avatar rcane avatar sebastic avatar shehzan10 avatar soerendischer avatar topheg avatar zhoub avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

libcitygml's Issues

pkgconfig requires libxml-2.0?

In pkgcitygml.pc.cmake I see flags that requires libxml-2.0, but afaik libcitygml parses xml with xerces-c, is that a mistake?

IntBuildingInstallation not handled?

I have citygml files with 'IntBuildingInstallation' tag what is not in source.
IntBuildingInstallation is not in the source. IntBuildingInstallation not handeled?

             <bldg:roomInstallation>
                    **<bldg:IntBuildingInstallation**
                        **gml:id="GML_da67e87f-1715-4cae-83dc-2380837c7b10">**
                        <gml:description>Badewanne von ArchiCAD 14</gml:description>
                        <gml:name>Bathtub</gml:name>
                        <bldg:function>1070</bldg:function>
                        <bldg:lod4Geometry>
                            <gml:MultiSurface>
                                <gml:surfaceMember>
                                    <gml:Polygon gml:id="PolyID36629_959_379253_37763">
                                        <gml:exterior>
                                            <gml:LinearRing
                                              gml:id="PolyID36629_959_379253_37763_0">
                                              <gml:pos>458881.04 5438361.2 0 </gml:pos>
                                              <gml:pos>458881.04 5438361.2 0.6 </gml:pos>
                                              <gml:pos>458881.04 5438362.7 0.6 </gml:pos>
                                              <gml:pos>458881.04 5438362.7 0 </gml:pos>
                                              <gml:pos>458881.04 5438361.2 0 </gml:pos>
                                            </gml:LinearRing>

Need some help building

Hi,

thanks for putting all your good work into this. I really would like to give this lib a try but I am not c++ guy. So I tried for over a day now to get this to build (and the dependencies). So far I think I got a valid binary for xerces-c but when I try to compile libcitygml I get about 1000 warnings and 24 errors. Hunting those down lead me no where.

Long story shourt... I've seen that this apparently builds with CI. Could you send me a compiled .dll for windows? I'd be more than happy to send some beer money your way :)

Thanks for considering und viele Grüße

Thorsten

Are ReliefFeatures not supported?

I've been working with a a couple of models from https://www.citygml.org/samplefiles/

Both of these models use ReliefFeature, but the CityObject for this returns 0 for both getGeometriesCount() and getImplicitGeometryCount(), and has 0 child city objects.

In FZK Viewer, the object tree for these files shows the relief:ReliefFeature as having a child relief:TINRelief object. This TINRelief object does not appear in the CityObject tree.

All the other features of the models seem to be working well. Am I missing something here?

MultiSurface not handled?

I have citygml files with several buildings where no geometry is found, they consist of things like

      <bldg:WallSurface ........
       <bldg:lod2MultiSurface>
        <gml:MultiSurface gml:id="UUID_3761e2aa-5025-41e8-a64b-71b8321c0149">
         <gml:surfaceMember>
          <gml:Polygon gml:id="DEB_LOD2_UUID_6ab80a6c-3ece-48b9-b9ff-9b4622033395_eeb5fc15-1458-4046-b353-823f50ae2a15_poly">
           <gml:exterior>
            <gml:LinearRing gml:id="DEB_LOD2_UUID_6ab80a6c-3ece-48b9-b9ff-9b4622033395_eeb5fc15-1458-4046-b353-823f50ae2a15_poly_0_">
             <gml:posList srsDimension="3">392343.615 5819938.087 34.83 392343.615 5819938.087 67.227 392343.73 5819938.334 67.494 392343.73 5819938.334 34.83 392343.615 5819938.087 34.83</gml:posList>
            </gml:LinearRing>
           </gml:exterior>
          </gml:Polygon>
         </gml:surfaceMember>
        </gml:MultiSurface>
       </bldg:lod2MultiSurface>
      </bldg:WallSurface>

Importer crashes due to dereferencing deleted memory

First of all, thanks a lot for making this great library!

When importing some larger datasets I ran into some crashes.

This appears to be the cause:

  • In the call to gluTessVertex we pass a pointer to elements stored inside the _vertices and _indices vectors.
  • However, gluTessVertex does not appear to do any work until we call gluTessEndPolygon.
  • At this point, _vertices and _indices may have been re-allocated (after successive calls to TesselatorBase::addContour which pushes new elements to them, causing them to re-allocate to fit a new capacity)
  • The memory pointed to will be freed, and accessing it (in vertexDataCallback and combineCallback) will trigger undefined behaviour.

We can fix this by making sure the vectors containing the elements we send to GLU do not grow while GLU is processing them. That would be really simple if we knew before starting how many vertices we will need to add. Unfortunately I don't think we know that?

So here's my suggested solution:

  • Build the list of vertices and indices for all contours, before starting to process them.
    • This will make sure calls to addContour will not happen while GLU is processing them.
  • Copy the index value directly to the void* data parameter, so that we can safely add new elements to _indices (from Tesselator::combineCallback) while GLU is working with them.
  • copy _vertices to a new temporary std::vector, and pass vertex pointers from this list instead, so we can safely add new elements to _vertices (from Tesselator::combineCallback) later.

It's confusing to explain, so I'll send you a PR 😁

Is the CityGML writer plan ?

I'm using CityGML for years with my own I/O library, which is not complete and aging. But I have no time to ameliorate it today. I test your reader which is performing. But I need the writher too. Is it plan ?

Fails to build with GCC 7

As reported by Matthias Klose in Debian Bug #853487:

The package fails to build in a test rebuild on at least amd64 with
gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The
severity of this report may be raised before the buster release.
There is no need to fix this issue in time for the stretch release.

The full build log can be found at:
http://people.debian.org/~doko/logs/gcc7-20170126/libcitygml_2.0-3_unstable_gcc7.log
The last lines of the build log are at the end of this report.

To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly,
or install the gcc, g++, gfortran, ... packages from experimental.

apt-get -t experimental install g++

Common build failures are new warnings resulting in build failures with
-Werror turned on, or new/dropped symbols in Debian symbols files.
For other C/C++ related build failures see the porting guide at
http://gcc.gnu.org/gcc-7/porting_to.html

[...]
cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/sources && /usr/bin/c++   -DCITYGML_LIBRARY -DLIBCITYGML_BUILD -DLIBCITYGML_DYNAMIC -DUSE_GDAL -DXERCES_STATIC_LIBRARY -Dcitygml_EXPORTS -I/<<PKGBUILDDIR>>/sources/include -I/usr/include/gdal -I/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/include  -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -fPIC -fPIC   -o CMakeFiles/citygml.dir/src/parser/linestringelementparser.cpp.o -c /<<PKGBUILDDIR>>/sources/src/parser/linestringelementparser.cpp
[ 90%] Building CXX object sources/CMakeFiles/citygml.dir/src/parser/linearringelementparser.cpp.o
cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/sources && /usr/bin/c++   -DCITYGML_LIBRARY -DLIBCITYGML_BUILD -DLIBCITYGML_DYNAMIC -DUSE_GDAL -DXERCES_STATIC_LIBRARY -Dcitygml_EXPORTS -I/<<PKGBUILDDIR>>/sources/include -I/usr/include/gdal -I/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/include  -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -fPIC -fPIC   -o CMakeFiles/citygml.dir/src/parser/linearringelementparser.cpp.o -c /<<PKGBUILDDIR>>/sources/src/parser/linearringelementparser.cpp
[ 92%] Building CXX object sources/CMakeFiles/citygml.dir/src/parser/implicitgeometryelementparser.cpp.o
cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/sources && /usr/bin/c++   -DCITYGML_LIBRARY -DLIBCITYGML_BUILD -DLIBCITYGML_DYNAMIC -DUSE_GDAL -DXERCES_STATIC_LIBRARY -Dcitygml_EXPORTS -I/<<PKGBUILDDIR>>/sources/include -I/usr/include/gdal -I/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/include  -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -fPIC -fPIC   -o CMakeFiles/citygml.dir/src/parser/implicitgeometryelementparser.cpp.o -c /<<PKGBUILDDIR>>/sources/src/parser/implicitgeometryelementparser.cpp
[ 94%] Building CXX object sources/CMakeFiles/citygml.dir/src/parser/addressparser.cpp.o
cd /<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/sources && /usr/bin/c++   -DCITYGML_LIBRARY -DLIBCITYGML_BUILD -DLIBCITYGML_DYNAMIC -DUSE_GDAL -DXERCES_STATIC_LIBRARY -Dcitygml_EXPORTS -I/<<PKGBUILDDIR>>/sources/include -I/usr/include/gdal -I/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu/include  -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -Wdate-time -D_FORTIFY_SOURCE=2 -std=c++11 -fPIC -fPIC   -o CMakeFiles/citygml.dir/src/parser/addressparser.cpp.o -c /<<PKGBUILDDIR>>/sources/src/parser/addressparser.cpp
In file included from /<<PKGBUILDDIR>>/sources/src/parser/addressparser.cpp:1:0:
/<<PKGBUILDDIR>>/sources/include/parser/addressparser.h:11:31: error: 'function' in namespace 'std' does not name a template type
         using Callback = std::function<void(std::unique_ptr<Address>&&)>;
                               ^~~~~~~~
In file included from /<<PKGBUILDDIR>>/sources/src/parser/addressparser.cpp:1:0:
/<<PKGBUILDDIR>>/sources/include/parser/addressparser.h:14:132: error: 'Callback' does not name a type; did you mean 'valloc'?
         AddressParser(CityGMLDocumentParser& documentParser, CityGMLFactory& factory, std::shared_ptr<CityGMLLogger> logger, const Callback& callback);
                                                                                                                                    ^~~~~~~~
                                                                                                                                    valloc
/<<PKGBUILDDIR>>/sources/include/parser/addressparser.h:28:9: error: 'Callback' does not name a type; did you mean 'valloc'?
         Callback m_callback;
         ^~~~~~~~
         valloc
/<<PKGBUILDDIR>>/sources/src/parser/addressparser.cpp:61:143: error: 'Callback' does not name a type; did you mean 'valloc'?
     AddressParser::AddressParser(CityGMLDocumentParser& documentParser, CityGMLFactory& factory, std::shared_ptr<CityGMLLogger> logger, const Callback& callback)
                                                                                                                                               ^~~~~~~~
                                                                                                                                               valloc
/<<PKGBUILDDIR>>/sources/src/parser/addressparser.cpp: In constructor 'citygml::AddressParser::AddressParser(citygml::CityGMLDocumentParser&, citygml::CityGMLFactory&, std::shared_ptr<citygml::CityGMLLogger>, const int&)':
/<<PKGBUILDDIR>>/sources/src/parser/addressparser.cpp:63:7: error: class 'citygml::AddressParser' does not have any field named 'm_callback'
     , m_callback(callback)
       ^~~~~~~~~~
/<<PKGBUILDDIR>>/sources/src/parser/addressparser.cpp: In member function 'virtual bool citygml::AddressParser::parseElementEndTag(const citygml::NodeType::XMLNode&, const string&)':
/<<PKGBUILDDIR>>/sources/src/parser/addressparser.cpp:91:9: error: 'm_callback' was not declared in this scope
         m_callback(std::move(m_address));
         ^~~~~~~~~~
/<<PKGBUILDDIR>>/sources/src/parser/addressparser.cpp:91:9: note: suggested alternative: 'malloc'
         m_callback(std::move(m_address));
         ^~~~~~~~~~
         malloc
sources/CMakeFiles/citygml.dir/build.make:1217: recipe for target 'sources/CMakeFiles/citygml.dir/src/parser/addressparser.cpp.o' failed
make[3]: *** [sources/CMakeFiles/citygml.dir/src/parser/addressparser.cpp.o] Error 1
make[3]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu'
CMakeFiles/Makefile2:120: recipe for target 'sources/CMakeFiles/citygml.dir/all' failed
make[2]: *** [sources/CMakeFiles/citygml.dir/all] Error 2
make[2]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu'
Makefile:152: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/<<PKGBUILDDIR>>/obj-x86_64-linux-gnu'
dh_auto_build: make -j1 returned exit code 2
      cd /<<PKGBUILDDIR>>
debian/rules:16: recipe for target 'build' failed
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

Element parser throwing errors for xlinks

I have data that contains a cityobject like:

<gml:solidMember>
  <gml:Solid>
    <gml:exterior xlink:href='#otherobject'>
    </gml:exterior>
  </gml:Solid>
</gml:solidMember>

Looks like this causes it to run

if (!m_boundElement.valid()) {
// This might happen if an container element that usally contains a child element links to an exting object using XLink an thus
// uses a combined start/end element: e.g.: <surfaceMember xlink:href="#..."/>
// For such elements a child parser must only be created if there is no xlink attribute.
CITYGML_LOG_ERROR(m_logger, "CityGMLElementParser::endElement called on unbound " << elementParserName() << " object for element <" << node << "> at " << getDocumentLocation());
throw std::runtime_error("CityGMLElementParser::endElement called on unbound CityGMLElementParser object.");
}

While I understand why it's going into this condition, I'm not completely sure why it has to throw an unrecoverable error. Isn't there a different path it can take?

Or is it because xlink is not supported?

If I wanted to work on this, what is the workaround for this?

libcitygml 1.4.4 fails to build OSG plugin with OpenSceneGraph 3.2.1

While updating the libcitygml Debian package I noticed that the osgplugin fails to build, both the osgdb_citygml and citygmlOsgViewer target:

make[3]: Entering directory '/tmp/buildd/libcitygml-1.4.3/obj-x86_64-linux-gnu'
/usr/bin/cmake -E cmake_progress_report /tmp/buildd/libcitygml-1.4.3/obj-x86_64-linux-gnu/CMakeFiles 50
[ 96%] Building CXX object osgplugin/CMakeFiles/citygmlOsgViewer.dir/CitygmlOsgViewer.cpp.o
cd /tmp/buildd/libcitygml-1.4.3/obj-x86_64-linux-gnu/osgplugin && /usr/bin/c++   -DPLUGIN_BIN_DIR=\"/tmp/buildd/libcitygml-1.4.3/obj-x86_64-linux-gnu/lib\" -DUSE_GDAL -DXERCES_STATIC_LIBRARY -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2  -std=c++11 -fPIC -I/tmp/buildd/libcitygml-1.4.3/sources/include -I/tmp/buildd/libcitygml-1.4.3/obj-x86_64-linux-gnu/include    -o CMakeFiles/citygmlOsgViewer.dir/CitygmlOsgViewer.cpp.o -c /tmp/buildd/libcitygml-1.4.3/osgplugin/CitygmlOsgViewer.cpp
/tmp/buildd/libcitygml-1.4.3/osgplugin/CitygmlOsgViewer.cpp: In member function 'bool PickingHandler::printDescriptionOfIntersectedDrawable(const osgGA::GUIEventAdapter&, osgGA::GUIActionAdapter&)':
/tmp/buildd/libcitygml-1.4.3/osgplugin/CitygmlOsgViewer.cpp:50:17: error: 'class osgGA::GUIActionAdapter' has no member named 'computeIntersections'
         if (!aa.computeIntersections(ea, intersections)) {
                 ^
/tmp/buildd/libcitygml-1.4.3/osgplugin/CitygmlOsgViewer.cpp:61:41: error: 'class osg::Drawable' has no member named 'getNumDescriptions'
         if (firstIntersection.drawable->getNumDescriptions() == 0) {
                                         ^
/tmp/buildd/libcitygml-1.4.3/osgplugin/CitygmlOsgViewer.cpp:67:68: error: 'class osg::Drawable' has no member named 'getDescriptions'
         for (const std::string& desc : firstIntersection.drawable->getDescriptions()) {
                                                                    ^
osgplugin/CMakeFiles/citygmlOsgViewer.dir/build.make:57: recipe for target 'osgplugin/CMakeFiles/citygmlOsgViewer.dir/CitygmlOsgViewer.cpp.o' failed
make[3]: *** [osgplugin/CMakeFiles/citygmlOsgViewer.dir/CitygmlOsgViewer.cpp.o] Error 1
make[3]: Entering directory '/tmp/buildd/libcitygml-1.4.3/obj-x86_64-linux-gnu'
/usr/bin/cmake -E cmake_progress_report /tmp/buildd/libcitygml-1.4.3/obj-x86_64-linux-gnu/CMakeFiles 51
[ 98%] Building CXX object osgplugin/CMakeFiles/osgdb_citygml.dir/ReaderWriterCityGML.cpp.o
cd /tmp/buildd/libcitygml-1.4.3/obj-x86_64-linux-gnu/osgplugin && /usr/bin/c++   -DUSE_GDAL -DXERCES_STATIC_LIBRARY -Dosgdb_citygml_EXPORTS -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -D_FORTIFY_SOURCE=2  -std=c++11 -fPIC -fPIC -I/tmp/buildd/libcitygml-1.4.3/sources/include -I/tmp/buildd/libcitygml-1.4.3/obj-x86_64-linux-gnu/include    -o CMakeFiles/osgdb_citygml.dir/ReaderWriterCityGML.cpp.o -c /tmp/buildd/libcitygml-1.4.3/osgplugin/ReaderWriterCityGML.cpp
/tmp/buildd/libcitygml-1.4.3/osgplugin/ReaderWriterCityGML.cpp: In function 'void createOsgGeometryFromCityGMLGeometry(const citygml::Geometry&, CityGMLSettings&, osg::Geode*, const osg::Vec3d&)':
/tmp/buildd/libcitygml-1.4.3/osgplugin/ReaderWriterCityGML.cpp:402:19: error: 'class osg::Geometry' has no member named 'addDescription'
             geom->addDescription(p.getId());
                   ^
osgplugin/CMakeFiles/osgdb_citygml.dir/build.make:57: recipe for target 'osgplugin/CMakeFiles/osgdb_citygml.dir/ReaderWriterCityGML.cpp.o' failed
make[3]: *** [osgplugin/CMakeFiles/osgdb_citygml.dir/ReaderWriterCityGML.cpp.o] Error 1

how to use

hallo dear, i have used cmake to build all files, now where should i provide my .gml files to get output ?thanks

How to access the elements maintaining external references

Hello, thanks for the nice library. But I met some problems while reading my GML file.

For example, I have a GML file with such a member:
core:cityObjectMember
<frn:CityFurniture gml:id="frn_0fede2e1-e9b0-4c85-bf79-f0f0561088da">
<frn:class codeSpace="../../codelists/CityFurniture_class.xml">1000</frn:class>
<frn:function codeSpace="../../codelists/CityFurniture_function.xml">1120</frn:function>
frn:lod3Geometry
gml:MultiSurface
gml:surfaceMember
<gml:Polygon gml:id="fme-gen-c0bb7ba3-21dc-47c1-afac-c9463a5fb91a">
gml:exterior
<gml:LinearRing gml:id="fme-gen-c0bb7ba3-21dc-47c1-afac-c9463a5fb91a_0">
gml:posList35.08438112805094 138.85740168268748 1.943731604668821 35.08433208088209 138.8574225819179 1.9891862646404748 35.084333421831275 138.8574272394311 1.989130431634036 35.084382469044485 138.85740634018458 1.9436757312691486 35.08438112805094 138.85740168268748 1.943731604668821</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</gml:surfaceMember>
</gml:MultiSurface>
</frn:lod3Geometry>
</frn:CityFurniture>
</core:cityObjectMember>

I successfully accessed the geometry child (frn:lod3Geometry), but failed to access those with external linkage (frn:class, frn:function). Are there any existing APIs for this purpose?

Thank you.

I can not compile addressparser.cpp on MSVC 2013

When compiling addressparser.cpp with MSVC 2013, I get the following 2 errors,
-) error C2593: 'operator =' is ambiguous addressparser.cpp line 52
That is on the end of statement
k_dataElements = {
{ NodeType::XAL_CountryNameNode, &Address::setCountry },
{ NodeType::XAL_LocalityNameNode, &Address::setLocality },
{ NodeType::XAL_ThoroughfareNameNode, &Address::setThoroughfareName },
{ NodeType::XAL_ThoroughfareNumberNode, &Address::setThoroughfareNumber },
{ NodeType::XAL_PostalCodeNumberNode, &Address::setPostalCode }
};
-) error C2668: 'citygml::`anonymous-namespace'::make_unique' : ambiguous call to overloaded function addressparser.cpp line 85
m_address = make_unique

(attributes.getCityGMLIDAttribute());

Missing AppearanceTarget::getAllMaterialThemes

Hi,

Is there any way to get all material themes at geometry or polygon ? I did search to the latest code base but only found

    std::vector<std::string> AppearanceTarget::getAllTextureThemes(bool front) const
    {
        auto& map = front ? m_themeTexMapFront : m_themeTexMapBack;
        std::vector<std::string> themes;
        for (const auto& pair : map) {
            themes.push_back(pair.first);
        }
        return themes;
    }

There is function AppearanceTarget::getAllTextureThemes but no AppearanceTarget::getAllMaterialThemes.

Any ideas ? Thanks in advance.

How to get the index of vertex

Hi :
I can get the vertex info from test gml file by using below sample codes, however there is no index or indics for these vertex info.
How can I get that ? My goal is to generate the mesh object by using vertex and index info.
Thanks.

std::shared_ptr myPolygon = inGeometry.getPolygon(i);
std::shared_ptr myExternalLinearRing = tempPolygon->exteriorRing();
std::vector myExternalLinearVertices = myExternalLinearRing->getVertices();

Not Support <gml:geometryMember>

As

<bldg:lod4Geometry>
  <gml:MultiGeometry>
    <gml:geometryMember>
        <gml:MultiGeometry>
            <gml:geometryMember/>
        </gml:MultiGeometry>
    </gml:geometryMember>
  </gml:MultiGeometry>
</bldg:lod4Geometry>

generated from FME.

Related to #81

Citygml 3.0 spaces are not supported

Models containing "spaces" (from CityGML 3.0) will fail to import. Examples being gen:GenericOccupiedSpace.

See OGC docs: https://docs.ogc.org/guides/20-066.html#ug-coremodel-section

Here's a sample model (converted form CityJSON):
cube.city.zip

I'll start working on support for this and send you a PR, if you don't mind :)
From what I can see it should be pretty simple to do. Just a matter of adding some new node types, and extend the if-checks in cityobjectelementparser.cpp.
Update: Ok, so probably a bit more than that, when including the new additions to "transport", that depend on this..

Reading CityGML fails if file has a <cityObjectMember> only containing ignored elements

When parsing a node we always create a new CityObjectElementParser.

This causes an exception to be thrown in CityGMLElementParser::endElement (see citygmlelementparser.cpp) if the only contains children that are ignored (because they haven't been implemented, etc.).

I've created a test file (modified version FZK-Haus) that shows the problem:
ignore-test.zip

This is the model where I first encountered this problem (because it uses "grp:CityObjectGroup", which is not implemented):
LoD3_Railway.city.zip
I've encountered the same issue on other models too.

I suggest replacing that error with a warning, and instead handling this case. I can create a PR for that. Though, please correct me if you think that would be a bad idea πŸ˜…

In the case of a container element containing a child element with an xlink, it should also be safe to continue parsing - but it's fair to print a warning, since that element won't be parsed. I noticed once case where that happens (tran:intersection with an xlink - which isn't handled at the moment). I might make a bug/PR for that too.

And by the way, thanks a lot for making this amazing library!

ParserParams::minLOD / maxLOD seem to be unused

As the heading suggests, I don't seen any references to the ParserParams::minLOD and ParserParams::maxLOD member variables. These seem to be dummy variables for now.
Is there any plan to support these options?

Question: Which version of CityGML is supported?

Hi,

I've had a look through the repository but I can't find any details about the following:

Which version of CityGML is supported?

What features are not currently supported for the supported versions of CityGML?

Thanks
Damian

Release tagging

Since code.google.com is shutting down, and the libcitygml project there has been dead for awhile, are you planning to tag releases here on GitHub?

This looks like the most viable successor of the Google hosted project and I'd like to switch the libcitygml Debian package to use this repo. Having tagged releases makes it much easier to package.

Is it possible to compile without OpenGL?

I wanted to know about critical OpenGL is to libcitygml? I see that it is only used in tesselator.
Would it be possible to disable this via a CMake option? How would this impact the rest of the loading pipeline?

Note: I am not using OSG.

Installation of libcitygml

Recently, I have tried to create the binary project from the cmake source using CMake 3.4.1 gui form but receive the following message,

CMake Error at CMakeModules/FindXerces.cmake:109 (MESSAGE):
Could not find Xerces-C !
Call Stack (most recent call first):
CMakeLists.txt:134 (FIND_PACKAGE)

Do you have the procedure or document to explain how to convert the cmake source code into the binary project so visual studio can access?

excessive logging

where do I switch off logging in citygml::load?
passing nullptr as logger in the 3rd argument does nothing

std::runtime_error with test datasets

I did have to make some trivial changes to compile with vs2012. I can provide this code if you are interested. CityGML_2.0_Test_Dataset_2012-04-23 is what I'm using, and no matter test data I choose it parses for a while and hits this condition. I was only doing a spot check of this library and it doesn't look like its working out of the box. Can you test with the citygml test data and see if you are also getting this exception thrown?

if (!m_boundElement.valid()) {
// This might happen if an container element that usally contains a child element links to an exting object using XLink an thus
// uses a combined start/end element: e.g.:
// For such elements a child parser must only be created if there is no xlink attribute.
CITYGML_LOG_ERROR(m_logger, "CityGMLElementParser::endElement called on unbound " << elementParserName() << " object for element <" << node << "> at " << getDocumentLocation());
throw std::runtime_error("CityGMLElementParser::endElement called on unbound CityGMLElementParser object.");
}

error during run

hallo it shows this error when i run
it shows this error
Parsing CityGML file C:\libcitygml\bin\tester.gml using libcitygml v.2.0.8...
ERROR [C:\Users\prasharr\Desktop\testing\libcitygml-master\sources\src\parser\geometryelementparser.cpp:75] Expected start tag of GeometryObject but got gml:multicurve at line 52, column 25 in file C:\libcitygml\bin\tester.gml
ERROR [C:\Users\prasharr\Desktop\testing\libcitygml-master\sources\src\parser\parserxercesc.cpp:300] Unexpected Exception occurred: Unexpected start tag found.

clang compiling errors

complaining about consecutive right angle brackets

/usr/local/include/citygml/cityobject.h:109:53: error: a space is required
      between consecutive right angle brackets (use '> >')
        std::vector<std::unique_ptr<ImplicitGeometry>> m_implicitGeometries;
                                                    ^~
                                                    > >

and 3 more in citymodel.h

LOD0 parsing

Hi,
I'd be willing to add LOD0 parsing to libcitygml.
However, I'm not sure if this project is still active and if a pull request could be considered ?

Thanks

CMake Error at CMakeModules/FindXerces.cmake:74

CMake Error at CMakeModules/FindXerces.cmake:74 (MESSAGE):
Could not find Xerces-C !
when i using camke to configure libcitygml

how can i fix it?
i use libcitygml0.1.3 & citygml2vrml v.0.1.3 & XERCES 3.1.1
Visual Studio 2010
Windows 7 x64

CityModel Envelope not transformed

When I load a model and use the WGS84 as the destination SRS in params, the model is transformed correctly, but the envelop for the model is not transformed. cityModel->getEnvelope().srsName() returns the original SRS and the values remain same as when there is no destination SRS.

As far as I checked, there is no one-off function to transform coordinate systems, this can only happen at model load.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    πŸ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. πŸ“ŠπŸ“ˆπŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❀️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.