PVC file format

[Anton Driesse]

There is a PVC file format for exchanging PV system physical layout
information that is identified as being open.  It is described briefly here:

https://www.pvsyst.com/help/pv-collada-file-format.htm

Does anyone think it could be useful to have pvlib read/write these files?

Anton

--
PV Performance Labs Germany
Emmy-Noether-Str. 2
79110 Freiburg
Germany

+49-761-8973-5603 (Office)
+49-174-532-7677 (Mobile)

www.pvperformancelabs.com

[Will Hobbs]

It seems potentially useful to me. 

I've been looking for a way to store geospatial metadata like inverter and combiner boundaries, and geojson seems like a decent option, but maybe .pvc could be more robust and widely used. 

Do you know if .pvc files include absolute/global location information (e.g., lat/lon of each object or a reference point for the plant)? And do you know if the format precludes assigning combiner and inverter IDs to tables?

Including this additional metadata may not be that useful in pvlib, but an "all-in-one" geospatial file might be more likely to be widely adopted than multiple file types that serve different purposes. 

Will

[Mark Mikofski]

in SolarFarmer tracker or racking locations can be specified in a CSV file with tracker or rack number as the index/row and 6 columns for (x1, y1, z1) on north/east end and (x2, y2, z2) for south/west end. But I'm open to using the collada file definitions, especially if that means they can be read into sketch-up directly.

The extra meta data in the .pvc around module dimensions and tracker rotation limits, etc. seems redundant b/c a lot of that is already specified in the PAN file. SolarFarmer has additional files that can save/load rack and tracker specs with the same info, but it is in (oh no!) xml. I can share some examples, but I think something in yaml or json would be easier to read.

[Anton Driesse]

@mark: Well, certainly yaml is easier on the eyes, but if it's a pvlib function doing the reading maybe data exchange with other programs is more important than my eyes.

@will: I would assume that readers of the format would ignore anything they don't understand. 

--
You received this message because you are subscribed to the Google Groups "pvlib-python" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pvlib-python...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/3f9e7020-e343-4ac9-9273-1b2708fe9dd2n%40googlegroups.com.

[cwh...@sandia.gov]

There is at least one commercial user of pvlib that is asking for this capability. Even if pvlib would currently use only a portion of the file content, I think a reader is worth adding.

[Anton Driesse]

Great, sounds like we might have a commercial volunteer to implement this then! :)

[Anton Driesse]

For those who are interested in this topic:

https://github.com/NREL/SAM/issues/208

Anton

--
You received this message because you are subscribed to the Google Groups "pvlib-python" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pvlib-python...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/pvlib-python/a751a731-24cd-54d4-5b2b-00df4c019bb0%40pvperformancelabs.com.