But yeah - that's been working for us so far pretty well
@pwideman (or anybody else who's interesting in java/spring implementations) here is what i have so far -- just real basic functionality. if you want to reuse any of it, you should just be able to tack on a new module that gets autoconfigured based on a profile name and provide your own entities, repositories, and service implementations
Thanks @joshfix, we have already coded up a skeleton service for our own implementation that we'll be filling out. Unfortunately I can't share the entire project as it is based on some of our product code, which is not open source. I'll compare/contrast to what you have here. I'll put some thought into whether any parts of our implementation could be open sourced, but it would probably just be the equivalent of swagger-codegen on the spec, so may not be useful.
no worries. i've noticed some of the swagger generated controllers require a bit of massaging. for instance, the ImageryApiController only provides a single method that returns ResponseEntity<FeatureCollection>. if the "f" parameter equals "html", you don't have much of an option to return a template model or simple an html string.
i just duplicated the two methods and added get mappings that look like this @GetMapping(value = "/imagery", produces = MediaType.TEXT_HTML_VALUE, params = "f=html") and return a ResponseEntity<String> with some really crappy html representation of the objects
the spec currently has a definition for "Polygon", which has a property called "type" and an enumerated value of "Polygon".
should the definition be changed to "geometry" or something similar, then let the type define what geometry it is?
I would be in favor of mimicking GeoJSON unless there is something else that is better to copy